nv-l

Antwort: Netview growing Objects Database

1998-07-21 17:33:26
Subject: Antwort: Netview growing Objects Database
From: Sylvia Koch <sylvia.koch AT EMPRISE DOT DE>
To: nv-l AT lists.tivoli DOT com
Date: Tue, 21 Jul 1998 23:33:26 +0200
Sylvia [email protected]
21.07.98 23:33


In NetView V5, it should be possible to prevent the discovery of nodes
based on the absence of SNMP.
Specify as statement in the seedfile:
@oid 1.3.6.1.*
This specifies the total group of SNMP-nodes with OIDs beginning with
1.3.6.1. Non-SNMP-devices are not included in this group, thus they are
excluded from discovery.
It works as described in a test environment.

Sylvia Koch





Leslie Clark <lclark AT US.IBM DOT COM> am 21.07.98 04:30:18

Bitte antworten an Discussion of IBM NetView and POLYCENTER Manager on
      NetView et alia <NV-L AT UCSBVM.UCSB DOT EDU>

An:    NV-L AT UCSBVM.UCSB DOT EDU
Kopie:  (Blindkopie: Sylvia Koch/Emprise)
Thema: Netview growing Objects Database




I've just reviewed the documents from a training session I attended on V5,
and
it does not
appear to me that you can prevent the discovery of nodes based on the
absence
of SNMP.
Somebody will correct me if I am wrong. You can, however, exclude address
ranges, so if
you have a convention for addressing low-priority devices like
workstations,
you can now
exclude them more easily than you could before.  You can also cause
non-snmp
devices
to be discovered as unmanaged, which you probably know, with an entry in
oid_to_type.
That will help with cpu and network traffic, but will not reduce the object
count, of course.
Exclusion by range can be done with V4, it is just a lot easier
(!xxx.xx-xx.*.*) in V5.
Now for some unsolicited advice. What you have is NOT a network management
problem,
but an organizational problem. I see this with some customers, from time to
time. In fact I
expect you will see a flaming notice from James S. any minute now.  The
people
who
implement the network, the people who administer the addresses, and the
people
who
administer the management tools must all work together.  Here's how it
works
best:
1) The network guys apply for an address from the address administrator.
2) The address administrator assigns a name to go with that device (DNS,
etc.)
3) The network guys configure the device, including the SNMP fields for
location & contact,
and trap destination (the Network Management Station)
4) Some sort of change control notice is sent to the administrator of the
Network Management
Station to tell them about a new device that needs managing (or it does not
get
managed).
5) The administrator of the NMS adds the device to the seedfile, or ensures
that the ranges
in the seedfile will allow the device to be discovered, and then discovers
it.
If the implementation team does not report new and changed addresses, their
devices don't
get managed. Make it a rule. Get buy-in from management.
You can tell that I am a strong proponent of seedfiles, especially
restrictive
seedfiles. It is the
only way to keep garbage out of the database and maximize performance. And
I
have done
more than a few of these things. Tiny networks can get away with
runaway-discovery. Yours
is of a respectable size, and should be controlled. Hope this helps.
Cordially,
Leslie Clark
IBM Global Services - Network & Systems Management - Detroit
------------------------------------------------------------
>I've got one NV 4.1 on AIX  monitoring a wide multi-site network with 15,
>000 IP adresses, and only 1500 SNMP devices to manage. Undesirables
objects
>consuming CPU, RAM, Disk ressources and corrupt performances so i need to
>reduce the Objects Database. Seedfile seems not to be the way, while IP
>adresses of SNMP devices can change (two differents teams to install /
>manage the entire Network).
>Is it possible to limit Netview Object Database to only SNMP devices ?
>I was told that with NV 5.1 discovery can be defined based on SNMP sysOID,
>like 1.3.6.1.2., is this right, and could
>this improvement solve my problem ?
>Thanks for your help

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