DFM - Authentication Failure Alert

Unanswered Question
Jul 11th, 2007

I am receiving alerts in DFM for "Authentication Failure" on a device that I am monitoring with DFM. The only info I can find about the alert is the name of the alert and the type of alarm. In this case, a "minor alarm". I would like to know what is device is causing the failure as it involves my network core switch. Does anyone have any ideas on how to find out what is causing this alarm?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Joe Clarke Wed, 07/11/2007 - 21:42

For this, you will need to sniff the trap on the wire, or forward the trap to another NMS that can break the varbinds out to provide more detail.

bm_5789 Thu, 07/12/2007 - 06:05

I used the Packet Capture feature supplied by CiscoWorks and could not pinpoint what is causing the Authen Failure.

Joe Clarke Thu, 07/12/2007 - 07:51

Some devices may send the generic SNMPv2 authentication failure trap without any varbinds, but most Cisco devices send a version that includes the address of the host that did the poll.

If the varbind is missing from the trap, then you would need to move your sniffer closer to the device to find out who is doing the polling (i.e. capture the offending SNMP request packet). Alternatively, if this is an IOS device, you can use "debug snmp packet" to get see who is polling the device.

hgans Wed, 04/04/2012 - 00:43

Is it possible to filter such kind of alerts from LMS alert view?

I had couple of LMS installations lately and on every network these authentication alerts show up.

Now customers want to filter these messages out of DFM to get rid of them...



Joe Clarke Wed, 04/04/2012 - 07:12

They are unsolicited traps so provided DFM is seeing them, they will be shown.  You could disable authFail traps on the device, but you may be missing some important security issues. It would be better to isolate why the traps are being sent in the first place to determine if you have a misconfiguration or someone is trying to compromise the network.

hgans Fri, 04/06/2012 - 00:10

ok understand.

The thing in our case is the failed authentication source is reported as the LMS server which has granted SNMP access to the monitored nodes.

Do you have experience with such kind of issues?

Otherwise our next step would be to capture some of these SNMP packets to examine if the reported auth failed node is really the LMS server...


Joe Clarke Fri, 04/06/2012 - 00:17

The packet capture is definitely what you should do next.  The community string used and the objects being polled will indicate what in LMS is doing the polling.


This Discussion