Cisco Systems 78-16845-01 appendix Transient Event Has Disappeared Unexpectedly

Appendix J Troubleshooting

J.10.5 Configuration Center, Chassis View, Diagnostics Center, and Statistics Report Problems

Possible alternative workaround—Open a new GUI and a new Configuration Center, Chassis View, Diagnostics Center, or Statistics Report.

J.10.5.5.6 Transient Event Has Disappeared Unexpectedly

Transient alarms behave somewhat differently depending on whether the entity is managed by the network element or the NMS itself. If the transient alarm is on a managed network element; for example, an alarm generated by an FTP transfer failure, then the alarm is self-clearing. This means if the same transient alarm happens more than twice, 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 occurrences of the same alarm conditions. Since these NMS alarms (or events) that pertain to 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 maximum 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 purged the event.

Step 1 Filter the alarm list on CTM 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 has not reached 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:

•CMSCclient.log, NMServer.log, and CMSCclient.log

•Capture NMServer dump, use nmControl

Possible alternative workaround—Restart the Alarm List GUI.

J.10.5.5.7 Port in Tree View Displays Aggregate Alarm; However, No Children Exist Under Port

The tree view in CTM client GUIs displays network elements from the top-level physical view down to the port. Alarm severities are aggregated from children up to parents. Since the port is at the lowest level of the tree, the question that often arises is how a port can have an aggregate alarm if it has no children. The answer to this question is that connections are virtual entities under ports in the tree view. Virtually, you will not see connections in the tree. But connection alarms are aggregate up to the port in the tree view.

Step 1 Compare the connection alarms with the aggregate port alarms:

a.In the Configuration Center, click the Connections tab.

b.Find the port in the tree view and drag and drop it to the right window pane. The Connection view window appears.

Cisco Transport Manager Release 6.0 User Guide

J-68 78-16845-01