Unanswered Question
Jul 24th, 2007


We are seeing snmp authentication failures on a switch which we are managing with CiscoWorks LMS 2.6

Looks like a clear error, so I changed the device login credentials in Common Services > Device Management, but that didn't seem to solve the problem.

Even deleting the whole device didn't solve the problem.

Does anybody know if there is another place were I should change the device credentials?

Thanks in advance,


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 1 (2 ratings)
Joe Clarke Tue, 07/24/2007 - 08:11

It would really depend on what is being polled in those SNMP packets, and what type of device this is. A sniffer trace would shed light on the former. The most likely cause for this problem is Campus Manager User Tracking, but only if this is a switch.

hendriksm Thu, 07/26/2007 - 01:34

Hi Joe,

Thanks for your reply!

It seems it's the Campus Manager Data Collection process which is causing this, because when I removed all the schedules the snmp authentication messages disapeared.

When I start the Data collection again, the problem is back.

But now the question, where can I change the snmp authentication settings for the data collection???

Kind regards,


Joe Clarke Mon, 07/30/2007 - 12:42

The problem most likely has to do with the polling of inactive VLANs. The best way to troubleshoot this is to get a packet capture of the bad SNMP requests. This will help determine exactly which part of CM is doing the polling, and will help with fixing it.

agiacometti Wed, 07/25/2007 - 11:00

Hi, i had the same issue, this is my storie and recomendation...

First, this snmp-auth-fail is a trap, this trap cannot be analized in CiscoWorks (neither is loged the detail that we need here), so you have to forward it to another platform (i use a linux with the trapd demon).

Then i search the log of trapd, there you will find WHO is tring to query throu SNMP your network device, and therefore WHO is the responsible of this auth-failure

If the credential are OK on the CiscoWorks, then this trap shouldnot be generated by an incorrect access of the CW, so, you have to find WHO else is trying to get the network devices.

Hope this help!

Pushkar Sambhoos Mon, 07/30/2007 - 00:04


The trap is generated when a snmp request is received by the switch with an incorrect SNMP community string. You can initiate a packet capture on the switch to check for the source of the snmpgets with an incorrect community string.

-- Pushkar

hendriksm Tue, 10/02/2007 - 01:03

Hi all,

It seems that CW User Tracking doesn't always like "@" signs in the snmp community string.

The combination of a certain version of IOS, hardware type and CW, causes the device not to show up in CW User Tracking.

When I changed the community string on the devices that where missing in the end-host report, the problem was solved!

Kind regards,



This Discussion