For feedback, use the following:
ipd_online_feedback@alcatel-lucent.com
Table of Contents Previous Next Index PDF


Facility Alarms
In This Chapter
This chapter provides information about configuring event and accounting logs in the system.
Topics in this chapter include:
Facility Alarms Overview
Facility Alarms provide a useful tool for operators to easily track and display the basic status of their equipment facilities.
CLI display (show routines) allows the system operator to easily identify current facility alarm conditions and recently cleared alarms without searching event logs or monitoring various card and port show commands to determine the health of managed objects in the system such as cards and ports.
The SR-OS alarm model is based on RFC 3877, Alarm Management Information Base (MIB), (which evolved from the IETF DISMAN drafts).
Facility Alarms vs. Log Events
Facility Alarms are different than (log) events. Events are a single point in time and are generally stateless. Facility Alarms have a state (at least two states: active and clear) and duration and can be modelled with state transition events (raised, cleared).
The Facility Alarms module processes log events in order to generate the raised and cleared state for the alarms. If a raising log event is suppressed under event-control, then the associated Alarm will not be raised. If a clearing log event is suppressed under event-control, then it is still processed for the purpose of clearing the associated alarm. Log event filtering, throttling and discarding of events during overload do not affect Facility Alarm processing. Log events are processed by the Facility Alarm module before they are discarded in all cases.
Figure 8 illustrates the relationship of log events, alarms and the LEDs.
Figure 8: Log Events, Alarms and LEDs
Facility Alarms are different and independent functionality from other uses of the term alarm in SR-OS such as:
Log events that use the term alarm (tmnxEqPortSonetAlarm)
Facility Alarm Severities and Alarm LED Behavior
The Alarm LEDs on the CPM/CCM reflects the current status of the Facility Alarms:
The supported alarm severities are as follows:
Alarms inherit their severity from the raising event.
Log events that are a raising event for a facility alarm configured with a severity of indeterminate or cleared will result in those alarms not being raised (but clearing events are processed in order to clear alarms regardless of the severity of the clearing event).
Changing the severity of a raising event only affects subsequent occurrences of that event and alarms. Alarms that are already raised when their raising event severity is changed maintain their original severity.
Facility Alarm Hierarchy
Facility Alarms for children objects is not raised for failure of a parent object. For example, when an MDA fails (or is shutdown) there is not a set of port alarms raised.
When a parent alarm is cleared, children alarms that are still in occurrence on the node appears in the active alarms list. For example, when a port fails there is a port alarm, but if the MDA is later shutdown the port alarm is cleared (and a card alarm will be active for the MDA). If the MDA comes back into service, and the port is still down, then a port alarm becomes active once again.
The supported Facility Alarm hierarchy is as follows (parent objects that are down cause alarms in all children to be masked):
Note that a masked alarm is not the same as a cleared alarm. The cleared alarm queue does not display entries for previously raised alarms that are currently masked. If the masking event goes away, then the previously raised alarms will once again be visible in the active alarm queue.
Facility Alarm List
The following table(s) show the supported Facility Alarms.
 
The linkDown Facility Alarm is supported for the following objects (note that all objects may not be supported on all platforms):