|
|
This chapter presents general troubleshooting information and a discussion of tools and techniques for troubleshooting serial connections. The chapter consists of the following sections:
The output of the show interfaces serial exec command displays information specific to serial interfaces. Figure 15-1 shows the output of the show interfaces serial exec command for a High-Level Data Link Control (HDLC) serial interface.
This section describes how to use the show interfaces serial command to diagnose serial line connectivity problems in a wide-area network (WAN) environment. The following sections describe some of the important fields of the command output.
Other fields shown in the display are described in detail in the section "Detailed Information on the show interfaces serial Command" later in this chapter.
You can identify five possible problem states in the interface status line of the show interfaces serial display (see Figure 15-1):
Table 15-1 shows the interface status conditions, possible problems associated with the conditions, and solutions to those problems.
| Status Line Condition | Possible Problem | Solution |
|---|---|---|
Serial x is up, | --- | This is the proper status line condition. No action required. |
Serial x is down, | Typically indicates that | Step 1 Check the LEDs on the CSU/DSU to see whether 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 hard- ware installation documentation). Step 3 Insert a breakout box and check all control leads. Step 4 Contact your leased-line or other carrier service to see whether there is a problem. 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. |
Serial x is up, |
| Step 1 Put the modem, CSU, or DSU in local loopback mode and use the show interfaces serial command to determine whether the line protocol comes up. If the line protocol comes up, a telephone company problem or a failed remote router is the likely problem. 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. Caution: Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use. |
| 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 the line protocol comes up and the keepalive counter increments, the problem is not in the local router. Troubleshoot the serial line as described in the sections "Troubleshooting Clocking Problems" and "CSU and DSU Loopback Tests" later in this chapter. Step 7 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. | |
| Step 1 Add the clockrate interface configuration command on the serial interface. Syntax: clock rate bps Syntax Description:
Step 2 Set the DTE device to SCTE mode if possible. If your CSU/DSU does not support SCTE, you might have to disable SCTE on the Cisco router interface. Refer to the section "Inverting the Transmit Clock" later in this chapter. Step 3 Verify that the correct cable is being used. Step 4 If the line protocol is still down, there is a possible hardware failure or cabling problem. Insert a breakout box and observe leads. Step 5 Replace faulty parts as necessary. | |
Serial x is up, | Loop exists in | Step 1 Use the show running-config privileged exec command to look for any loopback interface configuration command entries. Step 2 If you find a loopback interface configuration command entry, 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 line 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. |
Serial x is up, |
| Step 1 Troubleshoot the line with a serial analyzer and breakout box. Look for toggling CTS7 and DSR8 signals. Step 2 Loop CSU/DSU (DTE loop). If the problem continues, it is likely that there is a hardware problem. If the problem does not continue, it is likely that there is a telephone company problem. Step 3 Swap out bad hardware as required (CSU, DSU, switch, local or remote router). |
| Step 1 Check the 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 show running-config 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. |
Output drops appear in the output of the show interfaces serial command (refer to Figure 15-1) when the system is attempting to hand off a packet to a transmit buffer but no buffers are available.
Symptom: Increasing output drops on serial link.
Table 15-2 outlines the possible problem that might cause this symptom and describes solutions to that problem.
| Possible Problem | Solution |
|---|---|
Input rate to serial interface exceeds bandwidth available on serial link | Step 1 Minimize periodic broadcast traffic such as routing and SAP1 updates by using access lists or by other means. For example, to increase the delay between SAP updates, use the ipx sap-interval interface configuration command. Step 2 Increase the output hold queue size in small increments (for instance, 25 percent), using the hold-queue out interface configuration command. Step 3 On affected interfaces, turn off fast switching for heavily used protocols. For example, to turn off IP fast switching, enter the no ip route-cache interface configuration command. For the command syntax for other protocols, consult the Cisco IOS configuration guides and command references. Step 4 Implement priority queuing on slower serial links by configuring priority lists. For information on config- uring priority lists, see the Cisco IOS configuration guides and command references. Note: Output drops are acceptable under certain conditions. For instance, if a link is known to be overused (with no way to remedy the situation), it is often considered preferable to drop packets than to hold them. This is true for protocols that support flow control and can retransmit data (such as TCP/IP and Novell IPX2). However, some protocols, such as DECnet and local-area transport are sensitive to dropped packets and accommodate retransmission poorly, if at all. |
| 1SAP = Service Advertising Protocol 2IPX = Internetwork Packet Exchange |
Input drops appear in the output of the show interfaces serial exec command (refer to Figure 15-1) when too many packets from that interface are still being processed in the system.
Symptom: Increasing number of input drops on serial link.
Table 15-3 outlines the possible problem that might cause this symptom and describes solutions to that problem.
| Possible Problem | Solution |
|---|---|
Input rate exceeds the capacity of the router or input queues exceed the size of output queues | Note: Input drop problems are typically seen when traffic is being routed between faster interfaces (such as Ethernet, Token Ring, and FDDI1) and serial interfaces. When traffic is light, there is no problem. As traffic rates increase, backups start occurring. Routers drop packets during these congested periods. Step 1 Increase the output queue size on common destination interfaces for the interface that is dropping packets. Use the hold-queue out interface configuration command. Increase these queues by small increments (for instance, 25%) until you no longer see drops in the show interfaces output. The default output hold queue limit is 100 packets. Step 2 Reduce the input queue size, using the hold-queue in interface configuration command, to force input drops to become output drops. Output drops have less impact on the performance of the router than do input drops. The default input hold queue is 75 packets. |
| 1FDDI = Fiber Distributed Data Interface |
If input errors appear in the show interfaces serial output (refer to Figure 15-1), there are several possible sources of those errors. The most likely sources are summarized in Table 15-4.
Symptom: Increasing number of input errors in excess of 1 percent of total interface traffic.
| Possible Problem | Solution |
|---|---|
The following problems can result in this symptom:
| Note: Cisco strongly recommends against the use of data converters when you are connecting a router to a WAN or serial network. Step 1 Use a serial analyzer to isolate the source of the input errors. If you detect errors, it is likely that there is a hardware problem or a clock mismatch in a device that is external to the router. Step 2 Use the loopback and ping tests to isolate the specific problem source. For more information, see the sections "Using the trace Command" and "CSU and DSU Loopback Tests" later in this chapter. Step 3 Look for patterns. For example, if errors occur at a consistent interval, they could be related to a periodic function such as the sending of routing updates. |
Table 15-5 describes the various types of input errors displayed by the show interfaces serial command (see Figure 15-1), possible problems that might be causing the errors, and solutions to those problems.
| Input Error Type (Field Name) | Possible Problem | Solution |
|---|---|---|
CRC errors occur when
| Step 1 Ensure that the line is clean enough for transmission requirements. Shield the cable if necessary. Step 2 Make sure the cable is within the recommended length (no more than 50 feet [15.24 meters], or 25 feet [7.62 meters] for T1 link). Step 3 Ensure that all devices are properly configured for a common line clock. Set SCTE on the local and remote DSU. If your CSU/DSU does not support SCTE, see the section "Inverting the Transmit Clock" later in this chapter. Step 4 Make certain that the local and remote CSU/DSU are configured for the same framing and coding scheme as that used by the leased-line or other carrier service (for example, ESF/B8ZS). Step 5 Contact your leased-line or other carrier service and have it perform integrity tests on the line. | |
A framing error occurs
| Step 1 Ensure that the line is clean enough for transmission requirements. Shield the cable if necessary. Make certain you are using the correct cable. Step 2 Make sure the cable is within the recommended length (no more than 50 feet [15.24 meters], or 25 feet [7.62 meters] for T1 link) Step 3 Ensure that all devices are properly configured to use a common line clock. Set SCTE on the local and remote DSU. If your CSU/DSU does not support SCTE, see the section "Inverting the Transmit Clock" later in this chapter. Step 4 Make certain that the local and remote CSU/DSU is configured for the same framing and coding scheme as that used by the leased-line or other carrier service (for example, ESF1/B8ZS2). Step 5 Contact your leased-line or other carrier service and have it perform integrity tests on the line. | |
Aborted transmission | Aborts indicate an illegal sequence of one bits (more than seven in a row) The following are possible reasons for this to occur:
| Step 1 Ensure that all devices are properly configured to use a common line clock. Set SCTE on the local and remote DSU. If your CSU/DSU does not support SCTE, see the section "Inverting the Transmit Clock" later in this chapter.
Step 2 Shield the cable if necessary. Make certain the cable is within the recommended length Step 3 Check the hardware at both ends of the link. Swap faulty equipment as necessary. Step 4 Lower data rates and determine whether aborts decrease. Step 5 Use local and remote loopback tests to determine where aborts are occurring (see the section "Special Serial Line Tests" later in this chapter). Step 6 Contact your leased-line or other carrier service and have it perform integrity tests on the line. |
| 1ESF = Extended Superframe Format 2B8ZS = binary eight-zero substitution |
Interface resets that appear in the output of the show interfaces serial exec command (see Figure 15-1) are the result of missed keepalive packets.
Symptom: Increasing interface resets on serial link.
Table 15-6 outlines the possible problems that might cause this symptom and describes solutions to those problems.
| Possible Problem | Solution |
|---|---|
The following problems can result in this symptom:
| When interface resets are occurring, examine other fields of the show interfaces serial command output to determine the source of the problem. Assuming that an increase in interface resets is being recorded, examine the following fields: Step 1 If there is a high number of output drops in the show interfaces serial output, see the section "Serial Lines: Increasing Output Drops on Serial Link" earlier in this chapter. Step 2 Check the carrier transitions field in the show interfaces serial display. If carrier transitions are high while interface resets are being registered, the problem is likely to be a bad link or bad CSU or DSU. Contact your leased-line or carrier service and swap faulty equipment as necessary. Step 3 Examine the input errors field in the show interfaces serial display. If input errors are high while interface resets are increasing, the problem is probably a bad link or bad CSU/DSU. Contact your leased-line or other carrier service and swap faulty equipment as necessary. |
Carrier transitions appear in the output of the show interfaces serial exec command whenever there is an interruption in the carrier signal (such as an interface reset at the remote end of a link).
Symptom: Increasing carrier transitions count on serial link.
Table 15-7 outlines the possible problems that might cause this symptom and describes solutions to those problems.
| Possible Problem | Solution |
|---|---|
The following problems can result in this symptom:
| Step 1 Check hardware at both ends of the link (attach a breakout box or a serial analyzer and test to determine source of problems). Step 2 If an analyzer or breakout box is unable to identify any external problems, check the router hardware. Step 3 Swap faulty equipment as necessary. |
The show controllers exec command is another important diagnostic tool when troubleshooting serial lines. The command syntax varies depending on platform:
Figure 15-2 shows the output from the show controllers cbus exec command. This command is used on Cisco 7000 series routers with the Fast Serial Interface Processor (FSIP) card. Check the command output to make certain that the cable to the channel service unit/digital service unit (CSU/DSU) is attached to the proper interface. You can also check the microcode version to see whether it is current.
On access products such as the Cisco 2000, Cisco 2500, Cisco 3000, and Cisco 4000 series access servers and routers, use the show controllers exec command. Figure 15-3 shows the show controllers command output from the Basic Rate Interface (BRI) and serial interfaces on a Cisco 2503 access server. (Note that some output is not shown.)
The show controllers output indicates the state of the interface channels and whether a cable is attached to the interface. In Figure 15-3, serial interface 0 has an RS-232 DTE cable attached. Serial interface 1 has no cable attached.
Figure 15-4 shows the output of the show controllers mci command. This command is used on AGS, CGS, and MGS routers only. If the electrical interface is displayed as UNKNOWN (instead of V.35, EIA/TIA-449, or some other electrical interface type), an improperly connected cable is the likely problem. Abad applique or a problem with the internal wiring of the card is also possible. If the electrical interface is unknown, the corresponding display for the show interfaces serial exec command will show that the interface and line protocol are down.
The output of the various debug privileged exec commands provides diagnostic information relating to protocol status and network activity for many internetworking events.
Following are some debug commands that are useful when troubleshooting serial and WAN problems. More information about the function and output of each of these commands is provided in the Debug Command Reference publication:
The ping command is a useful test available on Cisco internetworking devices as well as on many host systems. In TCP/IP, this diagnostic tool is also known as an Internet Control Message Protocol (ICMP) Echo Request.
Cisco internetworking devices provide a mechanism to automate the sending of many ping packets in sequence. Figure 15-5 illustrates the menu used to specify extended ping options. This example specifies 20 successive pings. However, when testing the components on your serial line, you should specify a much larger number, such as 1000 pings.
In general, perform serial line ping tests as follows:
Step 1 Put the CSU or DSU into local loopback mode.
Step 2 Configure the extended ping command to send different data patterns and packet sizes. Figure 15-6 and Figure 15-7 illustrate two useful ping tests, an all-zeros 1500-byte ping and an all-ones 1500-byte ping, respectively.
Step 3 Examine the show interfaces serial command output (see Figure 15-1) and determine whether input errors have increased. If input errors have not increased, the local hardware (DSU, cable, router interface card) is probably in good condition.
Assuming that this test sequence was prompted by the appearance of a large number of CRC and framing errors, a clocking problem is likely. Check the CSU or DSU for a timing problem. See the section "Troubleshooting Clocking Problems" later in this chapter.
Step 4 If you determine that the clocking configuration is correct and is operating properly, put the CSU or DSU into remote loopback mode.
Step 5 Repeat the ping test and look for changes in the input error statistics.
Step 6 If input errors increase, there is either a problem in the serial line or on the CSU/DSU. Contact the WAN service provider and swap the CSU or DSU. If problems persist, contact your technical support representative.
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 is better able to 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.
In general, clocking problems in serial WAN interconnections can be attributed to one of the following causes:
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% to 2.0% 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.
After you determine that clocking conflicts are the most likely cause of input errors, use the following procedure will help you 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 suggests that the other end is sending bad information or that there is a line problem.
Table 15-8 outlines suggested remedies for clocking problems, based on the source of the problem.
| Possible Problem | Solution |
|---|---|
Incorrect CSU configuration | Step 1 Determine whether the CSUs at both ends agree on the clock source (local or line). Step 2 If the CSUs do not agree, configure them so that they do (usually the line is the source). Step 3 Check the LBO1 setting on the CSU to ensure that the impedance matches that of the physical line. For information on configuring your CSU, consult your CSU hardware documentation. |
Incorrect DSU configuration | Step 1 Determine whether the DSUs at both ends have SCTE mode enabled. Step 2 If SCTE is not enabled on both ends of the connection, enable it. (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.) Step 3 Make sure that ones density is maintained. This requires that the DSU use the same framing and coding schemes (for example, ESF and B8ZS) used by the leased-line or other carrier service. Check with your leased-line provider for information on its framing and coding schemes. Step 4 If your carrier service uses AMI coding, either invert the transmit clock on both sides of the link or run the DSU in bit-stuff mode. For information on configuring your DSU, consult your DSU hardware documentation. |
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. |
| 1LBO = Line Build Out |
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.
If the situation is bad enough, you must increase the bandwidth of the link. However, increasing the bandwidth might not be necessary or immediately practical. One way to resolve marginal serial line overutilization problems is to control how the router uses data buffers.
Use one of the following three options to control how buffers are used:
The configuration commands associated with these options are described in the Cisco IOS configuration guides and command references.
The following section focuses on identifying situations in which these options are likely to apply and defining how you can use these options to help resolve connectivity and performance problems in serial/WAN interconnections.
The system buffers are associated with the main system memory and are allocated to different-size memory blocks. A useful command for determining the status of your system buffers is the show buffers exec command. Figure 15-8 shows the output from the show buffers command.
In the show buffers output
The show buffers command output in Figure 15-8 indicates high numbers in the trims and created fields for large buffers. If you are receiving high numbers in these fields, you can increase your serial link performance by increasing the max free value configured for your system buffers. trims identifies the number of buffers that the RP has trimmed from the pool when the number of buffers in free list exceeded the number of max allowed buffers.
Use the buffers max free number global configuration command to increase the number of free system buffers. The value you configure should be approximately 150% of the figure indicated in the total field of the show buffers command output. Repeat this process until the show buffers output no longer indicates trims and created buffers.
If the show buffers command output shows a large number of failures in the (no memory) field (see the last line of output in Figure 15-8), you must reduce the usage of the system buffers or increase the amount of shared or main memory (physical RAM) on the router. Call your technical support representative for assistance.
Use the hold-queue command to prevent packets from being dropped and to improve serial-link performance under the following conditions:
Priority queuing is a list-based control mechanism that allows traffic to be prioritized on an
interface-by-interface basis. Priority queuing involves two steps:
Step 1 Create a priority list by protocol type and level of priority.
Step 2 Assign the priority list to a specific interface.
Both of these steps use versions of the priority-list global configuration command. In addition, further traffic control can be applied by referencing access-list global configuration commands from priority-list specifications. For examples of defining priority lists and for details about command syntax associated with priority queuing, refer to the Cisco IOS configuration guides and command references.
Use priority queuing to prevent packets from being dropped and to improve serial link performance under the following conditions:
In general, start with the default number of queues when implementing priority queues. After enabling priority queuing, monitor output drops with the show interfaces serial exec command. If you notice that output drops are occurring in the traffic queue you have specified to be high priority, increase the number of packets that can be queued (using the queue-limit keyword option of the priority-list global configuration command). The default queue-limit arguments are 20 packets for the high-priority queue, 40 for medium, 60 for normal, and 80 for low.
If the output of the show interfaces serial exec command indicates that the serial line is up but the line protocol is down, use the CSU/DSU loopback tests to determine the source of the problem. Perform the local loop test first, and then the remote test. Figure 15-9 illustrates the basic topology of the CSU/DSU local and remote loopback tests.
Following is a general procedure for performing loopback tests in conjunction with built-in system diagnostic capabilities:
Step 1 Place the CSU/DSU in local loop mode (refer to your vendor documentation). In local loop mode, the use of the line clock (from the T1 service) is terminated, and the DSU is forced to use the local clock.
Step 2 Use the show interfaces serial exec command to determine whether the line status changes from "line protocol is down" to "line protocol is up (looped)," or if it remains down.
Step 3 If the line protocol comes up when the CSU or DSU is in local loopback mode, this suggests that the problem is occurring 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 4 If the problem appears to be local, use the debug serial interface privileged exec command.
Step 5 Take the CSU/DSU out of local loop mode. When the line protocol is down, the debug serial interface command output will indicate that keepalive counters are not incrementing.
Step 6 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. This information will appear in the debug serial interface output.
If the keepalives do not increment, there may be a timing problem on the interface card or on the network. For information on correcting timing problems, refer to the section "Troubleshooting Clocking Problems," earlier in this chapter.
Step 7 Check the local router and CSU/DSU hardware, and any attached cables. Make certain the cables are within the recommended lengths (no more than 50 feet [15.24 meters], or 25 feet [7.62 meters] for a T1 link). Make certain the cables are attached to the proper ports. Swap faulty equipment as necessary.
Figure 15-10 shows the output from the debug serial interface command for an HDLC serial connection, with missed keepalives causing the line to go down and the interface to reset.
If you determine that the local hardware is functioning properly but you still encounter problems when attempting to establish connections over the serial link, try using the remote loopback test to isolate the problem cause.
The following are the steps required to perform loopback testing:
Step 1 Put the remote CSU or DSU into remote loopback mode (refer to the vendor documentation).
Step 2 Using the show interfaces serial exec command, determine whether the line protocol remains up with the status line indicating "Serial x is up, line protocol is up (looped)," or if it goes down with the status line indicating "line protocol is down."
Step 3 If the line protocol remains up (looped), the problem is probably at the remote end of the serial connection (between the remote CSU/DSU and the remote router). Perform both local and remote tests at the remote end to isolate the problem source.
Step 5 If problems persist, contact your WAN network manager or the WAN service organization.
This section covers the show interfaces serial command's parameters, syntax description, sample output display, and field descriptions.
To display information about a serial interface, use the show interfaces serial privileged exec command:
show interfaces serial [number] [accounting]Privileged exec
This command first appeared in Cisco IOS Release 10.0 for the Cisco 4000 series. It first appeared in Cisco IOS Release 11.0 for the Cisco 7000 series, and it was modified in Cisco IOS Release 11.3 to include the CT3IP.
The following is sample output from the show interfaces command for a synchronous serial interface:
Router# show interfaces serial
Serial 0 is up, line protocol is up
Hardware is MCI Serial
Internet address is 150.136.190.203, subnet mask is 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 0:00:07, output 0:00:00, output hang never
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
Five minute input rate 0 bits/sec, 0 packets/sec
Five minute output rate 0 bits/sec, 0 packets/sec
16263 packets input, 1347238 bytes, 0 no buffer
Received 13983 broadcasts, 0 runts, 0 giants
2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
1 carrier transitions
22146 packets output, 2383680 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets, 0 restarts
Table 15-9 describes significant fields shown in the output.
| Field | Description |
Serial...is {up | down} | Indicates whether the interface hardware is currently active (whether carrier detect is present) or whether it has been taken down by an administrator. |
line protocol | Indicates whether the software processes that handle the line protocol consider the line usable (that is, whether keepalives are successful) or whether it has been taken down by an administrator. |
Hardware is | Specifies the hardware type. |
Internet address is | Specifies the Internet address and subnet mask. |
MTU | Maximum transmission unit of the interface. |
Indicates the value of the bandwidth parameter that has been configured for the interface (in kilobits per second). The bandwidth parameter is used to compute IGRP metrics only. If the interface is attached to a serial line with a line speed that does not match the default (1536 or 1544 for T1 and 56 for a standard synchronous serial line), use the bandwidth command to specify the correct line speed for this serial line. | |
DLY | Delay of the interface in microseconds. |
rely | Reliability of the interface as a fraction of 255 (255/255 is 100% reliability), calculated as an exponential average over five minutes. |
load | Load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over five minutes. |
Encapsulation | Encapsulation method assigned to the interface. |
loopback | Indicates whether loopback is set. |
keepalive | Indicates whether keepalives are set. |
Last input | Number of hours, minutes, and seconds since the last packet was successfully received by an interface. Useful for knowing when a dead interface failed. |
Last output | Number of hours, minutes, and seconds since the last packet was successfully transmitted by an interface. |
output hang | Number of hours, minutes, and seconds (or never) since the interface was last reset because of a transmission that took too long. When the number of hours in any of the last fields exceeds 24, the number of days and hours is printed. If that field overflows, asterisks are printed. |
Output queue, drops input queue, drops | Number of packets in output and input queues. Each number is followed by a slash, the maximum size of the queue, and the number of packets because the queue is full. |
5 minute input rate | Average number of bits and packets transmitted per second in the past five minutes. The five-minute input and output rates should be used only as an approximation of traffic per second during a given five-minute period. These rates are exponentially weighted averages with a time constant of five minutes. A period of four time constants must pass before the average will be within 2% of the instantaneous rate of a uniform stream of traffic over that period. |
packets input | Total number of error-free packets received by the system. |
Total number of bytes, including data and MAC encapsulation, in the error-free packets received by the system. | |
no buffer | Number of received packets discarded because there was no buffer space in the main system. Compare with ignored count. Broadcast storms on Ethernet networks and bursts of noise on serial lines are often responsible for no input buffer events. |
Received...broadcasts | Total number of broadcast or multicast packets received by the interface. |
runts | Number of packets that are discarded because they are smaller than the medium's minimum packet size. |
giants | Number of packets that are discarded because they exceed the medium's maximum packet size. |
input errors | Total number of no buffer, runts, giants, CRCs, frame, overrun, ignored, and abort counts. Other input-related errors can also increment the count, so this sum might not balance with the other counts. |
CRC | Cyclic redundancy check generated by the originating station or far-end device does not match the checksum calculated from the data received. On a serial link, CRCs usually indicate noise, gain hits, or other transmission problems on the data link. |
frame | Number of packets received incorrectly having a CRC error and a noninteger number of octets. On a serial line, this is usually the result of noise or other transmission problems. |
overrun | Number of times the serial receiver hardware was unable to hand received data to a hardware buffer because the input rate exceeded the receiver's ability to handle the data. |
ignored | Number of received packets ignored by the interface because the interface hardware ran low on internal buffers. Broadcast storms and bursts of noise can cause the ignored count to be increased. |
abort | Illegal sequence of one bits on a serial interface. This usually indicates a clocking problem between the serial interface and the data link equipment. |
carrier transitions | Number of times the carrier detect signal of a serial interface has changed state. For example, if data carrier detect (DCD) goes down and comes up, the carrier transition counter will increment two times. Indicates modem or line problems if the carrier detect line is changing state often. |
packets output | Total number of messages transmitted by the system. |
Total number of bytes, including data and MAC encapsulation, transmitted by the system. | |
underruns | Number of times that the transmitter has been running faster than the router can handle. This might never be reported on some interfaces. |
output errors | Sum of all errors that prevented the final transmission of datagrams out of the interface being examined. Note that this might not balance with the sum of the enumerated output errors because some datagrams can have more than one error, and others can have errors that do not fall into any of the specifically tabulated categories. |
collisions | Number of messages retransmitted due to an Ethernet collision. This usually is the result of an overextended LAN (Ethernet or transceiver cable too long, more than two repeaters between stations, or too many cascaded multiport transceivers). Some collisions are normal. However, if your collision rate climbs to around 4% or 5%, you should consider verifying that there is no faulty equipment on the segment and/or moving some existing stations to a new segment. A packet that collides is counted only once in output packets. |
interface resets | Number of times an interface has been completely reset. This can happen if packets queued for transmission were not sent within several seconds' time. On a serial line, this can be caused by a malfunctioning modem that is not supplying the transmit clock signal, or by a cable problem. If the system notices that the carrier detect line of a serial interface is up but the line protocol is down, it periodically resets the interface in an effort to restart it. Interface resets can also occur when an interface is looped back or shut down. |
Number of times the controller was restarted because of errors. | |
alarm indications, remote alarms, rx LOF, rx LOS | Number of CSU/DSU alarms, and number of occurrences of receive loss of frame and receive loss of signal. |
BER inactive, NELR inactive, FELR inactive | Status of G.703-E1 counters for bit error rate (BER) alarm, near-end loop remote (NELR), and far-end loop remote (FELR). Note that you cannot set the NELR or FELR. |
Posted: Tue May 16 15:10:27 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.