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
>
|