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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
