ATM CRC errors and input drops

[-cybermen]

Hello

I have a problem with trobuleshooting ATM interface errors.

On my atm interface i noticed high number of drops and flushes and some CRC errors can somebody help me to figre out what can be the reason of the errors.

This is the output of sh interface command.

ATM4/ima0 is up, line protocol is up

Hardware is IMA PA

MTU 4470 bytes, sub MTU 4470, BW 5760 Kbit, DLY 20000 usec,

reliability 255/255, txload 63/255, rxload 206/255

Encapsulation ATM, loopback not set

Keepalive not supported

Encapsulation(s): AAL5

1535 maximum active VCs, 1 current VCCs

VC idle disconnect time: 300 seconds

0 carrier transitions

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 1d00h

Input queue: 4/75/2049/108899 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: Per VC Queueing

10 minute input rate 4655000 bits/sec, 608 packets/sec

10 minute output rate 1427000 bits/sec, 650 packets/sec

24954338 packets input, 2798748329 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicast)

0 runts, 0 giants, 0 throttles

144520 input errors, 144520 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

26842881 packets output, 4208883309 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

[sumanth_myneni]

Hi,

The errors that accounted were CRC which stands for Cyclic Redundancy Check. CRC Errors generally account due to physical media issues.

Try clearing the counters and checking the output after a couple of hours.If the crc errors are increasing,check the ATM link.

Sumanth

[wochanda]

I'm seeing 2 problems here:

1. Input drops/flushes

2. CRC errors

What they mean/how to troubleshoot

1. Input drops/flushes

The ATM input queue is only used to store packets that need to be process switched by the CPU. When this input queue fills up, you get drops, and it generally tells you that the CPU couldn't make a switching decision in time to keep up with the packets coming in. Flushes also happen in this scenario, except they are proactive discards made as an attempt to make room for control packets.

More info on these errors:

http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2030/products_password_recovery09186a008009478b.shtml

The most likely reason for these errors is that packets aren't being CEF switched. Please make sure you have 'ip cef' enabled globally, and you dont have 'no ip route-cache' on any of your interfaces. If these conditions are met, and a 'show ip cef' shows good looking output, you can do a 'show cef not' to see why packets are still being process switched. The most likely reason is that they are destined for the router, which increments under the 'receive' column.

2. CRCs

These increment when a frame comes in that fails the CRC-check, which means the frame has been changed, and thus is unusable. With ATM links, a common cause is the ATM cloud dropping cells. When a single ATM cell is dropped, the packet it was carrying cannot be properly reassembled, thus it is a CRC. If you aren't conforming to the CIR given by your provider, they could be policing your traffic by dropping cells. Please check your service agreement with the provider, and make sure it matches your configuration.

Another cause could be high-CPU utilization on the router somehow messing up the CRC calculation. If this is the case, the fix for the input drops will also clear this up.

Hope this helps

[wochanda]

Accidently pasted in the wrong CCO link for input drops, here is the right one:

http://www.cisco.com/en/US/products/hw/modules/ps2033/products_tech_note09186a00800ac5a8.shtml

[lizatwork]

How can I simulate customer traffic other than using extended pings. My situation involves crc errors that occur only when our client moves traffic to the interface. When I send extended pings, 5000 at mtu 1500 for 15 minutes, I do not see crc errors. I don't think I am creating the volume that is needed to see the errors. Is there another way to simulate client traffic?

[Joseph W. Doherty]

You could load the link with a traffic generator. Often I find one that pushes UDP packets at a specified rate makes a good crude method to load up a link.

PS:

I believe I recall CRC, on ATM, might also be counted for packets had lost a cell. Believe this could be confirmed with one of the ATM stat commands (sorry don't recall exact command). If this is happening, cause is usually traffic bursting above PCR.

[paolo bevilacqua]

Joseph is correct, CRC on ATM can mean cell drop by a network that doesn't support early packet discard.

Check you traffic parameters with SP and on PVC configuration.