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.
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?
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?
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.
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.
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?
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.
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?
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
File UT.properties does not exist. What I have to do for eliminating this trap?
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.
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.
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.
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.
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. public@6 when vlan 6 is not valid for that device). Such a request would not have a corresponding SNMP response.