Vynita -
Is your events window up on a read-write map? Is the hostname in the trap
the selection name of the object on the map you are trying to change status
on?
These thiings are required.
I am appending a document I wrote a while back in an attempt to explain the
requirements for changing status on the map with a trap.
Hope this helps
James Shanks
NetView for UNIX Level 3
Overriding status using a trap
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
/usr/OV/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 some 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 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.
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 field.
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.
James Shanks
06/16/97
==========================================================================
>Hi all
>I am running Netview/AIX 4.1.2.0.U449573
>I have encountered a problem with the event configuration. I >discovered a
NT machine
>and I have configured specific events to make the status make the >icon
red or green,
>I specified enterprise Specific 1 (application down) status >event, down ,
critical
>because if the application is down it must go red on the map.
>The event card comes up red but the icon does not change colour , >so I
>ran a sent snmp trap(netview Diagnose) and it also does not go >red.
>How do I get Netview to change colours on the map?
>Thanks
>Vynita P
|
