SNMP Authentication Failure 1.3.6.1.6.3.1.1.5.5

Unanswered Question
Sep 5th, 2009

Hi,

Call Manager 6.x Pub-Sub configuration running fine. SNMP configured in Serviceablity for version 2c, a community string, and a destination trap address (Windows Server running a third party monitoring software that polls via snmp all devices on the network so we can monitor snmp notifications.)

An snmp scan shows snmp active on the Call manager servers, and we are getting enterprise specific traps and the like,

however, in our monitoring software we keep getting this alert every second:

Authentication Failure 1.3.6.1.6.3.1.1.5.5

from the Call manager servers, no matter what the access privilege is set to. This alert every second is overloading the database the monitoring software uses.

I've been trying to figure out why this authentication failure keeps occuring every second and am stuck.

Temporarily, I have reconfigured the snmp properties on the Call Manager Servers to version 2c, community string, read only, with no destination trap address. This has stopped the authentication failure traps, but i think it has/will stop the application from any other traps as well.

"An authenticationFailure trap signifies that the SNMP

entity has received a protocol message that is not

properly authenticated. While all implementations

of SNMP entities MAY be capable of generating this

trap, the snmpEnableAuthenTraps object indicates

whether this trap will be generated."

Do i have to disable Authentraps on the call manager server to keep a destination address for traps and avoid the failure alert every second, and if so, does anyone know how to do that on the call manager server?

Thanks in Advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
gogasca Tue, 09/08/2009 - 22:34

Hi,

The OID .1.3.6.1.6.3.1.1.5.5 translates to authenticationFailure. This is

an authentication failure trap that your device is sending. What this means

simply is that someone used an incorrect SNMP community to poll your device.

You will get such a trap each time this occurs. If you wish to know the

source (who is polling with the incorrect community) you can setup a sniffer trace during the time you are getting the authentication failure traps and you will have your source IP (whoever is polling with incorrect

credentials).

HTH

Actions

This Discussion