Verizon Technical Information Document

 

 

Known Issue – Troubleshooting Clocking Issues on a Cisco Serial Line

 

 

 

SYMPTOM

 

In a serial line connected to a Cisco router, a chronic loss of connection on the line or increasing numbers of input errors can indicate a clocking issue on the line.

 

BACKGROUND

 

On a serial line, the CSU/DSU (CSU stands for Channel Service Unit, DSU stands for Data Service Unit) is the device that converts a digital data frame used on a Local Area Network (LAN) into the kind of frame that can be processed by a Wide Area Network (WAN), and vice versa.  This CSU or DSU device derives the data clocking for the serial line from the data passing through it.  To recover the clock, the CSU/DSU must receive at least one 1-bit value for every 8 bits of data.

 

It is common on newer serial line implementations to use ESF (extended superframe) framing with B8ZS (binary eight-zero) coding.  In B8ZS coding, a special code is inserted into the connection whenever the serial link detects eight consecutive zeros.  This preserves ones integrity on the data stream.  Older serial lines implementations may use SF (superframe format) framing and AMI (alternate mark inversion).  AMI does not have a specific method for maintaining ones density.

 

Another important element in serial communications is SCTE (serial clock transmit external) timing.  SCTE terminal timing is the clocking that is echoed back from the data terminal equipment, such as a router, back to the DSU/CSU device (the data communications equipment).  It is highly recommended to use SCTE timing on any serial transmissions higher than 64 kbps.

 

 

 

 

CAUSES

 

In general, clocking issues on Cisco serial lines that are a part of WAN interconnections tend to fall within one of the following categories:

 

-       Incorrect DSU or CSU configuration.

-       Out-of-specification cables (for example, cables that are longer than 50 feet or cables that are not properly shielded).

-       Noisy or poor patch panel connections.

-       “Daisy-chained” cables (two or more cables connected together to make a connection).

 

TROUBLESHOOTING INSTRUCTIONS

 

Detecting clocking problems

 

Input errors on a serial interface indicate potential clocking issues.  To determine if there are input errors on an interface, follow these steps:

 

1.   Run a show interfaces serial command in EXEC mode at the router command line.

2.   Look at the output of this command.  An example of such output is shown in Figure 1 below.  Look for CRC errors, framing errors, and aborts.

3.   If the number of errors exceeds 0.5 to 2.0 percent of the traffic on the interface, it is likely that there are clocking issues somewhere on the WAN connection.

4.   Look for any faulty patch panels on the connection.  If you see one, bypass or repair the faulty panel.

5.   Isolate the source of the clocking conflicts by following the steps in the next section, Isolating Clocking Problems.

 

 

 


Isolating Clocking Problems

 

1.   Perform a series of ping and loopback tests on the line, both local and remote.

2.   Using the results of these tests, determine if the clocking issue is on one end of the connection or on the line itself.  In local loopback mode, run ping tests using different patterns and packet sizes (1500-byte datagrams are good for testing).  This is important because in a serial connection to the CSU/DSU, some patterns may not cause a clocking error while other patterns will.

3.   Before and after each test, run a show interfaces serial command to determine if input errors are or are not increasing and where they are occurring.

a.   If input errors increase on both ends of the connection, the issue is likely due to a CSU clocking problem or incorrect CSU configuration.

b.   If input errors are increasing on only one end of the connection, there is likely a DSU clocking issue, an incorrect DSU configuration, or an issue with the cable itself.

c.    If there are aborts accumulating on one end of the line, then the other end of the line could be sending corrupted information, or there is a physical issue with the line.

 

 

SOLUTIONS

 

Follow these guidelines for fixing the particular kind of clocking issue that was isolated earlier:

 

Incorrect CSU configuration

 

1.   Ensure that the clock source settings on the CSU at each end of the line match, both set to local or line.  Line is the most typically used setting.  If they do not match, change the setting on one of the CSUs so that both settings match.

2.   Check the LBO setting on the CSU.  Make sure that the impedance setting on the CSU matches that of the serial line.  For more information, consult the documentation for your CSU hardware unit.

 

Incorrect DSU configuration

 

1.   Ensure that the DSUs on both end of the line have SCTE mode enabled.  If one or both DSUs do not have SCTE mode enabled, then enable it.

2.   To ensure that ones density is properly maintained on the line, make sure that each DSU uses the same framing setting (ESF or B8ZS) that the leased-line or other carrier service uses. You will need to contact your carrier provider to determine their framing settings.

3.   If your carrier service uses AMI coding, then either invert the clock on both sides of the link (if the link is not using SCTE timing), or else run the DSU in bit-stuff mode.  More information can be found in the documentation for your DSU hardware unit.

a.   To invert the clock, enter the command at the router command line that is specific to the kind of Cisco router used.  For instance, for Cisco 7000 series routers, the command is invert-transmit-clock interface configuration.  For Cisco 4000 series routers, the command is dte-invert-txc. 

b.   For other Cisco series routers, consult the IOS guide for that router to find the proper command.

 

 

 

Cable is out of specification

 

1.    If your cable is longer than 50 feet, then replace with a cable that is shorter than 50 feet.

2.   If the cable is unshielded, then replace with a shielded cable.

 

 

 

 

 

 

 

 

 

 

FIGURES

 

 

Figure 1:  Example of the output of a show interfaces serial command, with types of errors indicated.

 

 

 

 

 

 

Author:  James Sanders

 

Date:  July 11, 2017