Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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 Reference Guide.

    Fault Reporting

    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


    Fault-Reporting Behavior


    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 command show conditions retrieves a list of all active faults (both alarms and conditions), and the command show alarms retrieves a list of all active alarms.


    When a fault with critical, major, or minor severity either becomes active or is cleared, no reporting is provided. Polling results retrieved with either show conditions or show alarms do not include any active faults (alarms or conditions) on disabled entities.

    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.

    Figure 1: Alarm Information Retrieved Using the CLI

    Alarm Information Retrieved Using the CLI

    Fault Severity

    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.

    Not alarmed

    A fault that results in a standing condition, not an alarm.

    Not reported

    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 down when a fault is service-affecting.

    Modified: 2017-04-25