Hi
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:
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?
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.
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 on Troubleshooting ATM CRC Errors to see a Flash animation on the loopback line and loopback diagnostic commands.
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 on loopback line to see a Flash animation on how this command works.
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.
http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00800c93ef.shtml
Regards
Chetan umar
