nv-l
[Top] [All Lists]

Re: [nv-l] netmon and seedfile

To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] netmon and seedfile
From: Bill Evans <wvevans@epix.net>
Date: Fri, 26 Nov 2004 13:06:36 -0500
Delivery-date: Fri, 26 Nov 2004 18:07:16 +0000
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <OF9FC1E8BD.A4B37711-ONC1256F58.002D2B91-C1256F58.002EB6C1@carrefour.com>
References: <OF9FC1E8BD.A4B37711-ONC1256F58.002D2B91-C1256F58.002EB6C1@carrefour.com>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com
User-agent: Mozilla Thunderbird 0.9 (Windows/20041103)
I would imagine that your netmon queues are clogged with the 3800 entries in the seed file for awhile. Discover is database and network access intensive. All the discovery going on is competing with your regular status polling. But that's only the start.

I suspect that the "!@OID 0" slows things down as well. The netmon daemon will try an SNMP query on every IP address it finds in the ARP caches (as I understand it) in order to identify which items are not SNMP capable. It cuts down on the size of the database but adds discovery overhead. Hopefully it will only be trying it on the contents of the 10.*.*.* and 130.*.*.* networks found in the ARP caches of your routers but that can be a lot of addresses. Without negative entries it will try every IP address it encounters for SNMP. It depends on what order the filters are applied and my failing memory says the last test applied is for the positive range. (Someone please correct me if I'm wrong. The chart I once prepared on this is lost in the disk clutter.)

The recommended way to do this is to tightly control your seed file with* negative address ranges*. For example, in my installation we do not monitor the workstations and all workstation addresses are assigned by DHCP between xx.xx.xx.135 and xx.xx.xx.254. The routers, switches and servers we monitor are between xx.xx.xx.1 and xx.xx.xx.134. If the rules were followed strictly we should be able to start with the entries !1-9.*.*.*, !10.*.*.135-254 !11-145.*.*.*, !146.*.*.135-254 and !147-255.*.*.* to exclude all workstations. (Reality is that I have about 100 entries to just exclude the various DHCP ranges by subnet.) The best recommendation you can find in the archives is to discover the network in stages (and with patience). Once you're sure of your address ranges you can add the "!@OID 0" to cut down the size of the database and rediscover. The ultimate seed file blocks everything except the specific devices you know you want to monitor by address range. You pay in initial configuration time and overhead and save in daily operation.

Javier Morate Guerrero wrote:



     Hi,

     NetView 7.1.4 FP2   AIX 5.1

     I have a seedfile as:

     @limit_discovery
     10.*.*.*
     130.*.*.*
             .....
             .....
     10.71.203.241   #router cisco
     10.71.203.242   #router cisco
             .....
             .....
     !@oid 0
             .....

     (about 3800 lines)

     I have active the option: DISCOVERY NEW NODES

     My problem:
           Netmon is delayed enough, although the machine is to less of
  50% of CPU. If I quit DISCOVERY NEW NODES, netmon is precise. What's
  happening?


      Un saludo,

Francisco Javier Morate Guerrero
Dpto. Gestión de Sistemas
Carrefour España
jmorate@carrefour.com




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

Archive operated by Skills 1st Ltd

See also: The NetView Web