[c-nsp] Re: FE ignored errors
Rodney Dunn
rodunn at cisco.com
Mon Dec 20 12:01:41 EST 2004
I'm late to the party for this thread so
I'll comment at different places to clear
up confusion.
On Mon, Dec 20, 2004 at 10:18:12AM +0800, Cameron.Dry at didata.com.au wrote:
> What you may be seeing is instantaneous bursts at line
> rate that are causing the ignores which are not visible
> on the 30 second-weighted interface counters.
You are right that short bursts are not easy to catch
in 30 second averages. Most likely though before you
can get to linerate on an FE for a VIP for average packet
sizes you will hit the ceiling for the what the VIP CPU
can handle. When you hit the CPU limit (which is very
hard to capture under bursty taffic conditions) the most
common thing you see are ignores/input errors on the interface.
>
> Turbo ACLs may also assist if you need to maintain the
> functionality, but I would guess that the only resolution
> to this problem (if it is indeed impacting performance
> noticeably) is a VIP upgrade.
I don't recommend you enable Turbo ACL's unless you have long
(at least 10+) ACL's.
>
> Regards
>
> Cameron
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of jlewis at lewis.org
> Sent: Monday, 20 December 2004 7:51 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Re: FE ignored errors
>
>
> I forgot to mention, IOS versions in use are:
>
> rsp-k91pv-mz.122-18.S5.bin
> rsp-k91pv-mz.122-18.S6.bin
>
> On Sun, 19 Dec 2004, 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.
> >
> > I've seen Rodney's post from 11-24-04 warning not to try tuning the
> > buffers, and have removed all custom hold-queue settings from the
> > config on the least busy of the 7500s, and it's still having this
> > problem.
> >
> > We're seeing this primarily on FE internet transit connections, but
> > also to some degree on internal portchannel interfaces between our
> > routers and 3550 switches that fan out to customer aggregation 3550
> > switches.
> >
> > The feature I'm guessing could be to blame is policy routing. Ever
> > since the nachi/welchia outbreak that followed blaster, I've had
> > policy routing setup on all our transit connections to block the 92
> > byte echo/echo-reply packets nachi was famous for sending to pretty
> > much the whole internet.
> >
> > I also have a short input ACL on all our transit interfaces that
> > blocks SQL slammer and the DoS mentioned at
> > http://www.lurhq.com/cisco-dos.html
> >
> > i.e. here's some config snippets from one of the routers.
> >
> > ip cef distributed
> > interface FastEthernet6/0/0
> > ip access-group slammer+ciscodosopt in
> > ip verify unicast source reachable-via any
> > no ip unreachables
> > ip route-cache flow
> > no ip mroute-cache
> > ip policy route-map nachiworm
> > load-interval 30
> > full-duplex
> >
> > route-map nachiworm permit 10
> > match ip address nachilist
> > match length 92 92
> > set interface Null0
> >
> > ip access-list extended nachilist
> > permit icmp any any echo
> > permit icmp any any echo-reply
> >
> > ip access-list extended slammer+ciscodosopt
> > permit tcp any any
> > deny udp any any eq 1434
> > permit udp any any
> > permit icmp any any
> > deny 53 any any log-input
> > deny 55 any any log-input
> > deny 77 any any log-input
> > deny pim any any log-input
> > permit ip any any
> >
> > We still get quite a few hits on 1434/udp, and what could either be
> > nachi or just people doing windows traceroute, and relatively few on
> > the odd protos DoS.
> >
> > Short of just pulling all this (the policy routing and ACL) out and
> > hoping our network isn't destroyed from within by infected customers,
> > is there any way to diagnose whats causing the ignored errors? I'm
> > not seeing anything from show buffer fail (either on the RSP or VIPs)
> > when we get bursts of ignores. Show int stat shows what I think are
> > normal values (most traffic being dcef switched, orders of magnitude
> > less being processor switched).
> >
> > FastEthernet6/0/0
> > Switching path Pkts In Chars In Pkts Out Chars Out
> > Processor 9661 2256916 12471 1185150
> > Route cache 0 0 0 0
> > Distributed cache 34054578 10195735908 18164802 8416631117
> > Total 34064239 10197992824 18177273 8417816267
> >
> > Processor load and memory (either on the RSP or VIPs) doesn't look
> > problematic.
> >
> > ----------------------------------------------------------------------
> > Jon Lewis | I route
> > Senior Network Engineer | therefore you are
> > Atlantic Net |
> > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> >
>
> ----------------------------------------------------------------------
> Jon Lewis | I route
> Senior Network Engineer | therefore you are
> Atlantic Net |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> _______________________________________________
> 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/
>
>
> ******************************************************************************
> - NOTICE FROM DIMENSION DATA AUSTRALIA
> This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately.
>
> Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.
> ******************************************************************************
>
> _______________________________________________
> 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