06-03-2010 08:26 AM - edited 03-04-2019 08:40 AM
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.
06-03-2010 08:28 AM
Usually CRC errors are a clocking issue. Can you post the results of "show controllers t1"?
Edit: "show controllers e1"
HTH,
John
06-03-2010 08:33 AM
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
06-03-2010 08:39 AM
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).
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
06-03-2010 08:47 AM
very informative! Let me give me try and let you know.
Thank you!!
06-03-2010 08:49 AM
Your Welcome
Regards
Chetan Kumar
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide