In reality what you are calling the label,
mgmt.mib-2.transmission.ds1.6.1.10.15, is not a label at all but the SNMP type
which is associated with this
value. It's an OID telling where in the MIB tree that this value (the
Integer 44) comes from. All trap variables, and indeed all SNMP datagram
, are sent in packets of type-length-value. But while trapd gets this in
the packet, he extracts the values and puts them in a structure he passes
to all connected applications, such as nvcorrd, that receive this trap.
This structure does not contain the MIB OID, and never has, because, to
make a analogy, trapd passes on the contents, the values contained in the
trap, but not the "box" it came in. By putting vital information in the
OID only, this vendor has in effect, made it just as important that you
examine the "box" your data came in as well as the data itself, which,
while not illegal, is unwise. It is the contents of the trap, the
imbedded values, which are supposed to be important.
In any case, while trapd has access to this information, nvcorrd does not,
and it would take a considerable design change to make it otherwise. What
can you do? Well, the only thing I can think of is to have trapd
intercept the trap in question, extract the information, and pass it on to
a script which issues a new but similar trap using the snmptrap command.
Your new trap would contain the interface id as a value and it is that one
which you can send to TEC.
If you examine the man page for trapd.conf you will see that if you format
your variable as "$+n" rather than just $n, (that is, as "$+1" rather
than just "$1" in this case) trapd will display (and pass on to ovactiond
so you can use it in a script) the OID. Experiment with that formatting
and you will see what I mean. When you get the display to show you what
you want then you can pass it to a script that issues the snmptrap
command. It's a long way around the barn perhaps, but it is the only way
to add more content to your trap.
Hope this helps
.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
"Binder, Karin" <karin.binder@nwa.com>
02/19/2002 04:37 PM
To: <nv-l@lists.tivoli.com>
cc:
Subject: [nv-l] Accessing varbind information in Ruleset Action
Node
Hi all. Running Netview 6.03, AIX 4.3.3
I'm using a ruleset to process trap information from an aac imux. The
trap value contains the alarm type. I also need to know which interface
the trap applies to. While the interface index is not provided in the
value part of the varbind, it is part of the name string that is sent. For
example:
mgmt.mib-2.transmission.ds1.6.1.10.15 (Integer): 44
The alarm value is 44; The interface index is 15. I can see the varbind
name string in the event string ($*) in trapd.log. I need to access it
from a script called by an action node in a ruleset. $NVATTR_1 contains
the value 44. I can't seem to find the name string in the passed data.
Any ideas? Is this data accessible via a ruleset?
Thanks for all suggestions,
Karin Binder
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
|