Ciscoworks messages - hundreds of them

mzsaad123 · ‎03-20-2007

Hello,

I have a two 6509 core switches.

They are configured for HSRP.

143.61.184.1 is the IP of one of them and 143.61.184.2 is the IP of the second one.

I am getting these two emails in my mail every few minutes from Ciscoworks. Everything seems fine on the switch.

Here are the messages:

ALERT ID = 00000S9

TIME = Thu 15-Mar-2007 15:43:42 EST

STATUS = Active

SEVERITY = Critical

MANAGED OBJECT = 143.61.184.1

MANAGED OBJECT TYPE = Switches and Hubs

EVENT DESCRIPTION = 143.61.184.1: Authentication Failure:MinorAlarm; IP-143.61.184.1:Unresponsive; 172.32.74.1: Authentication Failure:MinorAlarm; 143.61.48.251:Unresponsive; 143.61.48.251:Unresponsive;

Here is the seond message:

EVENT ID = 00000XC

ALERT ID = 00000S9

TIME = Thu 15-Mar-2007 15:43:42 EST

STATUS = Cleared

SEVERITY = Informational

MANAGED OBJECT = 143.61.184.1

MANAGED OBJECT TYPE = Switches and Hubs

EVENT DESCRIPTION = MinorAlarm::Component=143.61.184.1: Authentication Failure;

172.32.74.1, 143.61.48.251 are the vlan interface IPs. The virtual IP of HSRP doesnt show anywhere on the mail.

I did a readup on cisco.com however wasn't able to find the reason.

Any help would be appreciated.

koeser · ‎03-20-2007

Hi,

you can ping to 172.32.74.1 and 143.61.48.251 from your ciscoworks-server ?

If not you must set the managment state of this interface to false.

K.

mzsaad123 · ‎03-20-2007

Thanks for reply.

Both pings are successful from Ciscoworks.

Joe Clarke · ‎03-20-2007

The alert email isn't so useful. It's the events you need to focus on. They represent the atomic device problems. The event in your first post is an authentication failure event. This indicates that DFM is receiving an authenticationFailure trap from this device. That means that some node in the network is polling this device with the wrong community string.

Since this is a cleared event, that means DFM has timed it out. However, you should check to see which node is doing the polling, and stop it.

mzsaad123 · ‎03-21-2007

Are you 100% this is due to community string?

Nothing has changed in the topology.

The only difference is that there is a new 3845 on outside the Checkpoint. (6509 which is reporting is inside)

However the new 3845 has been added in the Ciscoworks today.

Still no success :(

Joe Clarke · ‎03-21-2007

Yes, these are related to a network manager polling this device with the wrong community string. See http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/dfm/dfm206/ug/trapfwd.htm . You can get a sniffer trace of incoming traps to the DFM server and see if the trap contains the IP address of the offending server.