J-68
Cisco Transport Manager Release 6.0 User Guide
78-16845-01
AppendixJ 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.