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
|