AAL5 CRC errors on ATM IMA Interface.

Unanswered Question
Nov 27th, 2009
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
paolo bevilacqua Fri, 11/27/2009 - 15:54
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

The number of errors is negligible, less than one in a million.


So, everything is OK.

Karthik B V Sat, 11/28/2009 - 09:29
User Badges:

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 ?

Giuseppe Larosa Sat, 11/28/2009 - 12:17
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

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

Karthik B V Sat, 12/05/2009 - 05:01
User Badges:

Thanks.

Could you please let me know what added complexity on our IMA link?



Karthik...

Giuseppe Larosa Sat, 12/05/2009 - 23:58
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

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

paolo bevilacqua Thu, 12/10/2009 - 10:01
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.

Karthik B V Mon, 12/21/2009 - 14:09
User Badges:

Thanks folks,

Final question: Whether due to high link utilization the AAL5 CRC errors will increase?



Karthik...

marikakis Mon, 12/21/2009 - 17:15
User Badges:
  • Gold, 750 points or more

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).

marikakis Tue, 12/22/2009 - 04:08
User Badges:
  • Gold, 750 points or more

Two more things. You can have a look at the following document about CRC errors on ATM interfaces:

http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00800c93ef.shtml#reasonsforatmcrcerror

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.

Actions

This Discussion