6. Facility Alarms

This chapter provides information about configuring event and accounting logs in the system.

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 8 shows the relationship of log events, alarms and the LEDs.

Figure 8:  Log Events, Alarms and LEDs 
Note:

Some of the 7210 SAS platforms do not have Critical, Major, and Minor LEDs and Alarm Output pins. On these platforms, an event is raised and only a log is generated.

Facility Alarms have independent functionality from other uses of the term “alarm” in the 7210 SAS software such as:

  1. configure port ethernet report-alarm
  2. configure system thresholds no memory-use-alarm
  3. configure system thresholds rmon no alarm

6.3. Facility Alarm Severities and Alarm LED Behavior

The Alarm LEDs on the CPM/CCM reflects the current status of the Facility Alarms:

  1. The Critical Alarm LED (if available on the 7210 SAS platform), is lit if there is 1 or more active Critical Facility Alarms.
  2. Similarly with the Major and Minor alarm LEDs (if available on the 7210 SAS platform).
  3. The OT Alarm LED (if available on the 7210 SAS platform), is not controlled by the Facility Alarm module.

The supported alarm severities are as follows:

  1. Critical (with an associated LED
  2. Major (with an associated LED
  3. Minor (with an associated LED
  4. Warning (no LED)

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 shutdown the port alarm is cleared (and a card alarm will be active for the). If the card comes back into service, and the port is still down, then a port alarm becomes active again.

The supported Facility Alarm hierarchy is as follows (parent objects that are down cause alarms in all children to be masked):

  1. CPM → Compact Flash
  2. IOM/IMM → MDA → Port → Channel

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 again be visible in the active alarm queue.

6.5. Facility Alarm List

Table 66 and Table 67 list the supported Facility Alarms.

Table 66:  Facility Alarms 

Alarm

Alarm Name/Raising Event

Details String Example

Clearing Event

7210 SAS Devices

7210 SAS-D

7210 SAS-Dxp

7210 SAS-K 2F1C2T

7210 SAS-K 2F6C4T

7210 SAS-K 3SFP+ 8C

7-2001-1

tmnxEqCardFailure

Class MDA Module: failed, reason: MDA 1 failed startup tests

tmnxChassisNotificationClear

N

N

N

7-2003-1

tmnxEqCardRemoved

Class CPM Module: removed

tmnxEqCardInserted

N

N

Y

7-2004-1

tmnxEqWrongCard

Class IOM Module: wrong type inserted

tmnxChassisNotificationClear

N

N

N

7-2005-1

tmnxEnvTempTooHigh

Chassis 1: temperature too high

tmnxChassisNotificationClear

Y

Y

Y

7-2006-1

tmnxEqFanFailure

Fan 1 failed

tmnxChassisNotificationClear

N

N

N

7-2007-1

tmnxEqPowerSupplyFailureOvt

Power supply 2 over temperature

tmnxChassisNotificationClear

N

N

N

7-2008-1

tmnxEqPowerSupplyFailureAc

Power supply 1 AC failure

tmnxChassisNotificationClear

N

N

N

7-2009-1

tmnxEqPowerSupplyFailureDc

Power supply 2 DC failure

tmnxChassisNotificationClear

Y (ETR)

Y (ETR)

N

7-2011-1

tmnxEqPowerSupplyRemoved

Power supply 1, power lost

tmnxEqPowerSupplyInserted

N

N

N

7-2017-1

tmnxEqSyncIfTimingHoldover

Synchronous Timing interface in holdover state

tmnxEqSyncIfTimingHoldoverClear

Y (ETR)

Y (ETR)

Y

7-2019-1

tmnxEqSyncIfTimingRef1Alarm

with attribute tmnxSyncIfTimingNotifyAlarm == 'los(1)'

Synchronous Timing interface, alarm los on reference 1

tmnxEqSyncIfTimingRef1AlarmClear

Y (ETR)

Y (ETR)

Y

7-2019-2

tmnxEqSyncIfTimingRef1Alarm with attribute tmnxSyncIfTimingNotifyAlarm == 'oof(2)'

Synchronous Timing interface, alarm of on reference 1

same as 7-2019-1

Y (ETR)

Y (ETR)

Y

7-2019-3

tmnxEqSyncIfTimingRef1Alarm with attribute tmnxSyncIfTimingNotifyAlarm == 'oopir(3)'

Synchronous Timing interface, alarm oopir on reference 1

same as 7-2019-1

Y (ETR)

Y (ETR)

Y

7-2021-x

same as 7-2019-x but for ref2

same as 7-2019-x but for ref2

same as 7-2019-x but for ref2

Y (ETR)

Y (ETR)

Y

7-2030-x

same as 7-2019-x but for the BITS1 input

same as 7-2019-x but for the BITS1 input

same as 7-2019-x but for the BITS1 input

N

N

N

7-2033-1

tmnxChassisUpgradeInProgress

Class CPM Module: software upgrade in progress

tmnxChassisUpgradeComplete

N

N

N

7-2050-1

tmnxEqPowerSupplyFailureInput

Power supply 1 input failure

tmnxChassisNotificationClear

Y (ETR)

Y (ETR)

N

7-2051-1

tmnxEqPowerSupplyFailureOutput

Power supply 1 output failure

tmnxChassisNotificationClear

N

N

Y (ETR)

7-2073-x

same as 7-2019-x but for the BITS2 input

same as 7-2019-x but for the BITS2 input

same as 7-2019-x but for the BITS2 input

N

N

N

3-2004-1

linkDown

Interface intf-towards-node-B22 is not operational

linkUp

Y

Y

Y

Table 67 lists linkDown Facility Alarm support for the following objects; objects may not be supported on all platforms.

Table 67:  linkDown Facility Alarm Support  

Object

Supported?

Ethernet Ports

Yes

Ethernet LAGs

No

Ethernet VLANs

No