05-20-2007 04:12 PM
I am getting the following error in several devices in our network.
The 10.1.10.25 is the Ciscoworks server, I have reset the SNMP strings several times and cannot trace where the error is coming from.
Has anyone experienced this?
May 18 14:04:15.333: %SNMP-3-AUTHFAIL: Authentication failure for SNMP
req from
host 10.1.10.25
05-20-2007 04:27 PM
If you're absolutely sure the community strings in LMS are correct, the most likely cause of this problem is Campus Manager and community string indexing. What type of device is this? I'm betting it's an IOS switch. If you gather a packet capture of the SNMP traffic triggering this trap, it may be possible to prevent it.
05-20-2007 07:49 PM
You are right j,
I am seeing this same message in several switches (6509).
What in Campus Manager and community string indexing causes this problem?
05-20-2007 08:58 PM
User Tracking uses community string indexing to get end hosts from each VLAN. ANI uses community string indexing to get STP information for each instance of spanning tree. A sniffer trace is needed to see which it is.
05-21-2007 06:36 AM
Thanks J,
How would I change the user Tracking or the ANI SNMP community strings once I determine which one it is?
05-22-2007 01:06 PM
You don't. You have to manipulate options in ANIServer.properties (typically to disable polling of invalid VLANs). The root strings are most likely correct, but the index suffix is not valid. This of course is just a guess at this point. A sample trace of this would give a very clear picture of what is going on.
05-22-2007 02:35 PM
We had the exact problem:
RE: TAC Case:604897427
Fix: Disable Periodic Polling in CiscoWorks.
05-22-2007 03:00 PM
Thanks for the reply, I appreciate it.
05-22-2007 03:20 PM
I cannot find that case in TAC.
Are you sure the number is correct?
05-22-2007 03:34 PM
CASE# 604897427
You might need to query TAC and ask why this isn't avialable to you?
Here's some of the correspondance history:
From: xxxx@cisco.com
Subject: 604897427 CiscoWorks %SNMP-3-AUTHFAIL:
Sent: 15-JAN-2007 15:21:35*** Service Request LOG 2007-01-16 15:10:43.0 GMT, EDUAMOLI, Action Type: Email Out ***
From: xxxx@cisco.com
Subject: 604897427 CiscoWorks %SNMP-3-AUTHFAIL:
Sent: 16-JAN-2007 15:10:43*** Service Request LOG 2007-01-18 13:42:23.0 GMT, EDUAMOLI, Action Type: Email Out ***
From: xxxxx@cisco.com
Subject: 604897427 CiscoWorks %SNMP-3-AUTHFAIL:
Sent: 18-JAN-2007 13:42:23*** Service Request LOG 2007-01-19 14:19:18.0 GMT, W-NAKAMA, Action Type: Web Update ***
Thank you to Eduardo and Luis for helping on this problem. I have not received
a failed snmp authentication, since we disabled Periodic Polling. Will this
work-around solution be posted for everyone to see. On NetPro community, other
people are reporting same problem.
Thank you again,
*** Service Request LOG 2007-01-19 15:21:02.0 GMT, xxxxx, Action Type: Phone Log ***
Hit VM*** Service Request LOG 2007-01-19 15:22:51.0 GMT, xxxxx, Action Type: Email Out ***
From: xxxxx@cisco.com
Subject: 604897427 CiscoWorks %SNMP-3-AUTHFAIL:
Sent: 19-JAN-2007 15:22:51*** Service Request LOG 2007-01-19 15:23:54.0 GMT, EDUAMOLI, Action Type: Problem Description ***
%SNMP-3-AUTHFAIL emails from CW*** Service Request LOG 2007-01-19 15:23:54.0 GMT, EDUAMOLI, Action Type: Resolution Summary ***
Disable Periodic Polling
05-22-2007 03:38 PM
Thanks again I appreciate it,
But where the heck do you disable the periodic polling?
I can't find it anywhere in Cisco works.
I have a polling job in RME but it is only scheduled every 24 hours.
The authentication failures I am seeing are every two minutes.
05-22-2007 03:44 PM
Send me an email off-line and I'll send the entire t-shooting process TAC made us execute.
05-22-2007 06:06 PM
Disabling config archive periodic polling is not an ideal solution. The real solution will be to track down exactly what is causing the AUTHFAIL messages, and simply correct the bad polling. I looked at the sniffer traces in this SR, but they are only uni-directional. That is, I only see traffic bound to the CiscoWorks server.
I have also not seen a case where periodic polling causes AUTHFAILs unless the community string in DCR for the device is wrong. I would still like to see a good bi-drectional sniffer trace showing the problem, and I am sure I can isolate the true cause.
05-23-2007 03:22 AM
Thanks j,
If I do a sniffer trace on the switch, which interface do I look at?
Would it be the interface defined in ACS?
Also, on the switch, how is it decided which interface is the one used for TACACS authentication if it is not defined in the config?
05-23-2007 08:04 AM
Since the AUTHFAILs are being triggered by CiscoWorks polling, do a sniffer trace on the CiscoWorks server, and filter on the IP address of one of the switches as it appears in DCR. So, yes, it would have to be the IP address defined in ACS.
If you are not specifying a source address for TACACS+, the switch will use the interface closest to the AAA server to source its packets.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: