[c-nsp] high CPU with snmp IS THERE A REAL FIX

[Dale W. Carder]

To answer your subject: no.

On Feb 10, 2009, at 1:22 PM, Jeff Fitzwater wrote:
>
> We use snmp getnext and getbulk to get the ARP table from a router  
> that has ~16K entries and it takes about 10min to complete, with  
> ROUTER CPU at 100%.   Our other routers have the same hardware and  
> IOS but have <10K entries and work fine.

Same here.  It's been that way for what seems like a long time though.

> In the attached PDF from CISCO they explain the problem and also  
> state the if you turn on CEF (has always been on for long time) that  
> it is much faster since the FIB is already in a lexical order that  
> snmp likes.   Since CEF is always on, why does it still take so long.

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00800948e6.shtml

That document seems pretty dated and/or doesn't fit tcam based
architectures.

The solution could come in a couple of different forms:
- a processor faster than what shipped in my cell phone
(perhaps you would have had an rsp720 by now on 6500 had the
6500/7600 customer alienation not occurred, yada yada, Gert
takes a deep breath)
- maintaining a new datastructure in memory just to speed up
these sorts of things.
- finding a better sorting algorithm.
- create a new mib that returns the values in hardware order.

> At this point we basically cannot do any retrieval of the ARP  tables.

> Currently we use an expect script to get the table via CLI which is  
> much faster

That's what we do too, and we also scrape the ipv6 neighbor cache.
This all gets stuffed into sql.

> but it doesn't help tools that must use snmp.

I'm guessing you're referring to something that wants to use
the arp table to help with topology discovery?  I'll admit we
gave up on that long ago, too.

Dale