-----Original Message-----
From: Leslie Clark [mailto:lclark AT US.IBM DOT COM]
Sent: Monday, November 08, 1999 10:17 PM
To: NV-L AT UCSBVM.ucsb DOT edu
Subject: Status Color change
Deep, I haven't sent this around lately, so here's one from the archives.
It gives
a good explanation of the issues involved in manipulating the status of
objects
owned by Netview. I am trying to clarify the issue, which is that you are
not actually
expected to set your own status on things that belong to ipmap. That's why
you are getting all of these alternative suggestions instead of the
straight
answer you are asking for. I hope this helps.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager
From the Support Center....
------------------------------------------------------------------
One of the most common, and yet most complicated, things that NetView
users ask about is how to alter the status (color) of an icon on the
map using a trap, effectively overriding what netmon has done. This
can be accomplished in one of three ways, (1) using a ruleset with the
override node in it, (2) issuing the 58916871 NetView trap, or (3) by
configuring a non-NetView trap.
This document is an attempt to explain how these processes work.
Types of status
There are three (3) sources of status for objects on a NetView map:
1. Object source -- status of a single object is kept in the
database entry for that object
2. Compound Propagated source -- object has no status of its own, but
it is derived from status of its constituent objects.
Network symbols and collection objects have status source of
'Compound Propagated'
3. Symbol source -- an ipmap status not part of the object host nodes
in the map have this status source
You can determine the status source for any map object by selecting
it with the rightmost mouse button and clicking on Edit ==> Modify /
Describe ==> Symbol.
General requirements
1. In order for an event, no matter how it is processed, to override
status and change the color of an object on the map(s), the Event
process (called nvevents) must be running in dynamic workspace in a
control desk on the read-write map, and the control desk must have
been started by ovw (the map process) initially. This is the default
NetView End User Interface configuration.
The reason for this is that the APIs for the status override function
are in nvevents and ovw, and they can only be used effectively when
both are connected to the same read-write map.
2. The API can easily override the status of objects which have a
status source of 'Object' or 'Symbol', but a status source of
'Compound Propagated' is more difficult. Since this is a derived
status it cannot be changed directly. What nvevents can do in this
case, is to change the status source of the object to 'Symbol' first,
and then override it. But as this means that from that time on, the
map object will no longer reflect the combined status of the objects
"below" it (unless you later change the status source back to
'Compound Propagated again via Edit with the right mouse button) you
must set the application defaults for nvevents to permit this to
happen. You must edit app-defaults/Nvevents to say
nvevents.overrideCompoundStatus : True
When your event requests a status override, the object's status source
will be changed from compound to symbol, and then overridden. But now
you must take responsibility to change the status again when the
condition which caused you to change it in the first place has passed,
as it will never again reflect the status derived from its components.
Failure to have nvevents.overrideCompoundStatus : True set in your
Nvevents file is the most common reason why users report that overrides
do not work. Be aware that each user could have his or her own
copy of Nvevents in his or her $HOME directory or could have
incorporated the Nvevents entries into a .Xdefaults file. And be aware
that X is not forgiving about user defaults. The value here must be
"True" and not "True " with any extra spaces trailing the 'e'.
Note that if a host node is in a Collection, it has status source of
'Compound Propagated', while on the IP Segment map it will have a
status source of 'Symbol'. If you do not have
nvevents.overrideCompoundStatus : True
set in the Nvevents app-defaults, then the status you set will not be
reflected in the Collection. This is another common problem which
users report.
Note that the host node on a Segment map typically has status source
of 'Symbol'. It is set when netmon issues a Node Up/Node Down trap.
Note that interfaces have a status source of 'Object'. Their status
is set when netmon issues an Interface Up/Interface Down trap. At
higher levels, networks and segments have a status source of 'Compound
Propagated', so both the host node AND its "down" interfaces must
have their status set to User1 or User2 to avoid having them alter the
status of the network. Failure to set both of them is another common
user problem.
3. Condsider how you will change the status back again. If you are
changing status of nodes and interfaces that netmon pings, remember
that it will change them back again, so you might delay the netmon
polling cycle for them. If you are overriding the status source of an
object that was 'Compound Propagated' and are changing it to 'Symbol',
you must find a way to change the status again with so other "cleared
condition" event, since it will not change on its own now.
Override status with ruleset
In order for a ruleset to override status and change the color of an
object on the map(s), the ruleset must be running in dynamic workspace
in a control desk on the read-write map. This is general requirement
#1.
And for the ruleset to override the status of an object which has a
status source of 'Compound Propagated', you must edit
app-defaults/Nvevents to say
nvevents.overrideCompoundStatus : True
This is general requirement #2.
But ruleset override will only override the status of the host node,
the "origin" of the trap, and not the interface (unless the interface
does not have a hostname associated with it in the NetView database).
This can be inconvenient, especially if what you want to do is
override the status of both the host node and the interface (to
something like User1 or User2) so that they do not figure in status
propagation to higher-level nodes.
Note that the host node on a Segment map typically has status source
of 'Symbol'. It is set when netmon issues a Node Up/Node Down trap.
Note that interfaces have a status source of 'Object'. Their status
is set when netmon issues an Interface Up/Interface Down trap. At
higher levels, networks and segments have a status source of 'Compound
Propa- gated', so both the host node AND its "down" interfaces must
have their status set to User1 or User2 to avoid having them alter the
status of the network.
So NetView also provides another way that status can be overridden.
Override status using the 58916871 trap.
If you look at the description of this trap in Event Configuration,
you will see that this trap is not issued by netmon but is in fact
designed for customer use to change status (and therefore color) on a
map. It doesn't affect true status in the object database. Below is
a shell script which will issue this trap via the snmptrap command.
You pass it two variables -- (1) the name of the object from object
database, and (2) the status you want this changed to on the map(s).
Here's the script:
#!/bin/ksh
set -x
NAME=$1
STATE=$2
/usr/OV/bin/snmptrap `hostname` .1.3.6.1.4.1.2.6.3.1 \
`hostname` 6 58916871 1 \
.1.3.6.1.4.1.2.6.3.1.1.2.0 Integer 14 \
.1.3.6.1.4.1.2.6.3.1.1.3.0 OctetString $NAME \
.1.3.6.1.4.1.2.6.3.1.1.4.0 OctetString "Object status is" \
.1.3.6.1.4.1.2.6.3.1.1.5.0 OctetString $STATE
Obviously you can make this script more elaborate if you like.
The permissable status values are Unknown, Normal, Marginal, Critical,
Up, Down, User1, and User2.
You can obtain the name of the object by highlighting the icon on the
map and clicking with the RIGHT mouse button to get to Edit ==>
Modify/Describe ==> Object and the name is in the Set Selection Name
Typically, a host is known by its hostname and an interface by
hostname:interfacename, where the interface name is the IFdescription
from the MIB (such as "nv6ktst5.raleigh.ibm.com:tr0" for example).
You can always verify you have a correct object name by doing
ovobjprint -s <name>. If the object is not found, then you have a bad
name.
Since this is being done using the nvevents API to ovw, the same
restrictions apply. The snmptrap must be received by some NetView with
nvevents running in a control desk attached to an ovw running the
read-write map. This is general requirement #1.
And the Nvevents app-defaults file must have the same value set:
nvevents.overrideCompoundStatus : True if what you are setting has a
status source of Compound Propagated. This is general requirement #2.
Override with a trap setting
As in all other cases, general requirements #1 and #2 apply here as
well.
In addition, you cannot alter the status set by netmon traps, so you
have to use a trap from another agent. Here you can also use snmptrap
to create your own traps and issue those by script or automatic action
from Event Configuration.
