[c-nsp] ASR9000 Input MIB CRC

Curtis Piehler cpiehler2 at gmail.com
Sat Mar 23 14:26:33 EDT 2019


The rate at which these CRCs come in so quick that it is difficult to clear
both the router and switch counters at the same time to get an exact
match.  However, bear in mind the human delay is 1-2 seconds between
hitting "enter" to clear the counters on the devices, yes they do appear to
match on both sides.  The frequency of these Input MIB CRC is quite
literally 5 every second. It is a consistent increase every second.  Over a
couple minute time frame I already have 500+ CRC errors accrued.

On Sat, Mar 23, 2019 at 1:29 PM Saku Ytti <saku at ytti.fi> wrote:

> Hey Curtis,
>
> > One of the Bundle members appears to be accruing active Input MIB CRC
> which
> > then reflects on standard Input CRC errors.  These accruing errors do not
> > seem to be service impacting as there is 500M-1G of traffic on the
> physical
> >     Input error CRC             = 2635490
> >     Input MIB CRC               = 2635490
> > The Nexus 5k side just indicates accruing "Output Errors" under the
> > interface with no further details.  The actual counter error output of
> the
> > interface sees nothing.
>
> Do the counts match? ASR9k CRC input and Nexus 5k output errors?
>
> I believe 5596 supports cut-through switching so CRC is detected after
> frame has been sent. So possibly:
>
> A => 5596 => ASR9k
>
> A>5596 transit is breaking your frames or broken memory in 5596 and
> ASR9k is dropping them on ingress due to FCS/CRC check.
>
> And I'd be surprised if it is not service affecting, what ever frames
> those are, they are not delivered. Voice with modern codecs is very
> insensitive to quality, tolerates massive packet losses and jitter.
> Couple CRC errors here and there wouldn't matter at all.
>
> --
>   ++ytti
>


More information about the cisco-nsp mailing list