nv-l
[Top] [All Lists]

Re: AW: Best way to limit discovery

To: nv-l@lists.tivoli.com
Subject: Re: AW: Best way to limit discovery
From: Leslie Clark <lclark@US.IBM.COM>
Date: Fri, 10 Dec 1999 11:12:10 -0500
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


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

Archive operated by Skills 1st Ltd

See also: The NetView Web