Re: Status Color change

["Bingen, Jim D" <Jim.Bingen@NAVISTAR.COM>]

Leslie is right when she says that you are not expected to set your own
status on things that belong to ipmap. In fact if you try to you will be
fighting a useless battle with Netview which you cannot win.

The way I got around it so that I could set the color/status of our devices,
was as follows. We have a collection of about 70 Adtran CSU/DSUs. They can
be controlled by both SNMP or telnet commands. The problem is that since we
have a triangle configuration between our major sites and we also have
CSU/DSUs that carry voice circuits only, the status of the ip interface is
not necessarily the same as the status of the telephone line.

So I needed an icon that was attached to the icon for the Adtran unit that I
could change manually. What I did for each icon in the Adtran collection,
was to right click the icon for the Adtran unit, and select edit->copy->from
this submap. I then double clicked the icon and selected edit->paste from
the menu items on the top of the screen. This created two symbols for the
same object. I then right clicked this new icon and selected
edit->Modify/describe->symbol. Then I changed the  status source to symbol.
That way the first symbol was still controlled by ipmap because it was
compound (propagated), and the second icon was on its own because its status
source is symbol (its self). I also changed the label slightly for this
second icon by adding a "-T1" to the end of the name to represent the
telephone line side of the Adtran.

Now when a trap comes in that sets the status of an object, the top level
icon will not change because it is controlled by ipmap, but the bottom level
icon is changed. Once the bottom level icon is changed, the top level icon
will change to yellow to indicate the icons under it are mixed colors. I
also had to go through the Adtran traps and make sure they were configured
to change the status appropriately by using xnmtrap.

I also setup traps of my own using the Netview 58916871 trap procedure with
the snmptrap command to manually set the status of the bottom level symbols
to green (up) at Netview startup time (they come up as blue-unknown at
startup time), and any time the status is not correct.

I haven't had any problems with this so far. If anyone can see a problem
with it, let me know. It can be a lot of manual work to setup, but there is
little maintenance to keep it working. Also, if Adtran changes their traps,
I'll have to go through them to make sure they set the status of the object
the way I have them setup now before I can re-load them.



                -----Original Message-----
                From:   Leslie Clark [mailto:lclark@US.IBM.COM]
                Sent:   Monday, November 08, 1999 10:17 PM
                To:     NV-L@UCSBVM.ucsb.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.

Leslie is right when she says that you are not expected to set your own status on things that belong to ipmap. In fact if you try to you will be fighting a useless battle with Netview which you cannot win.

The way I got around it so that I could set the color/status of our devices, was as follows. We have a collection of about 70 Adtran CSU/DSUs. They can be controlled by both SNMP or telnet commands. The problem is that since we have a triangle configuration between our major sites and we also have CSU/DSUs that carry voice circuits only, the status of the ip interface is not necessarily the same as the status of the telephone line.

So I needed an icon that was attached to the icon for the Adtran unit that I could change manually. What I did for each icon in the Adtran collection, was to right click the icon for the Adtran unit, and select edit->copy->from this submap. I then double clicked the icon and selected edit->paste from the menu items on the top of the screen. This created two symbols for the same object. I then right clicked this new icon and selected edit->Modify/describe->symbol. Then I changed the  status source to symbol. That way the first symbol was still controlled by ipmap because it was compound (propagated), and the second icon was on its own because its status source is symbol (its self). I also changed the label slightly for this second icon by adding a "-T1" to the end of the name to represent the telephone line side of the Adtran.

Now when a trap comes in that sets the status of an object, the top level icon will not change because it is controlled by ipmap, but the bottom level icon is changed. Once the bottom level icon is changed, the top level icon will change to yellow to indicate the icons under it are mixed colors. I also had to go through the Adtran traps and make sure they were configured to change the status appropriately by using xnmtrap.

I also setup traps of my own using the Netview 58916871 trap procedure with the snmptrap command to manually set the status of the bottom level symbols to green (up) at Netview startup time (they come up as blue-unknown at startup time), and any time the status is not correct.

I haven't had any problems with this so far. If anyone can see a problem with it, let me know. It can be a lot of manual work to setup, but there is little maintenance to keep it working. Also, if Adtran changes their traps, I'll have to go through them to make sure they set the status of the object the way I have them setup now before I can re-load them.

  

-----Original Message-----
From:   Leslie Clark [mailto:lclark@US.IBM.COM]
Sent:   Monday, November 08, 1999 10:17 PM
To:     NV-L@UCSBVM.ucsb.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.