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
|