[c-nsp] ATM CRC errors

[F. David Sinn]

The CRC's can be related to lost cell's, since if a component cell (or 
cells) of a AAL5 encapsulated frame are lost, the resultant frame will 
no longer pass CRC checks when the re-assembly is attempted.

Qwest is correct in saying that discarded cells are most likely the 
cause, and unless they can tell you which VC they are discarding you 
on, you may be out of luck to find out which path is the troublemaker.  
If memory serves, a "sho atm vc" might tell you which VC is having the 
encapsulation error, but it's been years since I had to work on ATM on 
a day-to-day basis, so that may not be the case.

If you have contracted services that Qwest is policing, you may want to 
double check the shaping on your ends to insure the two match up so as 
to remove the CRC's.

If there is no policing and this is just a best effort service, then 
CRC's are a fact of life.

David

On Oct 27, 2004, at 10:48 AM, James Hamilton wrote:

> Hi there, we've got an ATM DS3 to Qwest (our telco) for Qwest based 
> T1s and
> DSL.  It's taken ~588 input CRC errors in the last 20 minutes.  The 
> count for
> the last week was ~140,000 CRC's.  I've been unable to match these CRC 
> errors
> to the counters for my interfaces.  There were about 100,000 CRC's 
> that I
> couldn't match to any interface except the main atm1/0 interface.
>
> We've checked the physical line, Qwest has monitored the port.  They 
> are
> telling me that discarded cells are the cause.  If that is the case 
> shouldn't
> I be able to match the main interface CRC counter to the CRC counters 
> for all
> my subinterfaces?  Any insight would be appreciated.
>
> Thanks
>
> -- 
>
> James Hamilton
> Southwest Cyberport
> http://www.swcp.com
> 505-232-7992		
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>