This is my seedfile, and it works just fine...
# this is the YES-PLEASE-section ...
# Nortel-stuff which has problems with it's SNMP agent
172.21.105.240 # BC_HA
172.21.105.241 # BC_VZ
# Printers we want to manage
172.20.120.196 # PlaNet
172.20.250.250 # Wawris
10.24.89.103 # WolfRath
172.20.250.253 # Dino
172.21.1.235 # HPNG6RZ
# spo-UNISYS-stuff
172.21.110.77 # spo-b
# X-Terminals we want to manage
172.20.250.252 # NMSXS1 James
172.21.14.203 # NMSXS2 James
# this is the THANKS-NO-section...
# WTFit
!172.31.1.236 # hades-stuff
!172.31.1.237 # hades-stuff
# die (un)heiligen UNISYS-Netze...
!172.21.110.1-240
!172.22.110.1-240
!172.22.102.1-240
# HSRP- bzw. Subnet-Mask-stuffit-Stuff...?
!224.0.0.*
# let someone else manage S-Bausparkasse...
!10.254.*.*
# Spectrum-Stuff (div. Management-stations und NT-clients)
!172.20.99.60-255
!172.28.99.60-255
# generally we want SNMP-stuff only
@oid 1.3.6.1.*
# with a few exceptions (see above) we do NOT want printers
!@oid 1.3.6.1.4.1.11.2.3.9.1 # HP Network Printer
!@oid 1.3.6.1.4.1.11.2.3.9.2 # HP Network Plotter
!@oid 1.3.6.1.4.1.108.1.1.7 # Emulex NetQue Version 4.0
!@oid 1.3.6.1.4.1.253.8.62.1.1.3.1.3 # Xerox Document Centre 230ST
!@oid 1.3.6.1.4.1.253.8.62.1.1.7.1.1 # Xerox Document Centre 255ST
!@oid 1.3.6.1.4.1.253.8.62.1.3.2.1.1 # Xerox DocuPrint N24/N32/N40 Network
Laser Printer
!@oid 1.3.6.1.4.1.641.1 # Lexmark Optra SC 1275
!@oid 1.3.6.1.4.1.683.6 # ExtendNet DX
!@oid 1.3.6.1.4.1.2136.2.2 # EFI Fiery Color Printer Server
# with a few exceptions (see above) we do NOT want X-Terminals
!@oid 1.3.6.1.4.1.42.2.3.1.2 # Sun X Terminal
!@oid 1.3.6.1.4.1.82.1.12 # NCD HMXpro24 hmx_x V5.0.202 #33814
02/23/1998
!@oid 1.3.6.1.4.1.82.1.13 # NCD EXPLORApro xpl V5.0.202 #33811
02/23/1998
# MicroSoft
!@oid 1.3.6.1.4.1.311.1.1.3.1.1 # NT4-Workstation
!@oid 1.3.6.1.4.1.311.1.1.3.2 # Windows 98 - holy jeezuz!
# AXIS StorPoint CDCD-ROM ServerV4.12 Aug 12 1997
# HP CD-ROM Server compatible,AXIS StorPoint CD CD-ROM Server,Version: 4.26
!@oid 1.3.6.1.4.1.368.1.2
# end of seedfile
hth.
Regards, Ralph.
iT-AUSTRIA / OE2100 / WPNM
Tel (mobil) 0664 1908469
Tel (iT-A) 21717 58948
FAX (iT-A) 21717 58979
Mailto:Ralph.Schiffinger@erstebank.at
> -----Ursprüngliche Nachricht-----
> Von: Art DeBuigny [SMTP:debuigny@DALLAS.NET]
> Gesendet am: Freitag, 10. Dezember 1999 16:07
> An: NV-L@UCSBVM.ucsb.edu
> Betreff: Re: Best way to limit discovery
>
> Yes, definitly try that too. I tried the OID's well over a year ago. Its
> likely
> that a patch would have resolved this problem by now. (when I tried it,
> it seemed
> that if you used OID's , netmon ignored your negative address ranges)
>
> Good luck!
>
> Art DeBuigny
> Bank of America Network Operations
> debuigny@dallas.net
>
> Leslie Clark wrote:
>
> > My experience with this has been different. If you also have the
> negative
> > address range, you do NOT get stub objects for nodes in those ranges.
> > The stubs are created for things that might change into something that
> > is supposed to be discovered, and those stubs are repolled periodically.
> > Nodes with addresses in the excluded range are not going to change,
> > so no stubs are created.
> >
> > If you have NO address exclusion, and use positive oids, then yes, every
> > address discovered will result in a stub that gets checked daily to see
> if
> > it's oid has changed to something acceptable.
> >
> > Cordially,
> >
> > Leslie A. Clark
> > IBM Global Services - Systems Mgmt & Networking
> > Detroit
> >
> >
> ==========================================================================
> ======
> > Jim;
> >
> > Be very careful in using OID's in your seed file. When an OID is
> contained
> > in a
> > seed file, NetView will create a stub object in your database for EACH
> and
> > EVERY
> > device it finds on your network. These objects are not real objects,
> but a
> > sort
> > of a marker telling NetView not to consider that device again in
> > autodiscovery.
> > Still, depending on the size of your network, you are talking about a
> very
> > huge
> > database just to keep all those stubs lying around.
> >
> > If your going to use OID's, you might as well use only OID's. That way,
> > you
> > will only discover the OID's in your seed file, and you don't have to
> worry
> > about IP address ranges at all.
> >
> > But what I would do is try and document your hubs and add them manually
> > using
> > the loadhosts command. We have found that if you can't define a range
> of
> > ip
> > addresses for a particular type of object, it is a big hassle trying to
> > keep the
> > NetView database clean of extraneous devices.
> >
> > Art DeBuigny
> > Bank of America Network Operations
> > debuigny@dallas.net
> > art.debuigny@bankofamerica.com
> >
> > "Brunke, Jim (FUSA)" wrote:
> >
> > > We are building a Netview server which will exclusively manage
> routers,
> > > switches and hubs on our network - and I need some advice on the best
> way
> > to
> > > setup for initial discovery.
> > >
> > > We have build a seedfile which contains an entry for each our routers
> &
> > > switches. The first 5 address of a subnet is reserved for router
> > interfaces
> > > so we limit discovery of other nodes in the network (servers and
> > > workstations) by excluding all other addresses, ie:
> > >
> > > !167.85.*.6-254
> > > !168.118.*.6-254
> > >
> > > One problem is that we do not have a well defined list of IP addresses
> > for
> > > all of the hubs on the network. They are a combination of Cisco and
> Bay
> > > hubs. Could I also add two @OID entries into the seedfile to discover
> > these
> > > nodes? I know if you list an snmp reachable IP address in the
> seedfile,
> > it
> > > will ignore the ! range exclusion and discover the node. Does the
> @OID
> > work
> > > similarly?
> > >
> > > Thanks, in advance
|