Thanks Leslie.
I believe your theory is correct. There were multiple address entries for
all of these. After I ran the xnmsnmpconf -delete on the IP address and I
implemented Dermot's suggestion most of the traps disappeared. I was able to
determine that a CiscoWorks server was the cause of other authentication
trap failures as well.
Thanks.
----- Original Message -----
From: "Leslie Clark" <lclark@us.ibm.com>
To: "IBM NetView Discussion" <nv-l@tkg.com>
Sent: Wednesday, June 13, 2001 10:30 PM
Subject: RE: [NV-L] authentication failure trap
> In the cases where it is Netview causing the trap, and if it happens
> when you demandpoll, take a look at the entries in xnmsnmpconf.
> There should be only one, and it should be for the Selection Name
> of the node. I've been seeing more than a few cases in which
> there are address entries in there but no name entries. Delete the
> address entries, add the name entry, and it should clear up. This
> will happen if the name resolution was added after the node was
> discovered, but not always, and probably under some other
> circumstances which are not yet clear to me. I also see it, of
> course, when people go around changing the communities on
> things without telling the Netview Admin. Demandpoll will complete,
> because it tries everything (generating traps), but mib appls will fail
> because they use an old record in xnmsnmpconf (generating traps).
> In theory, setting netmon to use the alternates 'every time' for the
> course of config poll or two (generating traps) will clear stuff up.
>
> Dermot, thanks for that tip, I'll file it!
>
> Cordially,
>
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
> (248) 552-4968 Voicemail, Fax, Pager
>
>
> "O'Neill, Dermott" <ONeillD@aetna.com>@tkg.com on 06/13/2001 02:03:41 PM
>
> Please respond to IBM NetView Discussion <nv-l@tkg.com>
>
> Sent by: owner-nv-l@tkg.com
>
>
> To: "'IBM NetView Discussion'" <nv-l@tkg.com>
> cc:
> 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
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
>
>
> _________________________________________________________________________
|