RE: [nv-l] Simulating node/interface up/down events

[James Shanks <jshanks@us.ibm.com>]

So what problem remains?  This is just what I would expect to see in trapd.log for that script:
1074765150 3  Thu Jan 22 09:52:30 2004 orkney  a Interface ether1 Down

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group

colin.walls@barclays.co.uk Sent by: owner-nv-l@lists.us.ibm.com 01/22/2004 04:59 AM Please respond to nv-l

To:        nv-l@lists.us.ibm.com         cc:                 Subject:        RE: [nv-l] Simulating node/interface up/down events

What we are trying to do is to take SNMP events from BT and feed them into
NV and onwards into TEC. We are not using the maps for these events, since
we can't actually see the BT provided infrastructure. 
 
I have updated the script that I sent last time. This now reads
 
snmptrap nvserv101 \
         .1.3.6.1.4.1.2.6.3.1 \
         128.30.13.205 \
         6 58916867 \
         0 \
         .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 orkney \
         .1.3.6.1.4.1.2.6.3.1.1.4.0 Octetstring 'Interface ether1 Down' \
         .1.3.6.1.4.1.2.6.3.1.1.5.0 Octetstring '128.30.13.205 0 1 1' \
         .1.3.6.1.4.1.2.6.3.1.1.6.0 Octetstring 'openview' \
         .1.3.6.1.4.1.2.6.3.1.1.7.0 Octetstring 'orkney' \
         .1.3.6.1.4.1.2.6.3.1.1.8.0 Octetstring '128.30.13.205' \
         .1.3.6.1.4.1.2.6.3.1.1.9.0 Octetstring 'ether1'

This produces the event shown in the attached JPG. I also get the following
in trapd.log. I have included some information from a previous trap, which
is from the working node up/down script.
 
1074764994 3  Thu Jan 22 09:49:54 2004 43.25.111.193             N  [1]
private.enterprises.ibm.ibmProd.3.1.1.2.0 (Integer): 1
1074764994 3  Thu Jan 22 09:49:54 2004  43.25.111.193             N  [2]
private.enterprises.ibm.ibmProd.3.1.1.3.0 (OctetString): sspg1657a01
1074764994 3  Thu Jan 22 09:49:54 2004  43.25.111.193             N  [3]
private.enterprises.ibm.ibmProd.3.1.1.4.0 (OctetString): node up
1074765150 3  Thu Jan 22 09:52:30 2004 orkney                    a Interface
ether1 Down


-----Original Message-----
From: James Shanks [mailto:jshanks@us.ibm.com]
Sent: 21 January 2004 16:51
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Simulating node/interface up/down events



What do you mean "NV sees no parameters with interface up/down events"? What
exactly are you trying to do? 
In most cases you cannot spoof NetView into updating his map status just by
sending him traps.         

My guess is that whatever it is, the code is looking for information in
other varbinds of the event.  Interface events now have  8  varbinds, not
three nor five.  The Admin Guide documentation, Appendix A,  was updated for
this in 7.1.4, but it is in the 7.1.3 Release Notes too that there are now
8. 
.1.3.6.1.4.1.2.6.3.1.1.2.0  Integer 14            fixed value of 14 
.1.3.6.1.4.1.2.6.3.1.1.3.0  OctetString         hostname of device owning
the interface 
.1.3.6.1.4.1.2.6.3.1.1.4.0  OctetString        "Interface <if_name> Down" 
.1.3.6.1.4.1.2.6.3.1.1.5.0  OctetString         data string consisting of
Interface IP address, timestamp of the event, owning node object id,
interface id, all blank delimited 
.1.3.6.1.4.1.2.6.3.1.1.6.0  OctetString         fixed value "openview " 
.1.3.6.1.4.1.2.6.3.1.1.7.0  OctetString        hostname of device owning the
interface 
.1.3.6.1.4.1.2.6.3.1.1.8.0  OctetString        IP address of the interface 
.1.3.6.1.4.1.2.6.3.1.1.9.0  OctetString        "<if_name>" 

Note that, however, in most cases you cannot spoof NetView into updating his
map status just by sending him traps.         



James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group 



                 colin.walls@barclays.co.uk 
Sent by: owner-nv-l@lists.us.ibm.com 


01/21/2004 11:02 AM 
Please respond to nv-l 


        
        To:        nv-l@lists.tivoli.com 
        cc:         
        Subject:        [nv-l] Simulating node/interface up/down events 




We have outsourced our network to BT, but still wish to retain some elements
of network management so that we can correlate network with system and
application events.

BT have been sending us node up/down events for some while now, we import
these into Netview with no difficulty. We now want them to send us interface
up/down events. We thought that this would simply mean modifying their
script, which sends an SNMP trap, to use specific traps of 58916866/7
instead of 58916864/5. What actually happens is that NV sees parameters with
the node up/down events, but no parameters with interface up/down events.

Stripping the whole thing down we end up with the following shell script
fragment.

snmptrap nvserv101 \
 .1.3.6.1.4.1.2.6.3.1 \
 $AGENT_IP \
 6 $SPECIFIC_TRAP \
 0 \
 .1.3.6.1.4.1.2.6.3.1.1.2.0 Integer 1 \
 .1.3.6.1.4.1.2.6.3.1.1.3.0 Octetstring $AGENT \
 .1.3.6.1.4.1.2.6.3.1.1.4.0 Octetstring $DESCRIPTION

Adding data and database parameters doesn't make any difference. Any clues
as to what we are doing wrong? We are running NV 7.1.3.

--
Dr. Colin Walls
Project Services
Enable
Telephone: 01565 613705
Email: Colin.Walls@Barclays.co.uk

Internet communications are not secure and therefore the Barclays Group
does not accept legal responsibility for the contents of this message.
Although the Barclays Group operates anti-virus programmes, it does not
accept responsibility for any damage whatsoever that is caused by
viruses being passed.  Any views or opinions presented are solely those
of the author and do not necessarily represent those of the Barclays
Group.  Replies to this email may be monitored by the Barclays Group
for operational or business reasons.






Internet communications are not secure and therefore the Barclays Group
does not accept legal responsibility for the contents of this message.
Although the Barclays Group operates anti-virus programmes, it does not
accept responsibility for any damage whatsoever that is caused by
viruses being passed.  Any views or opinions presented are solely those
of the author and do not necessarily represent those of the Barclays
Group.  Replies to this email may be monitored by the Barclays Group
for operational or business reasons.