One of our agency circuit which is running on ATM is having some issues. We found AAL5 CRC errors are increasing on atm0/ima0 interface, but no CRC errors on physical interface such as ATM0/0/0 & ATM0/0/1.
Could anyone please let me know why these AAL5 CRC increase? Is it due to high link utilization or PDU issue or Carrier network issues?
Thanks in advance.
USA-OAK-001-CE01#sh int atm0/ima0.100 ATM0/IMA0.100 is up, line protocol is up Hardware is ATM AIM IMA Description: ---- Primary VCC to PE Suwanee - ATM1/0/1.526 - CIR 3072K ---- Internet address is MTU 4470 bytes, BW 3072 Kbit/sec, DLY 20000 usec, reliability 255/255, txload 2/255, rxload 19/255 Encapsulation ATM 30091528 packets input, 24370911593 bytes 28717558 packets output, 5471173774 bytes 64924 OAM cells input, 64924 OAM cells output AAL5 CRC errors : 22 AAL5 SAR Timeouts : 0 AAL5 Oversized SDUs : 0 Last clearing of "show interface" counters 1w0d
Interface OK? Method Status Prot ocol FastEthernet0/0 YES manual up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
ATM0/0/0 unassigned YES NVRAM up up
ATM0/0/1 unassigned YES NVRAM up up
ATM0/IMA0 unassigned YES NVRAM up up
ATM0/IMA0.100 YES manual up up
ATM0/IMA0.200 YES manual up up
Loopback0 YES manual up up
Loopback1 YES manual up up
Loopback2 YES manual up up
Tunnel1 YES TFTP up up
USA-OAK-001-CE01#sh int atm0/ima0 ATM0/IMA0 is up, line protocol is up Hardware is ATM AIM IMA MTU 4470 bytes, sub MTU 4470, BW 3072 Kbit/sec, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 17/255 Encapsulation ATM, loopback not set Encapsulation(s): AAL5 255 maximum active VCs, 1024 VCs per VP, 2 current VCCs VC Auto Creation Disabled. VC idle disconnect time: 300 seconds Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 1w0d Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 5997 Queueing strategy: Per VC Queueing 5 minute input rate 206000 bits/sec, 19 packets/sec 5 minute output rate 18000 bits/sec, 19 packets/sec 30100670 packets input, 2905370643 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 22 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 28791739 packets output, 1180798921 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out
The number of errors is negligible, less than one in a million.
So, everything is OK.
But I want to know why these AAL5 CRC errors will increase. Is it due to carrier network path, Config issues or High link utilization etc ?
a non zero bit error probability exists in data network links.
For example on fiber based links BER is typically 10^-9. Most linecodes can deal with isolated bit errors and are capable to correct them, however when the number of wrongly received bits in a single data structure like an AAL5 PDU is over the capabilities of self correction, bits are errored and CRC detects this and allows to discard the PDU because contains unrecoverable errors.
Most upper layer communication use protocols like TCP that are capable of flow control and to transmit again the packet that was carried inside the dropped AAL5 PDU, so the practical effects of these few errors are negligible as noted by Paolo.
In your case there is the added complexity of IMA, however your link is fine.
Hope to help
Could you please let me know what added complexity on our IMA link?
thanks for your kind remarks
with added complexity I was meaning the fact that the ATM cells that are part of an AAL5 PDU can be carried on the different IMA member links so reassembly of AAL5 PDU happens at the other end of IMA bundle and has to deal with this handling cells that have travelled on the different links.
A key parameter in IMA is the different delay between member links this can be a source of problems if it is more then some milliseconds
Hope to help
Nothing in particular add complexity in your case.
What Giuseppe and I are telling you, ia that a small number of error on WAN circuits it normal, it doe not affect normal operation, and you cannot do anything about it.
Please remember to rate useful posts clicking the stars below.
Final question: Whether due to high link utilization the AAL5 CRC errors will increase?
This is possible. Actual behavior will depend on you traffic contract and provider network utilization. If cell(s) of an AAL5 PDU get dropped in the carrier network (say due to you exceeding your bandwidth contract or ATM service type timing constraints or provider has increased utilization and can't do you favors when you exceed your contract at some point or provider can't satisfy your contract), the receiving endpoint of the ATM VC will see the error. Note that ATM switches are typically more strict in enforcing timing constraints than routers (which might send cells back-to-back). You do need to configure your router in accordance to your contract as much as possible to avoid misbehaving VCs. Also, have in mind that the ATM counters of the routers do not include all ATM overheads (only AAL5 and even that not completely), so your real ATM utilization (as seen in ATM cells/sec from provider's perspective) might be quite higher than you expect (depending on your average IP packet size).
Two more things. You can have a look at the following document about CRC errors on ATM interfaces: