What question are you asking here, Denis? How does backup work or how
does snmptrap work? I assume what you are asking about are the trap
variables, correct?
This snmptrap script would have shown something that looked like a real
Node Down trap in the event window, but it does not have the same values
as a real one. It does not even have the same number of varbinds as a real
one, so that may be part of your problem. I don't know how that affected
your processing because I am not certain what you were testing, nor how
you were trying to test it. Did you try it using the event command?
/usr/OV/bin/event -h LexMol
would send a dummy Node Down with the hostname of "LexMol" as the source,
which is basically what your snmptrap command does, but I would check your
object database (ovobjprint -s <Selection Name>) to see if LexMol is
usually referred to by its short name or fully-qualified domain name
(LexMol.whatever.com). Usually it is the latter, and in that case it is
always better to use the fully-qualified name in the event or snmptrap
command so that there is no mistake.
In a real Node Down trap there would have been more variable bindings and
they would have had different variables. As a rule. all NetView traps
contain at least 5 variables. If it does not have at least five
variables, then it will not be treated as a real NetView trap, no matter
what the enterprise id is. Many specific traps and their contents are
explained in Appendix A of the NetView Administrator's Guide. The first
varbind is an integer representing the sending process. Since in real
life this would be netmon, and as netmon's number is "2", I would expect
the first varbind to be a "2" rather than a "9", though I don't know of
any process which actually checks this integer to determine who sent the
trap, but that is how it is documented. The second variable is always the
fully-qualified hostname (or IP Address if the name cannot be resolved),
and trapd will substitute this into the trap as the Origin provided the
trap has at least 5 variables (which would make it a genuine NetView trap,
as a opposed to a user trap with the NetView OID). That is most likely
the source of your testing difficulties, I expect. The third variable is
the trap message, Node Down", in this case. The fourth will always be
internally useful information such as the event timestamp and the NetView
object id of the node that is down. This is the kind of information that
the Appendix will tell you. The fifth variable will be a database
indicator. In past releases, this was always "openview" in UNIX and
"topo_db" in NT. It usually does not matter which is used. All this is
common up to Version 6. Later releases of NetView add additional
variables to certain traps, first for RFI, and later for use with
integrated TEC, so the actual number of variables and their contents, is
now release-dependent.
Beginning with Version 6, the sixth variable is the Selection Name of the
node for a node event, so it should always match varbind 2 for a Node
Down.
In 7.1.2, new varbinds, the seventh and eighth, are added, as noted in the
Release Notes. For a node event, such as Node Down, varbind 7 will be
empty and varbind 8 will contain a comma-separated list of all the
interfaces on that node.
I suggest that before you try to simulate a trap again, you capture the
contents of a real one first. You could do this in the following way. Go
to xnmtrap and select your trap and modify it to kick off a script when it
comes in, like this
/usr/OV/bin/echovar $S "$1" "$2" "$3" "$4" "$5" "$6" "$7" "$8"
And in echovar, do something like this:
#!/bin/ksh
#
echo `date` >> /usr/OV/log/echovar.out
echo "specifc = " $1 >> /usr/OV/log/echovar.out
echo " var 1 = " $2 >> /usr/OV/log/echovar.out
echo " var 2 = " $3 >> /usr/OV/log/echovar.out
echo " var 3 = " $4 >> /usr/OV/log/echovar.out
echo " var 4 = " $5 >> /usr/OV/log/echovar.out
echo " var 5 = " $6 >> /usr/OV/log/echovar.out
echo " var 6 = " $7 >> /usr/OV/log/echovar.out
echo " var 7 = " $8 >> /usr/OV/log/echovar.out
echo " var 8 = " $9 >> /usr/OV/log/echovar.out
If you ask for more variables than the trap send, the first empty one will
contain an error message from trapd, which says something like, "FMT
ERROR: accessing element #6, only 5 available" . The actual variables
will still be printed.
Hope this helps
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
Denis Peuziat/France/Contr/IBM@IBMFR
07/08/2002 05:28 AM
To: nv-l@lists.tivoli.com
cc:
Subject: [nv-l] trap parameters
Hi,
NV 7.1 AIX 4.3.3
I used the following script to issue a "node Down" trap in order to test
the backup functionnality in Netview. Unfortunately it did not work
properly....I was wondering what the different parameters correspond to?
Does anyone have a clue?
snmptrap @netview .1.3.6.1.4.1.2.6.3 @node 6 58916865 0 \
.1.3.6.1.4.1.2.6.3.1.1.2.0 integer '9' \
.1.3.6.1.4.1.2.6.3.1.1.3.0 octetstring "LexMol" \
.1.3.6.1.4.1.2.6.3.1.1.4.0 octetstring "Node Down"
thanks!
Regards,
Denis PEUZIAT
Tivoli Netview Administrator
IBM La Gaude
External phone: 33-0492115807
Tie line: 36-5807
---------------------------------------------------------------------
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)
|