I just reviewed my notes from the internal update on V6, and it says
in there that the W flag in oid_to_type is only consulted on initial
discovery. I would expect that to mean it will behave rather like the
agent and vendor fields, ie you have to rediscover to get it recognized.
This flag sets these fields to their defaults:
isHTTPSupported (true)
isHTTPManaged (true)
ManagementURL http: (//hostname)
QED these fields are only set at initial discovery, and you are expected
to either maintain them, or rediscover the node to get them reset. This
was done intentionally so that you could change them if you did not
like the defaults.
As for the other flags in oid_to_type (G,H,B) I am usually able to
get it to consider them by unmanaging and managing the segment
or network that the device appears in, so you might try that (after
stop/starting daemons once so everyone sees the current file). I
believe I have also seen them taken care of dynamically, eventually,
but I will not swear to it. As I said, I am usually doing a new site and
want
to get it done fast, so I delete and rediscover after changing oid_to_type
or oid_to_sym.
Other new ovw fields listed in my handouts for V6:
ifSpeed (on interface objects)
isHSRP (on interface objects)
has Serial (on node objects)
routerSysName (on router node objects)
There is no info in my handouts about their frequency of use, but
I believe that they are the kinds of things that would be picked up on
a configuration poll (daily or netmon startup), at least the last 3.
I know that isSNMPSupported does not get updated when you lose
snmp contact with a device, either because the agent on it is down,
its community changes, or you change the community that is being used
by Netview. A lot of work was done in V6 to give us the alternate
community support, so I don't know if that's changed. Anybody noticed?
The fields related to device type (isComputer) seem to be picked up ok.
The ones related to levels in the map (isHub, etc) seem to be picked up
by ovtopofix because they are based on flags in oid_to_type, and get
drawn after unmanage/manage of a higher-level object.
The ones related to agents (isMLM) get picked up on config polls, as do
the ones like sysLocation.
Net, maybe it just boils down to the agent and vendor fields not being
updated except on discovery. Perhaps it should be picked up by
ovtopofix. That would be a simple requirement to submit, if we cannot
come up with any more. Has anyone noticed any others?
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
---------------------- Forwarded by Leslie Clark/Southfield/IBM on
04/07/2000 01:27 PM ---------------------------
"Prokott, Joe" <Joe.Prokott@westgroup.com>@tkg.com on 04/07/2000 11:43:06
AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc:
Subject: RE: Re:[NV-L] Keeping NV fields up-to-date
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
_________________________________________________________________________
NV-L List information (unsubscribing, policies, posting, digest version,
searchable archives): http://www.tkg.com/nv-l
|