Constantly I see error on my E1 line. I have replaced cable and requested loopback test from telco. Be more specific, i am seeing crc error or input error. There are not much documents regarding this kind of error on cisco website. Just wondering if anyone experience this and find a better way to troubleshoot.
sorry i didn post more information. this is ATM over E1 line. show controller e1 does not show any error. but show atm 0/1/0.1 and errors are there.
E1 0/1/0 is up. Applique type is Channelized E1 - balanced Cablelength is Unknown No alarms detected. alarm-trigger is not set Version info Firmware: 20080918, FPGA: 13, spm_count = 0 Framing is CRC4, Line Code is HDB3, Clock Source is Line. CRC Threshold is 320. Reported from firmware is 320. Data in current interval (854 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Total Data (last 24 hours) 0 Line Code Violations, 0 Path Code Violations, 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins, 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
ATM0/1/0.1 is up, line protocol is up Hardware is ATM AIM E1 Internet address is MTU 4470 bytes, BW 1920 Kbit/sec, DLY 20000 usec, reliability 255/255, txload 30/255, rxload 53/255 Encapsulation ATM 53776803 packets input, 22158677113 bytes 47372580 packets output, 12455388461 bytes 13 OAM cells input, 0 OAM cells output AAL5 CRC errors : 1914 AAL5 SAR Timeouts : 0 AAL5 Oversized SDUs : 0 Last clearing of "show interface" counters 5d17h
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.
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).
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...