Ralph;
This is true. For smaller installations, this won't be much of an issue. This
is a very big issue for larger installations. I had a database size of over
120,000 objects, and was able to reduce that to 30,000 objects by removing
stubs. A stub is not treated the same as a normal object, but it does have an
impact on NetView's performance if there are a significant number of them. It
used to take me an hour to start up the daemons back in those days
Art DeBuigny
Bank of America Network Operations
debuigny@dallas.net
Schiffinger Ralph 2100 wrote:
> 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
> >
|