Troubleshooting Clocking Problems
Clocking conflicts in serial connections can lead either to chronic loss of connection service or to degraded performance. This section discusses the important aspects of clocking problems: clocking problem causes, how to detect clocking problems, how to isolate clocking problems, and clocking problem solutions.
Clocking Overview
The CSU/DSU derives the data clock from the data that passes through it. To recover the clock, the CSU/DSU hardware must receive at least one 1-bit value for every 8 bits of data that pass through it; this is known as ones density. Maintaining ones density allows the hardware to recover the data clock reliably.
Newer T1 implementations commonly use Extended Superframe Format (ESF) framing with binary eight-zero substitution (B8ZS) coding. B8ZS provides a scheme by which a special code is substituted whenever eight consecutive zeros are sent through the serial link. This code is then interpreted at the remote end of the connection. This technique guarantees ones density independent of the data stream.
Older T1 implementations use D4 (also known as Superframe Format [SF]) framing and Alternate Mark Inversion (AMI) coding. AMI does not utilize a coding scheme like B8ZS. This restricts the type of data that can be transmitted because ones density is not maintained independent of the data stream.
Another important element in serial communications is serial clock transmit external (SCTE) terminal timing. SCTE is the clock echoed back from the data terminal equipment (DTE) device (for example, a router) to the data communications equipment (DCE) device (for example, the CSU/DSU).
When the DCE device uses SCTE instead of its internal clock to sample data from the DTE, it can better sample the data without error even if there is a phase shift in the cable between the CSU/DSU and the router. Using SCTE is highly recommended for serial transmissions faster than 64 kbps. If your CSU/DSU does not support SCTE, see the section “Inverting the Transmit Clock,” later in this chapter.
Clocking Problem Causes
In general, clocking problems in serial WAN interconnections can be attributed to one of the following causes:
•
Incorrect DSU configuration
•Incorrect CSU configuration
•Cables out of specification (longer than 50 feet [15.24 meters] or unshielded)
•Noisy or poor patch panel connections
•Several cables connected in a row
Detecting Clocking Problems
To detect clocking conflicts on a serial interface, look for input errors as follows:
Step 1 Use the show interfaces serial exec command on the routers at both ends of the link.
Step 2 Examine the command output for CRC, framing errors, and aborts.
Step 3 If either of these steps indicates errors exceeding an approximate range of 0.5 percent to 2.0 percent of traffic on the interface, clocking problems are likely to exist somewhere in the WAN.
Step 4 Isolate the source of the clocking conflicts, as outlined in the following section, “Isolating Clocking Problems.”
Step 5 Bypass or repair any faulty patch panels.
Isolating Clocking Problems
After you determine that clocking conflicts are the most likely cause of input errors, use the following procedure to isolate the source of those errors:
Step 1 Perform a series of ping tests and loopback tests (both local and remote), as described in the section “CSU and DSU Loopback Tests,” earlier in this chapter.
Step 2 Determine which end of the connection is the source of the problem, or whether the problem is in the line. In local loopback mode, run different patterns and sizes in the ping tests (for example, use 1500-byte datagrams). Using a single pattern and packet size may not force errors to materialize, particularly when a serial cable to the router or CSU/DSU is the problem.
Step 3 Use the show interfaces serial exec command, and determine whether input errors counts are increasing and where they are accumulating.
If input errors are accumulating on both ends of the connection, clocking of the CSU is the most likely problem.
If only one end is experiencing input errors, there is probably a DSU clocking or cabling problem.
Aborts on one end suggest that the other end is sending bad information or that there is a line problem.
Note Always refer to the show interfaces serial command output (see Figure 15-1). Log any changes in error counts, or note if the error count does not change.
Clocking Problem Solutions
Table 15-8 outlines suggested remedies for clocking problems, based on the source of the problem.
|
Possible Problem
|
Solution
|
|---|---|
|
Incorrect CSU configuration |
1. 2. 3. |
|
Incorrect DSU configuration |
1. 2. (For any interface that is connected to a line of 128 kbps or faster, SCTE must be enabled. If your DSU does not support SCTE, see the section “Inverting the Transmit Clock,” later in this chapter.) 3. Check with your leased-line provider for information on its framing and coding schemes. 4. |
|
Cable to router out of specification |
If the cable is longer than 50 feet (15.24 meters), use a shorter cable. If the cable is unshielded, replace it with shielded cable. |
|
1 LBO = line build out |
Inverting the Transmit Clock
If you are attempting serial connections at speeds greater than 64 kbps with a CSU/DSU that does not support SCTE, you might have to invert the transmit clock on the router. Inverting the transmit clock compensates for phase shifts between the data and clock signals.
The specific command used to invert the transmit clock varies between platforms. On a Cisco 7000 series router, enter the invert-transmit-clock interface configuration command. For Cisco 4000 series routers, use the dte-invert-txc interface configuration command.
To ensure that you are using the correct command syntax for your router, refer to the user guide for your router or access server and to the Cisco IOS configuration guides and command references.
