[c-nsp] FE ignored errors

Rodney Dunn rodunn at cisco.com
Mon Dec 20 12:09:21 EST 2004


On Mon, Dec 20, 2004 at 10:03:46AM +0100, Gert Doering wrote:
> Hi,
> 
> On Sun, Dec 19, 2004 at 06:10:19PM -0500, Jon Lewis wrote:
> > I've recently started seeing large bursts (sometimes tens, usually
> > thousands) of input ignored errors on several 7500 routers FE
> > interfaces (rsp4, vip2-50, PA-FE-TX).  It's even happening on relatively
> > low traffic ones that are only doing about 1/5 line rate traffic.
> 
> We do also see them (on NPE-400/PA-FA-TX and on 7500/VIP2-50/PA-FE-TX).
> 
> My personal suspicion is that it's short bursts of "*lots* of small
> packets" - like "100 Mbit/s. flat for 10 seconds" - that cause some
> sort of buffer shortage, and thus input ignores.

Gert,

Usually what happens here if you see a large burst is the RX vip
can't service the RX interrupts fast enough to drain the packets
from the RX fifo buffer. We register those as ignores.

You can also see the ignores as most people talk about when
you are rx-buffering for an egress interface.  To tell if
you are rx-buffering on the ingress VIP where you are seeing
the ignores you do:

sh vip acc

and watch for the counters to go up for "in".

Serial3/1/0/1:11:
 MEMD txacc 0x0092: 4432119 in, 4976 drops (0 paks, 0/6/20 bufs) 128kbps
   No MEMD acc: 4432119 in

this means that 4432119 were rx buffered by this ingress VIP (slot 0
which in this case is a GEIP+) and 4976 were dropped because the
outbound interface was congested.  Very typical when it's an 
aggregation leased line box and you can have bursts feeding the low
speed links.

Ignores in this case are normal and the only way to stop them is
to get rx-buffering turned off (by enabled some form of QOS on
the egress side).  Then the drops will be output drops on the egress
side.

> 
> I've done some fiddling with hold-queues and buffers and whatnot (before
> reading Rodney's posting that one shouldn't do it) - but it didn't have
> any significant effect.  So I'm reading this list and hoping that someone
> else will come up with the magic bullet...

I know there are some corner cases where the amount of SRAM on the VIP
can affect the buffering capability for the VIP but I've never had
one I worked on to find the root cause where that was the problem.

The ones I have seen are when the bursts are overrunning the VIP
cpu for very short intervals and those packets show up as ignores
because it can't service the rx ring fast enough.

Very typical with low end VIPs and features enabled with dCEF given
the ingress VIP does most of the feature processing on a per packet
basis.

Not that I highly recommend it but I have seen a couple customers that
got better results from the 75xx with dCEF off because they had a
high end RSP that could switch packets and do the feature work faster
than the VIPs could do it all in distributed fashion.  The correct
thing for them to have done was to upgrade the VIPs to get more horespower
but they were moving to GSR's so they just needed a temporary workaround
and that did the trick.

Rodney

> 
> gert
> 
> -- 
> USENET is *not* the non-clickable part of WWW!
>                                                            //www.muc.de/~gert/
> Gert Doering - Munich, Germany                             gert at greenie.muc.de
> fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
> _______________________________________________
> 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/


More information about the cisco-nsp mailing list