Leslie is right, of course, but I'm afraid that we should confine this
discussion just to Windows, which is the platform that is at issue.
The broader question of how you change status on the NetView map based upon
an incoming trap depends greatly on what platform you have chosen. In a
nutshell, what works on UNIX may not work on Windows, because the APIs are,
and have to be, quite different.
The fact the you are on Windows both complicates and simplifies this issue,
for two reasons. The first is that while NetView for UNIX is an X-11
application, the user interface in NetView for Windows is not, so a lot of
what you can do in NetView for UNIX you simply cannot do easily in the
Windows version. The GUI had to be completely rewritten, and in that
rewrite, the developers decided not to include a lot of the backdoor and
hidden stuff you could do on UNIX, since it would not be easy to implement
in the native Windows GUI.
But the Windows developers did allow for the use of the Status trap, which
is also called the SNMP_EV event. To use it you have to create a .bat file
which sends an SNMP_EV event to your NetView, something like this
C:\usr\ov\bin\nvsnmptrap ^
myNetView .1.3.6.1.4.1.2.6.3 "" 6 58916871 "" ^
.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 "myhost.abc.com" ^
.1.3.6.1.4.1.2.6.3.1.1.4.0 octetstring "Status is" ^
.1.3.6.1.4.1.2.6.3.1.1.5.0 octetstring "Marginal"
You would of course substitute your path to nvsnmptrap in the first line,
your NetView hostname for "myNetView" in the second, and the name of the
object on your map that you wanted to change for "myhost.abc.com" in the
fourth.
Once you have completed this .bat file, you should test it from the command
line and verify that it works. Then my advice is copy and rename it, and
change it to set the status back to Normal, like this
C:\usr\ov\bin\nvsnmptrap ^
myNetView .1.3.6.1.4.1.2.6.3 "" 6 58916871 "" ^
.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 "myhost.abc.com" ^
.1.3.6.1.4.1.2.6.3.1.1.4.0 octetstring "Status is" ^
.1.3.6.1.4.1.2.6.3.1.1.5.0 octetstring "Normal"
Try this one too and verify that it works. Until you can alter the status
successfully from the command line, it is pointless to go any further.,
Now comes the tricky part. To drive this automatically, you must figure
out how to get the name of the object you want to change the status on out
of the incoming trap that you want to use as the trigger. NetView traps
always have the hostname as the second variable binding ($2) but not so
with those from other vendors. I am going to suppose that it is showing up
as the origin of the trap in the Event Browser. That would allow you to
reference it as $A in trapd.conf. In that case, then you could create a
third .bat file that looks like the first, except that it has "$1" for the
fourth variable binding:
C:\usr\ov\bin\nvsnmptrap ^
myNetView .1.3.6.1.4.1.2.6.3 "" 6 58916871 "" ^
.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 "$1" ^
.1.3.6.1.4.1.2.6.3.1.1.4.0 octetstring "Status is" ^
.1.3.6.1.4.1.2.6.3.1.1.5.0 octetstring "Marginal"
Suppose we filed this as C:\usr\OV\bin\marginal.status.bat. Then you would
configure your trigger trap, using trap.exe, to run it as a hidden
application, putting this in the box which says "Run this command when the
trap is received"
C:\usr\OV\bin\marginal.status.bat $A
Similarly if you have another event in mind to signal when this should go
back to normal, then you could do the same sort thing for that trap and
have it execute a version of the Normal status change .bat file, also with
$1 in the fourth line.
Why is this so hard to do? Well, the Windows product was designed for
smaller enterprises which did not need nor want to do complex
customizations. The idea was that if you needed this kind of thing, then
only those with strong Windows and NetView skills should be doing it.
That's why it is not documented in any great detail.
One last thing. As Leslie indicated the results of doing this are
unpredictable when you start doing them on an object which netmon is also
monitoring, because netmon may very well change the status back to what he
knows it to be, or fail to change it to normal again when it should be. He
will have no idea that you changed the status outside of his control. He's
not even aware of your change. He'll take his queue from the status in the
topology database and not what you have done. The developers intended this
API to be used on objects you created yourself and not on objects which
netmon created and is also monitoring.
That said, if you want to use it for other reasons, go ahead, but you will
have to take the responsibility for seeing that things returned to normal
when they should.
I should also mention that changing object status based on OSPF is a
fundamental feature of ITNM, NetView's replacement.
Hope this helps,
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|