This document describes how to troubleshoot problems with network clocking. There are many good documents on clocking issues and remedies, and this document is not intended to repeat information. Instead, the objective is to consolidate the knowledge in those documents and to provide pointers to those documents for details.
When implementing a time-division multiplexing (TDM) (T1/E1) interface, some of the following issues may occur:
If the show controller t1 command is used in order to investigate such problems, clock slips may be observed. The solution is not necessarily to make the T1 participate in network clocking; indeed, network clocking might well be the problem.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If the network is live, make sure that the potential impact of each command is understood before it is implemented.
Refer to Cisco Technical Tips Conventions for information on document conventions.
Traffic received on a T1 or E1 interface is inside repeating bit patterns called frames; each frame is a fixed number of bits. The receiving device simply counts the number of bits in order to determine the start and end of a frame and thus knows exactly when to expect the end of a frame.
However, if the timing between the sending and the receiving device is not the same, the receiving device might sample the bit stream at the wrong moment, which results in the return of an incorrect value. This condition is known as a clock slip.
By definition, a clock slip is the repetition or deletion of a bit (or block of bits) in a synchronous data stream, due to a discrepancy in the read and write rates at a buffer. Slips arise because an equipment buffer store or other mechanisms cannot accommodate differences between the phases or frequencies of the incoming and outgoing signals. This occurs when the timing of the outgoing signal is not derived from that of the incoming signal.
In the context of this document, think of the T1 port as the receiving device and the DSP as the sending device.
TDM-capable Cisco routers use an internal oscillator as a clock source in order to pass traffic across the backplane and across other interfaces. Cisco routers that are TDM-capable are the integrated services router generation 1 (ISR G1), ISR generation 2 (ISR G2), and the AS5xxx.
While Cisco IOS® software can easily control the clocking, the default clocking mode on these routers is effectively free running. The received clock signal from an interface is not connected to the TDM backplane of the router and is not used for internal synchronization between the rest of the router and other interfaces.
Each voice network module card (for example, the NM-HDV2) has its own PLL circuitry and can provide:
In Cisco routers, there is one PLL on the motherboard, called the network-clock. This PLL acts as the internal clock to the TDM backplane on the router and can lock on to one external source of clocking.
Note: The PLL can lock on to only one external source.
Think of NMs as enhanced voice cards. In addition to the voice card electronics, NMs also have PLLs and DSPs. That is, the NM essentially has everything required in order to be a self-contained clocking domain.
Here are several guidelines to help determine if network clocking is required:
Note: PVDM3s are installed onto the motherboard with the ISR G2 platforms. Therefore, the clocks are synchronized. Compare this to PDM2s, which can also be on NMs.
Clocks are synchronized when you use one clock source for all processing by participating modules and ports. This requires both a participate and a select step:
Here are several scenarios that explain when to use network clocking.
Network clocking is necessary:
Consider a two-port NM in which the two T1 ports are connected to two different service providers. If the two clock sources are Stratum 1 and are perfectly synchronized, you do not need network clocking. Because this is rare, however, network clocking should be required in this scenario.
Consider the scenario where a voice-enabled gateway has T1s/E1s on NMs with their own DSPs. If there are no DSPs on the motherboard or if the DSPs are not used (that is, no DSP farming is used or configured), each NM operates in its own clocking domain. In this scenario, there is no need for network clocking or for the network-clock-participate or network-clock-configuration commands.
Consider a situation where the T1 ports on two different NMs on a router connect to two different clock sources (such as two different carriers). Here are the different configurations to resolve this situation.
If both modules have onboard DSPs:
If at least one of the modules has onboard DSPs, but does not need onboard DSPs:
If you want both modules to participate in network clocking:
Miami#show running-config
!
!
Unnecessary output deleted
!
network-clock-participate slot 1
network-clock-participate slot 2
network-clock-select 1 T1 1/0
!
!
controller T1 1/0
description PSTN Trunk
framing esf
clock source line
linecode b8zs
ds0-group 1 timeslots 1-24 type e&m-wink-start
!
controller T1 2/0
description Tie Trunk to PBX
framing esf
clock source internal
linecode b8zs
ds0-group 1 timeslots 1-24 type e&m-wink-start
!
end
Note: Use the Command Lookup Tool (registered customers only) in order to obtain more information on the commands used in this section.
Revision | Publish Date | Comments |
---|---|---|
1.0 |
12-Apr-2013 |
Initial Release |