SNMP-3-AuthFail

Unanswered Question
Mar 3rd, 2008
User Badges:

I am getting this error on my Cisco Catalyst 6509 Switches. I verified that the AniServer.properties values for 0, but for some reason it looks like they keep getting reverted back to 1 (UTGetSuspendedVlans and UTGetVlansOnDownPorts). Has anyone else faced this issue I am an admin on the CiscoWorks Server.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joe Clarke Mon, 03/03/2008 - 09:47
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

What version of LMS?

dionjiles Mon, 03/03/2008 - 09:59
User Badges:

I'm running LMS 3.0 but I do plan on upgrading to LMS 3.0.1 this weekend.

Joe Clarke Mon, 03/03/2008 - 10:27
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

Then you need to check ut.properties to make sure these property values are correct.

dionjiles Mon, 03/03/2008 - 10:39
User Badges:

The values I changed in the AniServer.properties are different in the UT.properties file. Should I change those values to 0 as well?


Do I need to send you my logs so you can see what I'm seeing?

Joe Clarke Mon, 03/03/2008 - 10:45
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

Shutdown dmgtd, and change ut.properties to have the desired values. The UTGetSuspendedVlans property is also applicable to ANIServer.properties, so change it there as well. Then restart, perform a new Campus Data Collection, then a new UT acquisition. Does the authFail problem go away?

dionjiles Mon, 03/03/2008 - 10:49
User Badges:

I will let you know later on today as I have to wait after-hours to perform any maintenance on the server per company policy.

dionjiles Tue, 03/04/2008 - 05:34
User Badges:

I performed the actions on the server last night. I will notify my engineers to clear logs on the affected devices and see if the problem goes away.

dionjiles Tue, 03/04/2008 - 11:10
User Badges:

It seems as though I'm still showing those errors is there anything else I need to check?

Joe Clarke Tue, 03/04/2008 - 11:19
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

The first step would be to get a sniffer trace of the polling to see exactly which community string is triggering the authFail problem. If it's VLAN-related, the objects in the trace will tell us if it's UT or Data Collection. The next steps will depend on what is found in the trace.

dionjiles Tue, 03/04/2008 - 12:46
User Badges:

This can be done in CiscoWorks correct via the device center packet capture feature. Do I run the Data Collection in Campus Manager and run the packet capture against it?

Joe Clarke Tue, 03/04/2008 - 13:09
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

Yes, the packet capture can be run using the Packet Capture tool in Device Center. You should run a Data Collection, and correlate the authFail message timestamps to packets in the trace. The same method should be done for UT.

dionjiles Wed, 03/05/2008 - 12:36
User Badges:

Just a quick follow up....i ran packet trace against the data collection and no errors were found. However my UT acquisition has been running for like a full day now...is there any way to stop it?

Joe Clarke Wed, 03/05/2008 - 13:08
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

You can pdterm UTMajorAcquisition, and that will stop UT.

ibakanchev Thu, 03/06/2008 - 06:17
User Badges:

I have the same problem with LMS 2.6.Catalyst 6509 generates this trap when it receives SNMP-request from LMS Data Collection with community string @mst-0. File

ANIServer.properties:

UTGetSuspendedVlans=1

UTGetVlansOnDownPorts=1

File UT.properties does not exist. What I have to do for eliminating this trap?


dionjiles Thu, 03/06/2008 - 06:48
User Badges:

Hi JClarke,


I did exactly what you told me to do to troubleshoot this matter with no luck. No errors were found I have asked my engineer to take a look at the other two Cisco Catalyst 6509 devices which I don't see any errors in the show logging statements to see if he can see what's going on.

Joe Clarke Thu, 03/06/2008 - 08:36
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

What do you mean, no errors were found? Did the authFail messages stop? The steps I gave you weren't designed to produce errors. The sniffer trace will show SNMP packets. The packets that correspond to authFail messages will be of interest, as those are polling with an invalid SNMP community.

dionjiles Thu, 03/06/2008 - 10:53
User Badges:

So for not providing enough info. I verified the trace with the authfail messages from the logs and verified that the right SNMP community was being polled.

Joe Clarke Thu, 03/06/2008 - 10:59
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

But what about the indexes? The community string itself will be correct. It's a matter of the "@X" indexes that is causing the authFails. Figuring out what objects are being polled will tell us what component has the wrong indexes, and what needs to be troubleshot.

dionjiles Thu, 03/06/2008 - 11:55
User Badges:

Is this close to somewhat you are looking for. If not I will have my engineer take another look at it.





Attachment: 
Joe Clarke Thu, 03/06/2008 - 12:00
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

No, this would not cause authFail events. An authFail would be triggered by an SNMP packet with a community string that the device does not recognize. This could be an obviously incorrect string, or a VLAN index which does not exist or is suspended on the device (e.g. [email protected] when vlan 6 is not valid for that device). Such a request would not have a corresponding SNMP response.

Actions

This Discussion