Thanks very much Dermott for the excellent advice. I was able to implement
the suggestion this morning. By 8 a.m. I had successfully stopped 90% of the
traps. The rest come in bursts and the trap definition now provides the
source. It is a Cisco Works server. The admin occasionally forces a
discovery.
Ray
----- Original Message -----
From: "O'Neill, Dermott" <ONeillD@aetna.com>
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
Sent: Wednesday, June 13, 2001 1:03 PM
Subject: RE: [NV-L] authentication failure trap
> Hey Ray,
>
> Try formatting the trap as follows:
> Cisco_Auth_Failure {1.3.6.1.4.1.9} 4 0 A 2 0 "Status Events"
> Cisco Incorrect Community Name (authenticationFailure Trap) authAddr: $1
>
> This should show the address of the box that caused the authentication
> failure
> on the Cisco router - only cisco though, I dont think other vendors have
> populated
> the trap with this varbind.
>
> If it is a cisco box you could also loop thru all the routers in your
> collection/Smart set to see who caused previous authentication failures
> just as an fyi,
> since they may be the culprits causing authentication failures against
other
> boxes that dont report the failures.
> The authAddr is a cisco local variable,
> snmpwalk cisco_box 1.3.6.1.4.1.9.2.1.5.
> yielding:
> cisco.local.lsystem.authAddr.0 : IpAddress: 10.10.8.39
>
> Good Luck,
> --Dermott
>
> -----Original Message-----
> From: Westphal, Raymond [mailto:RWestphal@erac.com]
> Sent: Wednesday, June 13, 2001 12:16 PM
> To: NV List (E-mail)
> Subject: [NV-L] authentication failure trap
>
>
> Hello Everyone.
>
> Managing NetView for UNIX 6.0.2 on AIX 4.3.3.
>
> My trapd.log shows numerous authentication failure traps from Cisco
switches
> and routers. I have verified that NetView is the source in many cases. As
> soon as I demand poll the device, the trap is generated. xnmsnmpconf
> -resolve did show the proper configuration in NetView. The default
> configuration for read and write community strings was correct for these
> devices; it did apply to these devices. However, the authentication
failure
> traps did not stop until I deleted the entry from ovsnmp configuration
> database with the xnmsnmpconf -delete command.
>
> So here are my questions:
> Does the ovsnmp database contain single entries for a device or does it
> contain multiple entries? In other words, is there an entry in the
database
> for the short name, another entry for the fully qualified domain name, and
a
> third or more entries for the IP address(es)?
>
> I have one router that continues to generate authentication failure traps.
I
> cannot use debug on the router to determine the source of the snmp query
of
> the router. Can I use the trapd -T trace command to determine who is doing
> the query? If I need the hexadecimal trace (-x option) - can you tell me
how
> to decode the packet?
>
> Thanks.
>
>
> Ray Westphal
> Enterprise Rent-A-Car
>
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
> _________________________________________________________________________
|