Understanding the Output of show controllers on Cisco 12000 Series ATM Line Cards
Available Languages
Contents
Introduction
The show controller command provides hardware-related information useful to troubleshoot and diagnose issues with Cisco router interfaces. The Cisco 12000 Series uses a distributed architecture with a central command-line interface (CLI) at the Gigabit Route Processor (GRP) and a local CLI at each line card. On the Cisco 12000 Series, the output of the show controller command varies depending on the CLI used (at the GRP level or Line Card level).
This document provides information on how to interpret both sets of output.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The output presented on this document is taken from a Cisco 12016 Internet Router running Cisco IOS® Software Release 12.0(18)ST.
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 your network is live, make sure that you understand the potential impact of any command.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
show controller Under GRP CLI
The show controller output from the GRP CLI provides layer-1 information, including SONET alarms and errors. Any ATM specific-statistics are provided by the show controller output on the line card CLI.
SONET is a protocol that uses a three layer architecture, namely section, line and path. The SONET layers are shown below.
Each layer adds a certain amount of overhead bytes to the SONET frame. As a result, the show controller atm output is broken down into the following:
-
Section
-
Line
-
Path alarms and errors
Examples of each are shown below:
Note: The display given below shows only the output for interface atm6/0.
GSR#show controller atm6/0
ATM6/0
SECTION
LOF = 0 LOS = 0 RDOOL = 0 BIP(B1) = 0
Active Alarms: None
LINE
AIS = 0 RDI = 0 FEBE = 0 BIP(B2) = 0
Active Alarms: None
PATH
AIS = 0 RDI = 0 FEBE = 0 BIP(B3) = 0
LOP = 0 NEWPTR = 0 PSE = 0 NSE = 0
Active Alarms: None
HCS errors
Correctable HCS errors = 0 Uncorrectable HCS errors = 0
The following table briefly describes each alarm or error condition and provides links to existing references for further information on how to troubleshoot each alarm or error condition.
| Item | Meaning | Description |
|---|---|---|
| LOF | Loss of Frame | Number of times the interface experiences out of frame alignment problems. See Troubleshooting Physical Layer Alarms on SONET and SDH Links. |
| LOS | Loss of Signal | Number of times that the incoming optical signal is all zeros for at least 100 microseconds. Possible reasons include a cut cable, excessive attenuation of the signal, or faulty equipment. LOS state clears when two consecutive framing patterns are received and no new LOS conditions are detected. Section loss of signal is detected when an all-zeros pattern on the incoming SONET signal lasts 19 (+,-3) microseconds or longer. This defect might also be reported if the received signal level drops below the specified threshold. See Troubleshooting Physical Layer Alarms on SONET and SDH Links. |
| RDOOL | Receive Data Out of Lock | SONET clock is recovered using information in the SONET overhead. RDOOL is an inexact count of the number of times Receive Data Out Of Lock has been detected, which indicates the clock recovery phased lock loop is unable to lock to the receive stream. |
| BIP (B1) | Bit Interleave Parity | Number of received frames that has parity error at SECTION portion. See Troubleshooting Bit Error Rate Errors on SONET Links. |
| BIP (B2) | Bit Interleave Parity | Number of received frames with a parity error at LINE level. See Troubleshooting Bit Error Rate Errors on SONET Links. |
| BIP (B3) | BIP (B3) | Number of received frames with a parity error at the PATH level. See Troubleshooting Bit Error Rate Errors on SONET Links. |
| AIS | Alarm Indication Signal | Number of received AIS signals by the interface. The display indicates whether the signal is a LINE or PATH AIS. See Troubleshooting Physical Layer Alarms on SONET and SDH Links. |
| RDI | Remote Defect Indication | Number of received RDI signal by the interface. The display indicates whether the signal is a LINE or PATH RDI. See Troubleshooting Physical Layer Alarms on SONET and SDH Links. |
| FEBE | Far-End Block Error | A signal returned to the transmitting network element indicating that an erred block has been received at the receiving network element. FEBE is now called remote error indicator (REI). |
| LOP | Loss of Pointer | Reported as a result of an invalid path pointer (H1, H2) or an excess number of new data flag (NDF) enabled indications. See Troubleshooting NEWPTR Errors on POS Interfaces. |
| NEWPTR | New Pointer | An inexact count of the number of times the SONET framer has validated a new SONET pointer value (H1, H2). See Troubleshooting NEWPTR Errors on POS Interfaces. |
| PSE | Positive Stuffing | An inexact count of the number of times the SONET framer has detected a positive stuff event in the received pointer (H1, H2 bytes). See Troubleshooting PSE and NSE Events on POS Interfaces. |
| NSE | Negative Stuffing | An inexact count of the number of times the SONET framer has detected a negative stuff event in the received pointer (H1, H2 bytes). See Troubleshooting PSE and NSE Events on POS Interfaces. |
| HCS | Header Checksum | Number of times that an ATM cell failed the header checksum. ATM cell headers (not payload) are protected by a 1-byte cyclic redundancy check (CRC) called the Header Checksum (HEC or HCS). This CRC will correct single-bit errors (Correctable HCS errors) in the header and detect multiple-bit errors (Uncorrectable HCS errors). To troubleshoot this problem, determine whether the SONET layer is experiencing bit errors by looking for incrementing values of the following error counters in the output of the show controller atm command:
|
show controller Under Line Card CLI
The output of the show controller command from the line card CLI displays ATM-specific statistics. The show controller detail command is also available and displays hardware-specific statistics. Such statistics are normally useful to Cisco development engineers only and are not discussed in this document.
The Cisco 12000 Series supports two ways to gather output from the line card CLI.
-
attach <slot-number> - Use this command to access the Cisco IOS software image on a line card to monitor and maintain information on the line card. After you connect to the Cisco IOS image on the line card using this command, the prompt changes to "LC-Slot<x>#," where x is the slot number of the line card.
RTR12008#attach 1 Entering Console for 4 Port ATM OC-3c/STM-1 in Slot: 1 Type "exit" to end this session
press RETURN to get started!
LC-Slot1>en
-
execute-on - Use this command to execute commands remotely on a line card. You can use the execute-on privileged EXEC command only from Cisco IOS software running on the GRP card.
RTR12008#execute-on ? all All slots slot Command is executed on slot(s) in this chassis
RTR12008#execute-on slot 1 ? LINE Command to be executed on another slot
PTR12008#execute-on slot 1 sh controller ========= Line Card (Slot 1) =======
The following is example output of the show controller command from the line card CLI.
GSR-LC#show controller
TX SAR (Patch 3.2.2) is Operational;
RX SAR (Patch 3.2.2) is Operational;
Interface Configuration Mode:
STS-12c
Active Maker Channels: total # 1
VCID VPI ChID Type OutputInfo InPkts InOAMs MacString
999 0 9D68 UBR 0C020DE0 1044406472 0 9D682000AAAA030000000800
00000000 0 0
SAR Counters:
tx_paks 1592028614 tx_abort_packs 0 tx_idle_cells 2862571613
rx_paks 1184045134 rx_drop_paks 0 rx_discard_cells 3438990
Host Counters: rx_crc_err_packs 139694737 rx_giant_paks 0 rx_abort_paks 0 rx_crc10_cells 0 rx_tmout_paks 0 rx_unknown_paks 0 rx_out_buf_paks 0 rx_unknown_vc_paks 0 rx_len_err_paks 0 rx_len_crc32_err_paks 0
The TX SAR and RX SAR fields indicate the version of microcode running on the Segmentation and Reassembly (SAR) chip.
The Interface Configuration Mode displays as STS-Xc, which indicates a SONET link with Synchronous Transport Signal (STS) framing, or as STM-X, which indicates an SDH link with Synchronous Transport Mode (STM) framing. To change the framing type, use the atm sonet stm-4 interface-level configuration command.
The following table describes the SAR Counters and Host Counters fields. Many of the counters refer to AAL5 packets. ATM supports five ATM adaptation layers (AALs). AAL5 appends an eight-byte trailer to the common part convergence sublayer protocol data unit (CPCS-PDU). Request for Comments (RFC) 1483, Multiprotocol Encapsulation over ATM Adaptation Layer 5, defines aal5snap encapsulation, as well as defining how aal5snap encapsulation should use the AAL5 trailer.
The show controller atm 0 all command provides a single aggregate value of all CRC errors, drops, and other such counters for all PVCs configured on an interface; the ATM line cards for the Cisco 12000 Series do not maintain per-VC counters. In other words, all counters are per-interface and not per-VC. In addition, the drops shown in the output of this command record drops at the driver level. Some packets will pass the driver-level (layer-2) check, and then be dropped at the layer-3 interface input queue.
| Counter | Description |
|---|---|
| tx_paks | Number of AAL5 packets transmitted. |
| tx_abort_paks | Number of AAL5 packets that were scheduled for transmission but were not sent because the upper software layers passed a cell with VPI/VCI values that the SAR did not recognize or no longer considers valid. |
| tx_idle_cells | Number of idle cells transmitted by the line card. See ATM Control Cells Illustrated - Idle Cells, Unassigned Cells, IMA Filler Cells and Invalid Cells. |
| rx_paks | Number of AAL5 packets received as completed packets. This counter does not include packets received with an error, such as packets that are:
|
| rx_drops_paks | Number of AAL5 packets dropped by the SAR due to lack of internal SAR buffers. They may be caused when the host CPU cannot accept packets quickly enough from the SAR. |
| rx_discard_cells | Number of cells discarded due to a corrupted header, including nonexistent or unrecognized VPI/VCI values in the cell header. |
| rx_crc_err_paks | Number of received AAL5 packets with CRC errors. See CRC Troubleshooting Guide for ATM Interfaces. |
| rx_abort_paks | Number of received AAL5 packets with a length field in the AAL5 trailer set to a value of 0. |
| rx_tmout_paks | Number of partially reassembled AAL5 packets which were discarded because they were not fully reassembled within the required time period. In other words, the last cell of the AAL5 packet was not received within the required period of time. This counter also is defined in RFC 2515  . |
| rx_out_buf_paks | Number of received AAL5 packets that were dropped because no buffers were available to store the packets in the host memory. In some exceptional situations, the input line card may run out of these buffers and may indiscriminately drop that packet regardless of precedence. These buffers are carved from SAR memory, which is the 2 MB of SRAM where packets are stored before being delivered to the ToFab queues. See Understanding Per-VC Queuing Options on the 4xOC3 ATM Line Card. See also Troubleshooting Ignored Errors and No Memory Drops on the Cisco 12000 Series Internet Router. |
| rx_len_err_paks | Number of AAL5 packets with a reassembled size that differs from the size indicated by the length field in the AAL5 trailer. The two-byte length field in the AAL5 trailer indicates the size of the Common Part Convergence Sublayer Protocol Data Unit (CPCS-PDU) payload field. Two bytes is 16 bits or a maximum length value of 65,535 octets. See Understanding Maximum Transmission Unit (MTU) on ATM Interfaces. |
| rx_giant_paks | Number of AAL5 packets with a reassembled length that exceeds the value specified by the length field of the AAL5 trailer. To understand how these violations can occur, see Understanding Maximum Transmission Unit (MTU) on ATM Interfaces. |
| rx_crc10_cells | Number of cells that failed the CRC-10 checksum used by operations, administration, and maintenance (OAM) cells or raw cells. |
| rx_unknown_vc_paks | Number of AAL5 packets discarded because of non-existing or incorrect values in the VPI or VCI field, as well as unknown or unsupported values in the SNAP, NPLID, OUI, or Protocol ID fields. |
| rx_len_crc32_err_paks | Number of AAL5 packets discarded because the packets failed the CRC-32 check. The CRC field fills the last four bytes of the AAL5 trailer and protects most of the CPCS-PDU, except for the actual CRC field itself. For troubleshooting tips, see CRC Troubleshooting Guide for ATM Interfaces. |
| rx_unknown_paks | Number of AAL5 packets received with an error other than those above. |
Note: Unlike other ATM hardware, such as the PA-A3, the ATM line cards for the Cisco 12000 Series do not count SARTimeOuts and Oversized SDUs, as defined in RFC 1695.
Feedback