CRC Troubleshooting Guide for ATM Interfaces

Introduction

This document can help you to determine the reasons behind cyclic redundancy check (CRC) errors on your ATM interface.

Before You Begin

Prerequisites

There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

CRC Overview

The output of show interfaces commands on Cisco devices includes numerous counters. One such counter is CRC, which counts the number of times (that is, for how many packets) the checksum generated by the originating station, or far end device, does not match the checksum calculated from the data received. By doing this, CRC detects changes to a protocol data unit (PDU) during transmission. It is important that we retain the true value of this PDU because we want to ensure that the destination correctly interprets the data that we're communicating.

CRC errors typically indicate noise, gain hits or transmission problems on the data link, or on the interface itself. On an ethernet segment, CRC errors result from collisions or from a station transmitting bad data. On an ATM interface, CRC errors also occur when the ATM network provider drops some cells of a total packet in the switch "cloud". This can be done to police the number of cells and bits per second you are transmitting. You can obtain more information on policing by clicking here. The ATM interface detects these lost cells when the segmentation and reassembly (SAR) function reassembles the cells to create a complete packet again. Thus, CRC errors on ATM interfaces may point to a mismatch in traffic shaping and traffic policing parameters.

Note:  The input errors counter tracks the total number of CRCs, "no buffers", runts, giants, frames, overruns, ignored, aborts and other input-related errors. The input errors counter is therefore either the same as, or higher than, the CRC counter. The occurrence of errors and the input and output difference should not exceed one percent (1.0 %) of traffic on the interface.

Here is an example of show interfaces command output:

Router#show interfaces atm 4/0  
    ATM4/0 is up, line protocol is up 

    Hardware is cxBus ATM 
    Internet address is 131.108.97.165, subnet mask is 255.255.255.0 
    MTU 4470 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255    
    ATM E164 Auto Conversion Interface 
    Encapsulation ATM, loopback not set, keepalive set (10 sec) 
    Encapsulation(s): AAL5, PVC mode 
    256 TX buffers, 256 RX buffers, 1024 Maximum VCs, 1 Current VCs 
    Signalling vc = 1, vpi = 0, vci = 5 
    ATM NSAP address: BC.CDEF.01.234567.890A.BCDE.F012.3456.7890.1234.13 
    Last input 0:00:05, output 0:00:05, output hang never 
    Last clearing of "show interface" counters 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 
        144 packets input, 31480 bytes, 0 no buffer 
        Received 0 broadcasts, 0 runts, 0 giants 
        13 input errors, 12 CRC, 0 frame, 0 overrun, 1 ignored, 0 abort 
        154 packets output, 4228 bytes, 0 underruns 
        0 output errors, 0 collisions, 1 interface resets, 0 restarts  

Which CRC Are We Checking?

ATM supports five ATM adaptation layers (AALs). AAL5 appends an eight-byte trailer to the common part convergence sublayer protocol data unit (CPCS-PDU), which consists of the original layer-3 packet (for instance, an IP packet) before it segments into 53-byte cells. When you configure a permanent virtual circuit (PVC) with the encapsulation aal5snap command, you are telling it to use this AAL5 trailer. You also are specifying a Logical Link Control (LLC) or Subnetwork Access Protocol (SNAP) header, which is similarly used with Ethernet.

Note: On Cisco routers, the terms "frame", "AAL5 frames" and "CPCS-PDU" all refer to the same concept when we talk about ATM interfaces.

Request for Comments (RFC) 1483 , Multiprotocol Encapsulation over ATM Adaptation Layer 5, defines aal5snap encapsulation, as well as how it should use the AAL5 trailer. CRC fills the last four bytes of the trailer and protects most of the CPCS-PDU, except for the actual CRC field itself.

Several models of ATM interface are available for use with Cisco routers. Some models support per-VC (virtual circuit) counters, while others count errors for the total interface only.

Per-VC counters simplify the task of isolating CRC errors to a particular VC. For example, when you use a PA-A3, you can gather per-VC CRC statistics by first using the show atm pvc vpi/vci command to display the VCs.

Note: When you do this, take note of the column name that displays the locally significant virtual circuit descriptor (VCD) you have specified (this is sometimes automatically specified by the system) and the configured VPI/VCI pairs. Next, use the show atm pvc command to see the per-VC information.

Let's look at an example:

7206-1#show atm vc 
VCD / Peak Avg/Min 
Burst 
Interface Name VPI VCI Type Encaps    SC Kbps Kbps 
Cells  Sts 
2/0     1  2   3   PVC F4-OAM    UBR 2000   UP 
2/0     2  2   4   PVC F4-OAM    UBR 2000   UP 
2/0     10 4   55  PVC SNAP      UBR 155000 UP 
2/0.125 40 40  45  PVC NLPID     UBR 155000 UP 
2/0.125 50 45  45  PVC NLPID     UBR 155000 UP 
4/0.2   1  16  32  PVC SNAP      UBR 149760 UP 
6/0     1  10  100 PVC SNAP      UBR 44209  UP
7206-1#show atm pvc ? 
ppp PPP over ATM information 
interface 
<0-255>    VPI/VCI value(slash required) 
<1-65535>  VCI 
WORD Connection Name | Output modifiers   

7206-1#show atm pvc 10/100 
ATM6/0: VCD: 1, VPI: 10, VCI: 100 
UBR, PeakRate: 44209 
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0 
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s), 
OAM retry frequency: 1 second(s) 
OAM up retry count: 3, OAM down retry count: 5 
OAM Loopback status: OAM Disabled 
OAM VC state: Not Managed 
ILMI VC state: Not Managed 
InARP frequency: 15 minutes(s) 
Transmit priority 4 
InPkts: 0, OutPkts: 116261, InBytes: 0, OutBytes: 4999250 
InPRoc: 0, OutPRoc: 116261, Broadcasts: 0 
InFast: 0, OutFast: 0, InAS: 0, OutAS: 0 
InPktDrops: 0, OutPktDrops: 0 
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
OAM cells received: 0 
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0 
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0 
OAM cells sent: 0 
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutRDI: 0 
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0 
OAM cell drops: 0 
Status: UP

RFC 2515 defines CrcErrors as follows:

al5VccCrcErrors OBJECT-TYPE 
SYNTAX      Counter32 
MAX-ACCESS  read-only 
STATUS      current 
DESCRIPTION 
"The number of AAL5 CPCS PDUs received with CRC-32 errors on 
this AAL5 VCC at the interface associated with an AAL5 entity." 
::= { aal5VccEntry 3 }

Reasons for ATM CRC Errors

The following are some potential reasons for ATM CRC errors:

• Dropped cells due to traffic policing in the ATM cloud on one or more VCs attached to the ATM interface.

• Noise, gain hits, or other transmission problems on the data-link equipment.

• A faulty or failing ATM interface.

The show interfaces command output displays the CRC error count. These errors suggest that when the SAR reassembles the packet and checks the CRC, the calculated CRC value does not match the value in the assembled packet's CRC field.

Troubleshooting Steps

To determine the reason for the problems you are experiencing, follow the troubleshooting steps listed below:

1. Determine if the CRC counter is incrementing or whether it is a historical value from a problem that has now been corrected.

   • Execute the show interfaces atm command several times over a few hours or days.

   • Clear the counters if appropriate for easier troubleshooting.

   • Is the circuit new? Has it ever worked without CRC errors?

2. Determine when the CRC errors occur.

   • Do they occur during certain times of the day or during periods of high traffic? If so, you may be exceeding the traffic shaping parameters agreed with your ATM service provider.

   • Look into the switch cloud and determine whether there is congestion. This might involve asking the service provider.

   • Confirm your traffic shaping parameters with your provider. Ask your provider if he/she sees any cells with the cell loss priority (CLP) bit in the ATM header set to one (1). Has the service provider recorded dropped cells on its switch interfaces?

   • Test the line using pings with various IP packet sizes, click here for more details.

3. Determine whether the hardware may have failed.

   • Try swapping the hardware or ports.

   • Conduct a local loopback test wherein you ping your own interface. You can find more details on loopbacks here.

   • Create a soft loopback with the loopback diagnostic and atm clock internal commands on the main ATM interface. Loopback diagnostic loops transmit to receive on the local interface only and effectively isolates the network or data link.

     Note: ATM interfaces typically derive clocking from the line. When placed in loopback diagnostic, the ATM interface cannot derive clocking from the line, so you need to use the local oscillator with the atm clock internal command. If appropriate, be sure to return the clock source to the line after this test.

   • Create a hard loopback and connect the fiber strand to go from the transmit side (TX) to the receive side (RX).

     Click Troubleshooting ATM CRC Errors to see a video on the loopback line and loopback diagnostic commands.

4. Perform loopback tests on the line to determine whether the CRC errors point to noise or other transmission problems.

   • Create a test PVC on the two ATM interfaces and assign IP addresses. If possible, create a point-to-point subinterface. Then conduct extended ping tests using various byte sizes. Do CRCs increment with certain packet sizes?

   • Use the loopback line command on the remote ATM router interface. The loopback line command loops the remote end's receiver back to the transmitter, so that the local interface now performs the SAR reassembly function. If the remote interface has logged CRCs, do the CRCs follow to the local interface with the remote interface in loopback line? If so, the results suggest that the Cisco hardware functions properly and that the transmission path introduces the problem.

     Click loopback line to see a video on how this command works.

5. Log the debug information generated by debug atm errors. This debug command is non-intrusive and can typically be enabled on an interface in production.

By carrying out these steps, you should be able to find the cause of the CRC errors you are encountering.