James,
thanks for your answer. the thing I was trying to do was testing the backup
functionnality of Netview by generating a fake Node_down trap to one of my
netviews so that it would believe that the netview it was backuping was
Down.
In fact I got two NV , one monitoring system equipment, the other network
equipment. I configured containers in both of them and attributed the
containers to my NV accordingly to their function (system or network) . So
I got the same database in my NVs but one has got Network equipments UP and
system equipments Unmanaged, and the other Network equipments Unmanaged and
system equipments UP.
I thought that I could find a way to test the backuping by generating a
Node Down trap but as I don't know much about trap parameters, I used old
scripts found in a Redbook and even though I corrected them (syntax), I
didn't know about the trap parameters and how to set them so that my test
would work.....
Have tou ever used this Backup functionnality? Do you know exactly how it
works? do you need to have the GUI running?
thanks again for your answers!
regards,
Denis PEUZIAT
Tivoli Netview Administrator
IBM La Gaude
External phone: 33-0492115807
Tie line: 36-5807
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
|