nv-l
[Top] [All Lists]

Re: SNMP Polling Behavior

To: nv-l@lists.tivoli.com
Subject: Re: SNMP Polling Behavior
From: davids@ibk.com.au
Date: Thu, 22 Feb 2001 16:48:56 +1100
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


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web