CUOM 2.3 sends multiple notifications for Event StoppedGSUPerformancePolling with same time stamps

[michaelstotz]

Hi Alll,

I have a CUOM Version 2.3 which shows mutiple notifications per Device for Event StoppedGSUPerformancePolling with same time stamps. The message below is generated from the default All_Events for all devices.

Does anyone have a solution for that.

Regards Michael

This message is generated 8 times with the same time stamp in all messages.

** This message is generated from Cisco Unified Operations Manager **

ALERT ID                = 00012OW

CREATION TIME           = Sat 30-Oct-2010 16:31:57 CEST

MODIFIED TIME           = Sat 30-Oct-2010 17:00:58 CEST

STATUS                  = Active

SEVERITY                = Critical

MANAGED OBJECT          = 183.201.141.193

MANAGED OBJECT TYPE     = VoiceGateway

ASSOCIATED EVENTS       =

    Cleared:183.201.141.193:Unresponsive

    Active:183.201.141.193:StoppedGsuPerformancePolling

CUSTOMER IDENTIFICATION = Voice Port

CUSTOMER REVISION       = Voice Port

[Scott McDonald]

Michael,

If you look in the CSCOpx\log\gpf\poller.log you should see snmp timeouts for this device. The alert is notification of this temporary lost of polling between CUOM and the device. This could be due to network connectivity or the device being busy (SNMP packets are low priority, and since it’s UDP packet it will not retransmit). Since this specific alert had the device coming out of an "Unresponsive" state, the gpf polling would still be active until the next successful poll (every 4 mins).

scott

[Brian McPhillips]

I Have recently upgraded from 2.1 to 2.3 and im receiving these alerts also. I have checked the event set and this is not ticked but still alerting? Can i remove this alerting or is it advisable to leave it on? i cant see any issue with the Voice gateways at the time, some are being generated in the middle of the night so there would be no performance issues or major network activity.

[Michel Hegeraat]

if you get SNMP timeout on multiple devices then the fault usually lies in the path that the polling follows to get to these devices and back to the server.

The problem obviously lies in the part path they have in common.

It is not unusual to see the highest backbone loads during the night, due to backups being taken.

Make sure the most important inter-switch links have no errors.

I would rather fix this then turn off alerting.

Cheers,

Michel