These 'tcpConnectionClose' traps from Cisco routers are spit out
whenever you telnet into and out of your router. If you are seeing
them in absence of a telnet session, you could have an IOS issue.
I've also seen them generated as a result of management polling,
eg. Ciscoworks, etc...
And the amount of granularity you have over controlling these specific
traps at the source is also IOS dependent.
"Fendrick, Gib (CC-MIS)" wrote:
>
> 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
|