Well,
...THIS was the date of my last ovtopofix...
-rw-r--r-- 1 root bin 4711806 Dec 09 09:15 /usr/OV/log/db_res.log
...with...
8812 objects found in ovwdb.
...before ovtopofix started it's removing, and...
1140 objects found in ovwdb.
1140 valid nodes in ovwdb.
...after ovtopofix had finished.
...Right now (Fri Dec 10 17:26:14 NFT 1999) I've got...
20784 objects in object database.
Which should account for a lot of stubs.
But they do not seem to cause any harm at all ;-)
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: Leslie Clark [SMTP:lclark@US.IBM.COM]
> Gesendet am: Freitag, 10. Dezember 1999 17:12
> An: NV-L@UCSBVM.ucsb.edu
> Betreff: Re: AW: Best way to limit discovery
>
> Ralph, the fine point we would like to clarify: do you see any stubs
> for interaces in the address ranges you have excluded? The simple
> check is 'ovobjprint -s | grep Interface:' at some point in time BEFORE
> an ovtopofix that would flush them. I hope you will find that you have a
> lot of them, but only for things you have excluded by oid, not for things
> you have excluded by address. I think this is how it works, but Art has
> made me uncertain.
>
>
> Cordially,
>
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
> Detroit
>
> =========================================================
>
>
> 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
>
|