James Shanks [mailto:jshanks AT us.ibm DOT com] writes:
> 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.
Unfortunately, though, it's not uncommon. We've encountered this
problem too where info is impbedded in this "type-length-value" item.
>It is the contents of the trap, the imbedded values, which are
>supposed to be important.
Countpoint: the job of a manager is to manage a substantial subset of
all agents that actually exist. For better or worse, there are agents
out there that do this sort of stuff and you need the info to do your
job of managing them and reporting the information intelligibly.
> 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.
This does sound like a promising workaround. Howver, I'm curious how
this could get passed to the script. By what means would one
reference these type-length-values inside of a script?
> 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.
OIC. No kiddin? EXCELLENT.
> 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.
Heck, I'll take any way around the b that doesn't require my
purchasing a new tractor--thanks for the great tip James.
--
Todd H.
http://www.toddh.net/
> "Binder, Karin" <karin.binder AT nwa DOT com>
> 02/19/2002 04:37 PM
>
>
> To: <nv-l AT lists.tivoli DOT 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 AT lists.tivoli DOT com
> For additional commands, e-mail: nv-l-help AT lists.tivoli DOT 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)
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
> For additional commands, e-mail: nv-l-help AT lists.tivoli DOT 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)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
> For additional commands, e-mail: nv-l-help AT lists.tivoli DOT 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)
>
--
Todd H.
http://www.toddh.net/
|
