Troubleshooting Leased Lines
Once a leased line has been properly provisioned and installed by the telco, installation of a WAN network using Cisco routers is usually a simple, trouble-free task, requiring minimal configuration and maintenance. However, when a network does not operate as expected, proven problem-isolation techniques can be applied to recognize and solve common WAN problems. Cisco routers offer diagnostic tools to assist in troubleshooting network problems. Most WAN problems can be diagnosed by using the following commands:
Using The Show Interface Command To Troubleshoot Serial Lines
The show interface EXEC command displays useful troubleshooting information that varies depending on the interface type (e.g. Serial, Ethernet, Token Ring, or FDDI) and the wide area network (WAN) type used on the interface (e.g. X.25, Leased Line, or Frame Relay). This document specifically focuses on how the show interface command can be used to diagnose serial interfaces in a leased line environment.
Figure 1 illustrates the output of show interface serial0 for a High-Level Data Link Control (HDLC) encapsulated, leased-line serial interface. Important fields for diagnosing serial line problems are outlined in the illustration and explained below.
Figure 1 - Output of "show interface serial0" for HDLC encapsulated leased line interface
Interface and Line Protocol Status
The quickest way to diagnose the functionality of a serial interface is to read the first line of the show interfaces serial output. Five possible states can be identified by the interface and line protocol status line:
Status Line State | Possible Causes and Suggested Actions |
---|---|
Serial x is up, line protocol is up | This status indicates that the interface is functioning properly. |
Status Line State | Possible Causes and Suggested Actions |
---|---|
Serial x is down, line protocol is down | This status indicates that
the router is not sensing a carrier detect (CD) signal. Possible Causes:
Suggested Actions: Step 1 Check the LEDs on the CSU/DSU to see if CD is active, or insert a breakout box on the line to check for the CD signal. Step 2 Verify that you are using the proper cable and interface (see your hardware installation documentation) Step 3 Insert a breakout box; check all control leads. Step 4 Contact your leased-line or other carrier service. Step 5 Swap faulty parts. Step 6 If you suspect faulty router hardware, change the serial line to another port. If the connection comes up, the previously connected interface has a problem. |
Status Line State | Possible Causes and Suggested Actions |
---|---|
Serial x is up, line protocol is down | Possible Causes:
Suggested Actions: Step 1 Conduct CSU/DSU loopback tests. During local loopback, use the show interfaces serial number command to determine whether the line protocol comes up. If the line protocol does come up, it is likely that there is a telephone company problem or that the remote router is down. Step 2 If the problem appears to be on the remote end, repeat Step 1 on the remote modem, CSU, or DSU. Step 3 Verify all cabling. Make certain that the cable is attached to the correct interface, the correct CSU/DSU and the correct telephone company network termination point. Use the show controllers EXEC command to determine which cable is attached to which interface. Step 4 Enable the debug serial interface EXEC command. Step 5 If the line protocol does not come up in local loopback mode and if the output of the debug serial interface EXEC command shows that the keepalive counter is not incrementing, a router hardware problem is likely; swap router interface hardware. Step 6 If you suspect faulty router hardware, change the serial line to an unused port. If the connection comes up, the previously connected interface has a problem. |
Status Line State | Possible Causes and Suggested Actions |
---|---|
Serial x is up, line protocol is up (looped) | Possible Causes:
Suggested Actions: Step 1 Use the write terminal privileged EXEC command to look for any instances of the loopback interface configuration command. Step 2 If you find an occurrence of the loopback interface configuration command, use the no loopback interface configuration command to remove the loop. Step 3 If you do not find the loopback interface configuration command, examine the CSU/DSU to determine whether they are configured in manual loopback mode. If they are, disable manual loopback. Step 4 Reset the CSU or DSU and inspect the line status. If the protocol comes up, no other action is needed. Step 5 If the CSU or DSU is not configured in manual loopback mode, contact the leased-line or other carrier service for line troubleshooting assistance. |
Status Line State | Possible Causes and Suggested Actions |
---|---|
Serial x is administratively down, line protocol is down | Possible Causes:
Suggested Actions: Step 1 Check router configuration for the shutdown command. Step 2 Use the no shutdown interface configuration command to remove the shutdown command. Step 3 Verify that there are no identical IP addresses using the write terminal privileged EXEC command or the show interfaces EXEC command. Step 4 If there are duplicate addresses, resolve the conflict by changing one of the IP addresses. |
The following is a general procedure for performing loopback tests on HDLC links: | |
Step 1 | Place the CSU/DSU in local loopback mode. In local loopback mode, the use of the line clock (from the telephone service) is terminated. The DSU is forced to use the local clock. |
Step 2 | Use the show
interfaces serial command to determine whether
the line status changes from line protocol is
down to line protocol is up (looped),
or if it remains down. If the line protocol comes up when the CSU/DSU is in local loopback mode, the problem might be on the remote end of the serial connection. If the status line does not change state, there is a possible problem in the router, connecting cable, or CSU/DSU. |
Step 3 | If the problem appears to be local, issue the debug serial interface command. |
Step 4 | Take the CSU/DSU out of local loop mode. With the line protocol down and debug serial interface command enabled, the debug serial interface output will indicate that keepalive counters are not incrementing. |
Step 5 | Place the CSU/DSU in local loop mode again. This should cause the keepalive packets to begin to increment. Specifically, the values for mineseen and yourseen keepalives will increment every 10 seconds. If the keepalives do not increment, a router hardware problem is possible. Swap router interface hardware. |
Step 6 | Use the show interfaces serial command on the routers at both ends of the link. Examine the display output for CRC, framing errors, and aborts. If this step indicates errors exceeding an approximate range 0.5 to 2.0 percent of traffic on the interface, isolate the source of possible clocking conflicts by using loopback and ping tests. |
Using the Debug Serial Interface Command to Troubleshoot Serial Lines Click here for more information on debug commands.
Output from the HDLC Version of the debug interfaces serial Command
The debug serial interface command is one example of an extremely useful debug command for analyzing packets on a serial line.
If the show serial interface command shows that the line and protocol are down, you can use the debug serial interface command to isolate a timing problem as the cause of a connection failure. If the keepalive values in the mineseq, yourseen, and myseen fields are not incrementing in each subsequent line of output, there is a timing or line problem at one end of the connection.
The output of the debug serial interface command can vary, depending on the type of WAN configured for an interface: Frame Relay, HDLC, HSSI, SMDS, or X.25. The output also can vary depending on the type of encapsulation configured for that interface and the hardware platform.
The following list describes the possible output the command can generate:
Field | Description |
Serial1 | Interface through which the serial connection is taking place. |
HDLC | Indicates that the serial connection is an HDLC connection. |
myseq 636119 | The myseq counter increases by one each time the router sends a keepalive packet to remote router. |
mineseen 636119 | The value of the mineseen counter reflects the last myseq sequence number the remote router has acknowledged receiving from the router. The remote router stores this value in its yourseen counter and sends that value in a keepalive packet to the router. |
yourseen 515032 | The yourseen counter reflects the value of the myseq sequence number the router has received ina a keepalive packet from the remote router. |
line up | Indicates that the connection between the routers is maintained. Value changes to line down if the values of the myseq and myseen fields in a keepalive packet differ by more than three. Value returns to line up when the interface is reset. If the line is in loopback mode. (looped) appears after this field. |
The following are additional error messages that the debug serial interface command can generate for HDLC:
Field | Description |
Illegal serial link type code xxx, PC = 0xnnnnnn | This message is displayed if the router attempts to send a packet containing an unknown packet type. |
Illegal HDLC serial type code xxx, PC = 0xnnnnnn | This message is displayed if an unknown packet type is received. |
Serial 0: attempting to restart | This message is displayed periodically if the interface is down. The hardware is then reset to hopefully correct the problem. |
Serial 0: Received bridge packet sent to nnnnnnnnn | This message is displayed if a bridge packet is received over a serial interface configured for HDLC, and bridging is not configured on that interface. |
Caution The output from debug privileged EXEC commands provides diagnostic information concerning a variety of internetworking events relating to protocol status and network activity in general. Use these commands with great care. In general, it is recommended that these commands only be used under the direction of your router technical support representative when troubleshooting specific problems. Enabling debugging can disrupt operation of the router when internetworks are experiencing high load conditions. When you finish using a debug command, remember to disable it with its specific no debug command or with the no debug all command (the undebug command is also accepted).
To minimize the impact of using debug commands, follow this procedure:
Step 1 | Issue the no logging console global configuration command on your router. This command disables all logging to the console terminal (to re-enable logging to the console, issue the logging console enable global configuration command). |
Step 2 | Telnet to a router port and enter the enable EXEC command. |
Step 3 | Issue the terminal monitor command and issue the necessary debug commands (to disable logging on the virtual terminal, issue the terminal no monitor command). |
Following this procedure minimizes the load created by using debug commands because the console port no longer has to generate character-by-character processor interrupts.
All contents copyright © Cisco Systems, Inc. Important notices.