Configuring Fault Monitoring and Reporting
Fault monitoring is enabled by default for all managed entities and is conducted at the physical layer, covering optical signals and channel-specific transceiver faults, and at the protocol layer with specific fault points defined for all supported protocols. Monitoring is also conducted on supporting BTI7800 equipment, including the various sensors located throughout the chassis and on the modules.
You can enable or disable the reporting of a fault. When reporting is enabled and fault masking does not occur, the fault is reported as either an alarm (alarmed) or a condition (not alarmed). An alarm generates a notification as the fault becomes active. A condition does not generate a notification and is typically used to report lower-severity faults.
You can also configure whether a fault is an alarm or a
condition and change its default severity. For more information, see
the description of the
conditions CLI command in the BTI7800 Command Line
When reporting is enabled for a fault that becomes active on a managed entity, the reporting behavior of that fault depends on the administrative status (enabled or disabled) of the entity, as described in the following table.
Table 1: Entity Administrative Status and Fault Reporting
When a fault with critical, major, or minor severity (see Table 2) becomes active, it is reported with an alarm notification. When the fault is no longer active, a condition-clear alarm is generated.
Polling retrieves active faults on enabled entities. The CLI
When a fault with critical, major, or minor severity either
becomes active or is cleared, no reporting is provided. Polling results
retrieved with either
To retrieve alarms and conditions, use the
show alarms and
show conditions CLI commands, respectively. For both alarms and conditions,
the information retrieved shows the name of the entity affected, the
fault code, the time the fault was reported, the fault severity, the
impact on service, and the name of the fault in plain language.
Each fault is associated with one of the default severity types listed in the following table.
Table 2: Fault Severities
A failure that is likely causing serious loss or interruption of traffic.
A failure that could potentially lead to loss or interruption of traffic.
A failure that does not significantly affect traffic.
A fault that results in a standing condition, not an alarm.
A non-alarmed fault that is discovered only when standing conditions are polled.
Notifications for raise and clear events are never generated for faults with Not Reported (NR) severity, and active occurrences can be discovered only when the active conditions list is polled.
Fault Impact on Service
In addition to fault severity, reporting indicates whether a
fault impacts service (service-affecting true) or not (service-affecting
false). Depending on the entity type, the operational status of the
entity is reported as
when a fault is service-affecting.