nv-l
[Top] [All Lists]

Re: Strange Cisco traps....

To: nv-l@lists.tivoli.com
Subject: Re: Strange Cisco traps....
From: Gord Michaels <gord_michaels@HOTMAIL.COM>
Date: Thu, 16 Dec 1999 10:34:42 PST
Thanks for the response.

So, when you seen "Unknown Trap Format" in the Events Display, it means that
there is nothing close to it in trapd.conf, i.e. there is no nearest to drop
down to??

Hmmmm... I thought that if the Enterprise OID was not defined in trapd.conf
then it didn't get formatted, period. I had no idea it would look for the
'nearest' match.

Sincerely,

Gord.


>From: "Owens, Blaine C" <bowens@EASTMAN.COM>
>Reply-To: Discussion of IBM NetView and POLYCENTER Manager on NetView
>        <NV-L@UCSBVM.ucsb.edu>
>To: NV-L@UCSBVM.ucsb.edu
>Subject: Re: Strange Cisco traps....
>Date: Wed, 1 Dec 1999 14:25:56 -0500
>
>1. The enterprise ID could be either, you should not have had to do what
>you
>did. The base enterprise ID for cisco would be 1.3.6.1.4.1.9 which may
>contain a set of traps 0-x. Cisco may (and does) have additional enterprise
>IDs for specific device types and/or applications, each beginning
>1.3.6.1.4.1.9.x and each with their own set of traps 0-x. From your map do
>Options --> Event Configuration --> Trap Customization SNMP and scroll down
>to where the cisco IDs begin. It should work like this (using examples
>only):
>
>1.3.6.1.4.1.9.9.29
>1.3.6.1.4.1.9.9
>1.3.6.1.4.1.9
>
>The specific trap number is 1. If trapd sees 1.3.6.1.4.1.9.9.29 it will
>look
>in that section of trapd.conf to format specific trap 1. If there is no
>section 1.3.6.1.4.1.9.9.29 it will drop down to the next "nearest" match
>which would be 1.3.6.1.4.1.9.9 in this example and format it from there.
>Finally, if there is neither a 1.3.6.1.4.1.9.9.29 or a 1.3.6.1.4.1.9.9 it
>will drop down to the 1.3.6.1.4.1.9 section to format the trap. Hope this
>makes sense.
>
>2. You can configure cisco routers to force the trap source to be whatever
>interface you want. Add the following to the configuration of your cisco
>routers to force the source IP address of all traps to be the loopback
>interface IP:
>
>snmp-server trap-source Loopback0
>
>Hope this helps.
>
>Blaine Owens
>Eastman Chemical Company
>Phone - (423)-229-3579
>Fax - (423)-229-1188
>bowens@eastman.com
>
> > -----Original Message-----
> > From: Gord Michaels [SMTP:gord_michaels@HOTMAIL.COM]
> > Sent: Wednesday, December 01, 1999 1:50 PM
> > To:   NV-L@UCSBVM.ucsb.edu
> > Subject:      Re: Strange Cisco traps....
> >
> > Thanks for all the responses, but....
> >
> > 1. I still don't know why the Enterprise ID of the trap is:
> >
> > 1.3.6.1.4.1.9.9.29
> >
> > instead of 1.3.6.1.4.1.9  ????
> >
> > 2. Also, the traps are coming from specific intefaces and not the
> > interface
> > which the router was discovered with (i.e. I used the loopback addresses
> > for
> > discovery).
> >
> > This is a problem because I forward this trap if it comes from a device
>in
> > my Router_Collection. Even though the interface is a part of the device
> > (router) within this collection, it does not get sent to the Events
> > Display,
> > i.e. Netview does not see it as being a part of the collection, the
>Source
> > is an interface and not the router itself.
> >
> > Any seen this before.
> >
> > Any info appreciated,
> >
> > Gord Michaels.
> >
> >
> >
> >
> >
> >
> > >From: Brad Martin <bmartin@METLIFE.COM>
> > >Reply-To: Discussion of IBM NetView and POLYCENTER Manager on NetView
> > >        <NV-L@UCSBVM.ucsb.edu>
> > >To: NV-L@UCSBVM.ucsb.edu
> > >Subject: Re: Strange Cisco traps....
> > >Date: Wed, 1 Dec 1999 11:52:35 -0500
> > >
> > >We've had a similar problem in the past with one router sending this
>trap
> > >every
> > >20 seconds. CISCO was able to identify that the dial-up modem for the
> > >device was
> > >hanging and didn't clear the connection. Problem would go away once the
> > >modem
> > >was reset.
> > >
> > >Brad Martin
> > >MetLife
> > >
> > >
> > >
> > >
> > >
> > >
> > >"David Barnwell" <David.Barnwell@AEXP.COM> on 12/01/99 05:22:59 AM
> > >
> > >Please respond to "Discussion of IBM NetView and POLYCENTER Manager on
> > >NetView"
> > >       <NV-L@UCSBVM.ucsb.edu>
> > >
> > >To:   NV-L@UCSBVM.ucsb.edu
> > >cc:    (bcc: Brad Martin/Bsg/MetLife/US)
> > >Subject:  Re: Strange Cisco traps....
> > >
> > >
> > >
> > >I find the tcp connect close very useful as it enables you to know when
> > >someone has logged out of a Cisco router/switch and implement some
>change
> > >controll as a result.  I then have an associated script with this trap
> > >which
> > >pulls the config from the device in question and compares to a
>previsouly
> > >active configuration for the device to see if any changes have occured,
> > >saving
> > >the new config it necessary.  Cisco works 2000 provides some of this
> > >automation automatically but CiscoWorks 4 didnt hence the scripting !
> > >
> > >Cheers...db
> > >
> > >
> > >
> > >
> > >From:   waddle1%US.IBM.COM@Internet on 30/11/99 17:27 MST
> > >To:     NV-L%UCSBVM.ucsb.edu@Internet
> > >cc:      (bcc: David Barnwell)
> > >Subject:        Re: Strange Cisco traps....
> > >
> > >The Cisco is sending a trap for when it closes a TCP connection -- like
>a
> > >telnet, or similar.  I'll bet that if you telnet to your routers and
> > logout
> > >repeatedly, these traps will be numerous.  Also, DLSW uses TCP for its
> > >services, probably leading to more traps related to this.
> > >
> > >So far, I have not found a way to turn this off, short of disabling ALL
> > >traps.
> > >
> > >--D
> > >
> > >Duane Waddle
> > >waddle1@us.ibm.com
> > >"With sufficient thrust, pigs fly just fine..."  -- RFC1925
> > >
> > >
> > >"Fendrick, Gib (CC-MIS)" <Gib.Fendrick@CONAGRA.COM> on 11/30/99
>04:55:57
> > PM
> > >
> > >Please respond to Discussion of IBM NetView and POLYCENTER Manager on
> > >       NetView <NV-L@UCSBVM.UCSB.EDU>
> > >
> > >To:   NV-L@UCSBVM.UCSB.EDU
> > >cc:
> > >Subject:  Re: Strange Cisco traps....
> > >
> > >
> > >
> > >
> > >Gord,
> > >I am new to Netview/AIX and still learning the system, so I don't know
> > much
> > >about the internals flow of events/traps through the system.  I've seen
>a
> > >similar situation receiving this trap, but it seems to process
>correctly.
> > >
> > >I am also receiving many 'tcpConnectionClose' traps from two of my
> > >core/central switches and one core router.  No one has figured out why
> > yet.
> > >The first time this started happening, our Cisco engineer stopped the
> > traps
> > >by shutting off those snmptraps in the switch and router involved, i.e.
> > >didn't fix it, just stopped forwarding the traps to NetView.  Recently
>we
> > >moved one of our central DLSW peers over to a new 7204 Cisco router,
>and
> > >another switch started generating many of the 'tcpConnectionClose'
>traps.
> > >Still, no one knows why.  But we ASSUME it has something to do with the
> > >DLSW
> > >traffic.
> > >
> > >To your question on the SNMP MIB ID.  We had no problem here.  The trap
> > was
> > >defined in the Cisco enterprise 1.3.6.1.4.1.9, and the trap event was
> > >displayed correctly in the event display.  To temporarily keep the
>event
> > >off
> > >the event display, I went in to the Options-->Event
>Configuration-->Trap
> > >Customization:  SNMP... and selected the CISCO enterprise, then
>selected
> > >the
> > >Cisco_tcpConnectClose event, and modified it to 'log only' to keep the
> > >event
> > >off the event display.   It sounds to me like you have this same
> > Enterprise
> > >defined on your system and it also contained this event, but the event
>is
> > >not displaying correctly in your event window.  I have no idea why your
> > >system wouldn't match up the incoming trap to the event defined.
> > Hopefully
> > >someone else with more trap experience can help, otherwise Tivoli tech
> > >support.
> > >
> > >If you ever find out why the tcpConnectionClose traps are being
> > generated,
> > >let us know.
> > >
> > >Gib Fendrick
> > >
> > >
> > >
> > >                 -----Original Message-----
> > >                 From:   Gord Michaels
>[mailto:gord_michaels@HOTMAIL.COM]
> > >                 Sent:   Tuesday, November 30, 1999 2:43 PM
> > >                 To:     NV-L@UCSBVM.UCSB.EDU
> > >                 Subject:        Strange Cisco traps....
> > >
> > >                 Hello All.
> > >
> > >                 My config is: Netview 5.1.1 and AIX 4.2.1.
> > >
> > >                 I have placed the loopback address of all my routers
>in
> > my
> > >seedfile. They
> > >                 have been
> > >                 discovered no problem.
> > >
> > >                 I keep receiving many "tcpConnectionClose" traps from
> > >individual IP
> > >                 Interfaces on
> > >                 my Cisco routers. The strange thing is that these
>traps
> > >belong to
> > >                 enterprise:
> > >
> > >                 1.3.6.1.4.1.9.9.29
> > >
> > >                 Now, I used the cisco addtrap script to add a known
> > cisco
> > >traps to my
> > >                 trapd.conf file.
> > >                 But, there was no Enterprise with this ID.
> > >
> > >                 However, in the Enterprise 1.3.6.1.4.1.9, this trap
>did
> > >exist?? This seems
> > >                 very strange.
> > >                 Anyway, I had to edit this Enterpirse (1.3.6.1.4.1.9)
> > and
> > >change it (and all
> > >                 it's
> > >                 individual trap definitions within trapd.conf) to
> > >Enterprise
> > >                 1.3.6.1.4.1.9.9.29.
> > >
> > >                 Something seems very wrong with having to do this. Has
> > >anyone ever came
> > >                 accross this
> > >                 problem before??
> > >
> > >                 Any info appreciated.
> > >
> > >                 Sincerely,
> > >
> > >                 Gord Michaels.
> > >
> > >                 ______________________________________________________
> > >                 Get Your Private, Free Email at http://www.hotmail.com
> >
> > ______________________________________________________
> > Get Your Private, Free Email at http://www.hotmail.com
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web