LMS notification

[jorjes1984]

Hi Everyone

I am receiving a loooot of e-mails alerts (60-70 alert per day) from the LMS notifications

The below alert is what i am receiving:

ALERT ID = 0000AWC

TIME = Tue 12-May-2009 16:19:45 EEST

STATUS = Active

SEVERITY = Critical

MANAGED OBJECT = 172.16.99.1

MANAGED OBJECT TYPE = Switches and Hubs

EVENT DESCRIPTION = 172.16.99.1: Authentication Failure:MinorAlarm; 172.16.99.1:Unresponsive;

CUSTOMER IDENTIFICATION = 1

CUSTOMER REVISION = 1

After searching in the forum and on cisco, i found that this error could be caused by some1 trying to access the switch using a wrong snmp community

So i created an access-list:

access-list 3 permit 192.168.100.1

access-list 3 deny any log

snmp-server community snmpcom RO 3

I made sure that the LMS IP(192.168.100.1) has the correct community configured. ( i did the self test).

The following day i kept receiving the same notifications, and there was no MATCHING on the deny IP any in the access-list,so that confused as i made sure that no one else is trying to access the router.

Can any one advise what could be done further to troubleshoot the problem??

Note that they have Dot1x configured globally on the switch:

dot1x system-auth-control

archive

log config

logging enable

logging size 500

notify syslog

but it is not configured under any physical interface

Regards,

[Joe Clarke]

If you've narrowed down the problem to the LMS server, then start a sniffer trace on this server filtering on UDP port 161 traffic to this device. You should then see the SNMP packets which contain the wrong community string. The objects being polled in those packets (as well as the community) should help determine where the problem lies.

[jorjes1984]

Hello

I generated the DEVICE CREDENTIAL Verification JOB from the RME. and got the below report.

So could it be the LMS that is causing this error???

[Joe Clarke]

Yes, it could still be LMS that is the problem. This is why the sniffer trace is important. Seeing the requests being made, it will be possible to narrow down the problem to a specific application.

[Joe Clarke]

Plus, this report is old. In order to confirm the current DCR Credentials are correct, you will have to run a new Device Credential Verification job from RME > Devices > Device Management > Device Credential Verification Jobs.

[jorjes1984]

is it confirmed that the error that i am receiving is caused by a wrong SNMP access?

[Joe Clarke]

Yes, that is what this event means. Something is polling the device with the wrong community string.

[jorjes1984]

Hi There

I need to ask something

if we have an access-list applied on the SNMP-SERVER community, does users that are denied in the acl are denied before providing the wrong snmp??

What i mean is in my case where i have

access-list 3 permit ip 192.168.1.1

access-list 3 deny any

snmp-server community cisco RO 3

if any user else than the 192.168.1.1 try to access the Switch, will the wrong snmp be sent before being denied by the access-list??

Should i get the same authentication failure message even if the user (with the wrong SNMP) has been denied by the Access-list??

[Joe Clarke]

You should get an authFail trap in addition to a hit on your deny ACE.