11-27-2009 09:35 AM - edited 03-04-2019 06:48 AM
Hi all,
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
Regards,
Karthik
11-27-2009 03:54 PM
The number of errors is negligible, less than one in a million.
So, everything is OK.
11-28-2009 09:29 AM
Thanks,
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 ?
11-28-2009 12:17 PM
Hello Karthik,
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
Giuseppe
12-05-2009 05:01 AM
Thanks.
Could you please let me know what added complexity on our IMA link?
Karthik...
12-05-2009 11:58 PM
Hello Karthik,
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
Giuseppe
12-10-2009 10:01 AM
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.
12-21-2009 02:09 PM
Thanks folks,
Final question: Whether due to high link utilization the AAL5 CRC errors will increase?
Karthik...
12-21-2009 05:15 PM
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).
12-22-2009 04:08 AM
Two more things. You can have a look at the following document about CRC errors on ATM interfaces:
Other than that (which is a general description of what might happen), I agree with Paolo and Giuseppe that in your case the number of errors reported is nothing to worry about.
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