User guide

C-49
Cisco Media Gateway Manager 5.0 User Guide
OL-5461-02
Appendix C Troubleshooting
Configuration Center, Chassis View, Diagnostic Center and Statistics Report Problems
Step 2 If the suspect alarm is not in the list above, and it is displayed in the alarm list and not on the platform,
it may be defect. See below for troubleshooting further
a. Verify whether DB has correct alarm state, refer to the DB schema document for information on
what table to lookup for this particular entity type.
b. Collect the information requested in Defect information section.
Defect Information—Collect the following information for further analysis:
• Collect topod.log, linktopoc.log, ILMITopoc.log, NMServer.log, fileTopoc.log
• Collect nmControl.dump for option 3.
• Collect CMSCclient.log
Possible alternative workaround—Open a new GUI and a new Cisco MGM MGXNE Specific GUI
(CC,DC,CV,SRT)
C.6.5.6 Transient Event Has Disappeared Unexpectedly
Transient alarms behave somewhat differently depending on whether the entity is managed network
element, or the NMS itself. If the transient alarm is on a managed network element, such as a 'FTP
transfer failed', then the alarm is self-clearing. This means if the same transient alarm happens twice or
more, the previous active alarm is cleared by the latest.
If the transient alarm is not a managed network element, but rather the NMS itself, then the alarm is not
self-clearing and there will be multiple of the same alarm conditions. Since these NMS alarms (or
Events) that pertain the NMS, are not cleared by the NMS, NMS alarms are not correlated. They must
be cleared manually by the operator. If these events are not manually cleared, the list will grow only to
the value of MAX_ACTIVE_NMS_EVENTS that is specified in the NMServer.conf file. Once the list
of NMS alarms reaches MAX_ACTIVE_-NMS_EVENTS, NMServer will automatically clear the oldest
alarms in the list to make room for the new events. The number of events that will be cleared each time
the max is reached is also specified in NMServer.conf. That configuration parameter is called
EVENTS_TO_CLEAR_WHEN_MAX_REACHED.
If there was a transient event that has unexpectedly disappeared, it is most likely because NMServer is
purged the event. Follow these steps below to investigate the issue.
Step 1 Filter the alarm list on Cisco MGM alarms
Step 2 Check the alarm count and compare it with the MAX_ACTIVE_NMS_EVENTS value in
NMserver.conf. If the alarm count is close to the MAX_ACTIVE_NMS_EVENTS, then this explains
why the transient event has been purged.
Step 3 If the alarm count for NMS alarms is nowhere near the MAX_ACTIVE_NMS_EVENTS the missing
event may have been manually cleared. The NMServer log will indicate whether the event was manually
cleared.
Defect Information—Collect the following information for further analysis:
• Collect CMSCclient.log, NMServer.log, CMSCclient.log
• Capture NMServer dump, option 3 in nmControl.
Possible alternative workaround—Restart Alarm List GUI.