I have seen similar issues that Leslie explains below. We too use the
vendor field and this issue has come up because of this example.
I believe the underlying problem in general is that we do not know which
fields require rediscovery to update and which ones do not???? As Leslie
mentions, "vendor" and "SNMPAgent" are two such fields. I think there are
others as well.
Let's take this case by case - is there a way to update the "vendor" field
without doing rediscovery??? If not, what are the specific properties of
the "vendor" field that does not allow NV to update this field via a config.
check or some other periodic poll, ovtopofix, etc...? How can I find/know
all the other fields in the NetView database that behave this same way and
only update upon rediscovery?? After we look at the properties of the
"vendor" field that makes NetView only update on rediscovery, are there
other fields in NetView that only update on rediscovery for other different
reasons???
All I am trying to do is EASILY(i.e., minimal resources) put everything in
sync. and accurate in NV and since there is no message such as, for example,
"Config. check sees that the 'vendor' field in the NV database for object
XXXX does not match what is defined in the oid_to_type file, please
rediscover", we do not know when to do this. Ideally, it would be nice if
we could configure NetView so it would just update this field and not
require rediscovery. We could do like Leslie does and create a separate
collection for "vendor=Unset" and periodically check this collection, but
this is only one example for one field and why should we manually do this if
NV should be updating these fields anyway??? I wonder how many other fields
are not correct because they are different now vs. when they were initially
discovered?
All I want is a way to determine which NV fields are defined as static and
can/do other vendors add such static fields? Furthermore, if NV disovers
that these static fields become different(which it should be able to do via
its polling or from some periodic command - whether or not it is getting
done is another question), NV should at least have the option of sending
some sort of event/notification letting the NV administrator know about
these differences.
Joe
-----Original Message-----
From: Jeff Fitzwater [mailto:jfitz@Princeton.EDU]
Sent: Friday, April 07, 2000 8:38 AM
To: IBM NetView Discussion
Subject: Re: Re:[NV-L] Keeping NV fields up-to-date
NV 6 on sol 2.6
I have a similar problem with the oid-to-type field . If I change field 4
to have a (BW) indicating it is a bridge and has a web interface, I can't
seam to make the devices learn the new field attribute. I have shut
down netview and executed (ovw -fields) and also tried (ovtopofix -a) and
still the devices do not understand they are web capable. They work fine
if I set the object info for HTTP manually from the device pull-down menu.
I have even deleted an object and rediscoveered it via (loadhosts) and still
no entry to the device object field for HTTP.
Jeff Fitzwater
CIT Systems & Networking
Princeton University
----- Original Message -----
From: <lclark@us.ibm.com>
To: <NV-L@tkg.com>
Sent: Friday, April 07, 2000 9:10 AM
Subject: Re:[NV-L] Keeping NV fields up-to-date
>
>
> Joe, most of my work is with new installs, so I don't often see the
> kinds of administrative problems long-running installations have.
> But here's my two cents' worth anyway.
>
> I believe that the vendor and agent fields do not get updated on a
> config poll, only at initial discovery. Those are the only ones that
> have bothered me, anyway.
>
> I always make sure that the oid_to_type file is backed up by the
> vendor list (ovw_fields) and agent list (snmp_fields). This is not
> always done if third-party products are added. If they don't match
> exactly, the agent and vendor fields in the oid_to_type file won't
> be added to the object info for a newly discovered node.
>
> Then I always set up a collection (smartset) with the criteria of the
> vendor field being unset, but which is snmp-capable. This gives me
> a group to watch. Anything that shows up in here is probably not drawn
> properly, since I know there is no entry in the oid_to_type file for it,
> or it was discovered before I updated the configuration files. It flags
> new types of devices based on oid. If something shows up, I know
> that I have to update the vendor and agent lists, the oid_to_type, and
> maybe the oid_to_sym files, and then I delete and rediscover those
> nodes, primarily because I want the vendor field to be set, because it
> is the criteria for my 'to-do' collection.
>
> Can you point out other fields that are bothering you? This discussion,
> like the recent discussion of long-term administration of seedfiles, is
> one that is best held between customers who see the real-life issues
> over the long haul.
>
> Cordially,
>
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
> Detroit
>
> ---------------------- Forwarded by Leslie Clark/Southfield/IBM on
> 04/07/2000 08:54 AM ---------------------------
>
> "Prokott, Joe" <Joe.Prokott@westgroup.com>@tkg.com on 04/06/2000 06:23:27
> PM
>
> Please respond to IBM NetView Discussion <nv-l@tkg.com>
>
> Sent by: owner-nv-l@tkg.com
>
>
> To: "'NV Forum'" <nv-l@tkg.com>
> cc:
> Subject: [NV-L] Keeping NV fields up-to-date
>
>
>
> We have a never ending and growing NetView environment and sometimes
> struggle keeping all the NV fields for objects up-to-date.
>
> Does anyone know of a good way to verify that all NetView fields are
> up-to-date? I know there are some NV fields that only get defined upon
> initial discovery and will not change unless rediscovered, even if the
> fields files themselves have been updated. Is there a list of these type
> of
> fields that do not change once initially defined? Better yet, is there
> some
> way I can run a script that will either (1) let me know what nodes need to
> be re-discovered because there is a conflict with what is defined in the
NV
> database and what is defined in the fields/oid_to_sym/oid_to_type/etc...
> files, or (2) dynamically update these differences to match what is
> defined.
>
>
> There are always new fields added to new versions of NetView and I am
never
> quite sure if these will automatically be added or if I will need to
> rediscover the node so the new fields get added. It would be nice if
> NetView could tell me what the differences were so we could keep things
> up-to-date. It is not practical for us to rediscover our entire network
on
> some regular basis because we do not know if there are NV object field
> changes or not.
>
> I assume many others have this same problem. I would like as close to an
> automated solution to this problem as possible.
>
>
> Joe Prokott
> Network Architect
> West Group
> phone: 651-687-4536
> e-mail: joe.prokott@westgroup.com
>
>
>
> _________________________________________________________________________
>
> NV-L List information (unsubscribing, policies, posting, digest version,
> searchable archives): http://www.tkg.com/nv-l
>
>
>
> _________________________________________________________________________
>
> NV-L List information (unsubscribing, policies, posting, digest version,
> searchable archives): http://www.tkg.com/nv-l
>
_________________________________________________________________________
NV-L List information (unsubscribing, policies, posting, digest version,
searchable archives): http://www.tkg.com/nv-l
|