Guest

Cisco Line Cards

Understanding the Output of show controllers on Cisco 12000 Series ATM Line Cards

Cisco - Understanding the Output of show controllers on Cisco 12000 Series ATM Line Cards

Document ID: 19880

Updated: Aug 28, 2009

   Print

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.

biterrorrate_16149.gif

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:
  • B1, B2, and B3 BIP - Indicates that the local interface is receiving SONET frames with bit parity errors.
  • FEBE - Indicates that the remote interface is receiving SONET frames with B2 and B3 errors.
If these counters are incrementing, then the ATM cells will likely be corrupted as well. The HCS errors are simply a consequence of the SONET-level problems. To resolve this problem, use the steps in Troubleshooting Bit Error Rate Errors on SONET Links.

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:
  • Partially reassembled
  • Failed the CRC-32 check
  • Received on a nonexistent VPI/VCI pair
  • Unable to be stored in any internal SAR buffers
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 leavingcisco.com.
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.

Related Information

Updated: Aug 28, 2009
Document ID: 19880