these CRC's are calculated by ADM - atm direct mapping, so these are crc
calculated on ATM cell header minus HEC, since HEC is
used for cell delineation.
So, technically they are ATM CRC's
See if this helps you to understand the problem:
http://www.cisco.com/en/US/customer/tech/tk39/tk48/technologies_tech_note09186a00800c93ef.shtml
http://www.cisco.com/warp/public/121/atmds_framing.shtml#adm
Mike
----- Original Message -----
From: "james edwards" <hack...@cybermesa.com>
To: <cisc...@puck.nether.net>
Sent: Thursday, January 13, 2005 3:18 PM
Subject: Re: [c-nsp] CRC errors on DS3 interface
These are ATM CRC's. You can take a look at each PVC to see if CRC
errors
are associated with a specific PVC:
sh atm pvc x/y
Yes, the main interfafe does seem to be counting AAL5 CRC's from the sub
ifs
I just cleared the counters and sub ifs CRC = main interface CRC's
But there is a CRC check at the DS3 level:
alb-colo#sho controllers | include crc
rx_cell_lost=0, rx_no_buffer=0, rx_crc_10=0
rx_cell_lost=0, rx_no_buffer=0, rx_crc_10=0
rx_cell_lost=0, rx_no_buffer=0, rx_crc_10=0
rx_cell_lost=0, rx_no_buffer=0, rx_crc_10=0
rx_cell_lost=0, rx_no_buffer=0, rx_crc_10=0
rx_cell_lost=0, rx_no_buffer=0, rx_crc_10=0
rx_cell_lost=0, rx_no_buffer=0, rx_crc_10=0
rx_cell_lost=0, rx_no_buffer=0, rx_crc_10=0
rx_cell_lost=304412, rx_no_buffer=0, rx_crc_10=0, rx_no_mem=0
rx_cell_lost=0, rx_no_buffer=0, rx_crc_10=0, rx_no_mem=0
alb-colo#