6. Alarms
ROX™ v2.2 User Guide
86
RuggedBackbone™ RX5000
6. Alarms
6.1. Introduction
The ROXII alarm system is a highly configurable notification system of events of interest. Asserted
alarms in the system may be viewed in a table in the CLI, web user interface, as well as queried by
NETCONF. Alarms are categorized by subsystem.
The alarm system allows the user to:
• enable/disable alarms with the exception of mandatory alarms
• configure whether or not an alarm triggers the fail-relay and paints the alarm LED red
• configure the severity of an alarm to one of the following: emergency, alert, critical, error, warning,
notice, info, debug (in descending order of severity). A small minority of alarms have fixed severity.
6.1.1. Alarm Subsystems
As of the current release, there are three subsystems that support alarms; they are Admin, Chassis,
and Switch.
Note that some of the following examples describing the nature of each alarm subsystem may not be
available in this release. A list of the available alarms can be viewed in the configuration file at
/admin/
alarm-cfg
.
Admin Subsystem: these alarms are for administrative aspects of the device, including feature-key
problems, upgrades, and configuration changes.
Chassis Subsystem: these alarms are for physical or electrical problems, or events of interest. This
includes irregular voltages at the power supply or the insertion or removal of a module.
Switch Subsystem: these alarms pertain to layer-2 events of interests such as RSTP topology changes
and link up/down events.
6.1.2. Fail-Relay Behavior
The fail-relay shall be activated when an active alarm in the system is also configured to trigger it. Once
an alarm has been acknowledged or cleared it ceases to assert the fail-relay. The fail-relay will only be
de-activated when all active alarms that are configured to assert it have been acknowledged or cleared.
6.1.3. Alarm LED Behavior
The alarm LED on the control module shall be red when unacknowledged alarm(s) are asserted and
the LED is enabled for any of the active alarms. Once an alarm has been acknowledged or cleared,
the LED is switched off.
6.1.4. Clearing and Acknowledging Alarms
There are two broad types of alarms:
1.
Non-Clearable alarms - Users cannot clear these alarms, only acknowledge them; the difference
between these actions is outlined later in this section. These alarms have a condition associated
with them that the system assesses. The system asserts the alarm when the condition is true and
clears the alarm when the condition has been resolved. An example of this is 'Bad input supply on
power module'. If a redundant power module loses its supply an alarm is asserted. If the problem
is resolved and power is returned to the module, the system de-asserts the alarm. De-asserted
alarms remain as active alarms until acknowledged by the user.
