6.1. 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 7210 SAS alarm model is based on RFC 3877, Alarm Management Information Base (MIB), (which evolved from the IETF DISMAN drafts).

6.2. Facility Alarms vs. Log Events

Facility Alarms are different from 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 modeled with state transition events (raised, cleared).

The Facility Alarms module processes log events 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 9 shows the relationship of log events, alarms and the LEDs.

Figure 9:  Log Events, Alarms and LEDs 

Note: On platforms that do not support Critical, Major, and Minor LED and Alarm output pins, an event is raised and only a log is generated.

Facility Alarms are different and have independent functionality from other uses of the term alarm such as:

6.3. 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 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.

6.4. Facility Alarm Hierarchy

Facility Alarms for children objects is not raised for failure of a parent object. For example, when port fails (or is shut down) 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 port is later shut down the port alarm is cleared (and a card alarm will be active). If the card 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):

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.

6.5. Facility Alarm List

Table 64 and Table 65 list the supported Facility Alarms.

The linkDown Facility Alarm is supported for the following objects: