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
|