Given a seedfile with
!10.10.10.7-255
!10.10.11.21-127
!10.10.11.149-255
and a Cisco Router with address 10.10.11.132, that router will be found
because that address is NOT in the exluded ranges (! ranges). If it
has other addresses that are in those excluded ranges, those addresses
will be found, too, because they are on a device that has at least one
allowed interface. The exception at the moment is on NT, at 6.01, where
the exclusion ranges prevent the discovery of specific addresses. SO only
some of the cards would be drawn. I reported this new behavior to Support
and feel strongly that it is undesirable. It is apparently unintentional.
On all other releases and platforms, as far as I know, all interfaces will
be drawn. But the PCs, etc, in those address ranges will not be discovered,
because their addresses presumably fall fully within the excluded ranges.
Regarding positive entries: Positive single nodes will be discovered,
but don't limit discovery. They are treated as helpers to finding other
nodes. Positive address ranges, on the other hand, are supposed to limit
discovery to only those ranges. That's been that way since V3 or before.
However, if you use positive OID entries, it appears to me that positive
address ranges lose their magical effect. The order of precedence for
positive entries confuses me some. See the Installation & Configuration
manual, Chapter 7 for examples.
Another thing to keep in mind: The seedfile can be changed at any time,
and things already discovered won't be removed. So you can make it a
multi-step process if that will help. And using negative address ranges
is the best way to limit the size of the database. Using negative oids
(including !@oid 0 to keep out non-snmp nodes) causes the creation of
lots of hints, or stub objects that do impact performance although they
don't show on the map. So I try to find a balance between database size
and administrative burden. You might try negative address ranges that
match the assigned DHCP ranges to keep out the PCs, and then negative oid
ranges to keep out other groups of things you don't want, like printers,
as they show up. This will allow the complete discovery of the devices
with the oids you like, provided they have at least one address that is
allowed by your exclusion ranges. It also allows the discovery of things
you had not known were there, which is a good thing, in my opinion.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
mans.langert@se.ibm.com@tkg.com on 11/20/2000 03:08:52 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: nv-l@tkg.com
cc:
Subject: [NV-L] Re: netmon.seed configuration
So, a dynamic configuratio isn't possible then? Say a Cicso router is
installed with
address 10.10.11.132, it won't show up in the maps?!
If I run 6.01 (Unix or NT), I won't discover a device with all of the
interfaces, only the ones
included in the seedfile, but prior to 6.01 I will, is that what You say?
And, one more question to (hopefully) make me understand netmon.seed; if I
make a positive see entry
in netmon.seed, will everything else be excluded? Say I put
10.10.10.1
as the only entry, will I get only one node in the map?
Regards
Måns Langert
IBM Global Services
Phone: +46 8 793 3935
Mobile: +46 70 793 3935
E-mail: mans.langert@se.ibm.com
Leslie Clark wrote:
The only way I know of would be to exclude address ranges.
Assuming your 1.3.6.1.4.1.18 devices on 10.10.10.* are at
( or have at least one interface at) addresses 1-6, and the cisco
devices on 10.10.11.* are (or have at least one interface at)
addresses 1-20 and 128-148, I would use this in the seedfile:
!10.10.10.7-255
!10.10.11.21-127
!10.10.11.149-255
The @oid entries are only across-the-board, they cannot be
applied to specific parts of the network. The exclusions will
exclude nodes that have all of their interfaces in those ranges.
If you are on Unix, or on NT prior to 6.01, the devices you do want
to find will be discovered with all of their interfaces, provided they
have at least one interface that falls in an included range.
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|