Hi Kent,
the reason for high CPU-Load is, as David explained, the polling of the
ipNetToMediaNetAddress - table. The values are polled using the snmp "getnext "
- command. As the output is expexted to be sorted, for each getnext the
cisco-box sorts all entries in the table, in your case it has to sort 720 times
the table of 720 entries. One solution is to turn off discovery, as told by
David. Another possibility is to limit the number of entries netview polls from
your box:
Options -> snmp Configuration -> Number of Route Entries : xx
This limits the number of polls for this table, the value for xx I use is 50.
Discovery of new nodes might be slower, but I never experienced problems in
this direction, and you don't have to turn off discovery completely. Play with
the number to find the best solution for your problem.
Michael Seibold
GEK Gmünder Ersatzkasse
>>> davids@ibk.com.au 22.02.2001 06.48 Uhr >>>
Kent,
The sequence of events you are seeing is not related to status or
configuration polling by Netview.
It is merely Netview looking for new devices during idle periods as part of
New Node Discovery. One of the ways it does this is to retrieve the arp
cache (ipNetToMediaNetAddress) from the router to look for new devices on
the subnets attached to this router. If it finds new entries it will then
ping and SNMP poll the new devices.
Simplest solution is to turn off New Node Discovery.
I would also suggest this router must be running pretty close to the edge
for this to create a problem. Are you doing a lot of filtering or
prioritisation on the router?
Regards,
David Steed
IBK Pty Ltd
>Date: Thu, 22 Feb 2001 09:09:49 +1100
>From: Kent_Allison@advantra.com.au
>Subject: SNMP Polling Behavior
>
>Hi Everyone,
>
>We've recently had an occurrence of a NetView 6.0.1 (on Solaris 2.7)
>causing a Cisco 4700 router running IOS 11.0 with DLSW circuits to lock up
>with CPUHOG values around 4500 (they're due to be decommissioned hence the
>IOS hasn't been upgraded). The router support people did a trace and
found
>the following sequence:
>
>1. Ping
>
>2. Walking the SNMP tree for all .1.3.6.1.2.1.4.22.1.3.7, which is
>ipNetToMediaNetAddress; it maps things like
>.1.3.6.1.2.1.4.22.1.3.7.10.1.2.3 => 10.1.2.3. This appeared unlimited
and
>retrieved about 720 entries.
>
>3. Two well-behaved GETs - ifNumber, sysName
>
>4. Walking the SNMP tree for all .1.3.6.1.4.1.9.9.23.1.2.1.1.6, which is
>the CDP discovery table. It retrieved 9 entries. This seems limited, since
>there are 25 entries in this table on this router.
>
>5. Two more pings.
>
>To make matters worse this was occurring every 40 minutes. The only thing
>which appears excessive is the walk of all the ipNetToMediaNetAddress
>branch.
>
>The other relevant factors are the routers in question were not being SNMP
>status polled and that the SNMP configuration applying to them was the
>"global default" of:
>
># Timeout 4 secs
># Retries 2
># Fixed Poll Interval 2 hours
># Discovery Interval 1 week
># Config check interval 1 day
># Route entries to retrieve 10
>*.*.*.*:public:*:40:2:7200:::604800:604800:86400:10:1:0:1
>
>Also, I had been swopping the SNMP configuration from a "drp"
configuration
>(above) to "production" configuration as part of troubleshooting another
>issue. I wont post the script used to do this here but suffice it to say
>that xnmsnmpconf was used with the clearcache and import parameters.
>
>Now to the questions (sorry for the long append).
>
>Does anyone have any ideas why NetView ended up "ignoring" it's polling
>settings and "hit" the routers every 40 minutes?
>
>Can anyone confirm that the get of the ipNetToMediaNetAddress branch is
>part of a config check, or is it something else? Indeed, does anyone know
>what exactly SNMP information is retrieved during config checking and
>discovery polling?
>
>Does the SNMP configuration option to number of route entries retrieved
>also limit the number of entries retrieved from the CDP table?
>
>Finally, given that the routers aren't about to be upgraded, does anyone
>have any recommendations on how to limit SNMP to these boxes (without
>unmanaging them (and without disabling SNMP on the routers themselves)?
>
>Thank you for your time.
>
>Cheers,
> Kent
|