- play_arrow Overview
- play_arrow Operation, Administration, and Management Features
- play_arrow Ethernet OAM and Connectivity Fault Management for Routers
- Introduction to OAM Connectivity Fault Management (CFM)
- Configure Connectivity Fault Management (CFM)
- CFM Action Profile
- Ethernet Local Management Interface
- CFM Support for CCC Encapsulated Packets
- Configure Unified ISSU for 802.1ag CFM
- CFM Monitoring between CE and PE Devices
- Configure Continuity Check Messages
- Example: Configure Ethernet CFM on Physical Interfaces
- Example: Configure Ethernet CFM on Bridge Connections
- Example: Configure Ethernet CFM over VPLS
- play_arrow Link Fault Management for Routers
- play_arrow Ethernet OAM Link Fault Management for Switches
- play_arrow Ethernet OAM Connectivity Fault Management for Switches
- play_arrow Ethernet Frame Delay
- Ethernet Frame Delay Measurements on Switches
- Configure MEP Interfaces on Switches to Support Ethernet Frame Delay Measurements (CLI Procedure)
- Configure One-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
- Configure an Iterator Profile on a Switch (CLI Procedure)
- Trigger an Ethernet Frame Delay Measurement Session on a Switch
- Configure Two-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
- play_arrow Ethernet Service OAM (ITU-TY.1731) for Routers
- ITU-T Y.1731 Ethernet Service OAM Overview
- Configure Ethernet Frame Delay Measurement Sessions
- Configuring MEP Interfaces to Support Ethernet Frame Delay Measurements
- Configure Ethernet Frame Loss Measurement
- Configure an Iterator Profile
- Configure Ethernet Synthetic Loss Measurements
- Ethernet Alarm Indication
- Inline Transmission Mode
-
- play_arrow Network Monitoring by using SNMP
- SNMP Architecture and SNMP MIBs Overview
- Understand SNMP Implementation in Junos OS
- Configure SNMP in Junos OS
- Configure Options on Managed Devices for Better SNMP Response Time
- Enterprise Specific Utility MIB to Enhance SNMP Coverage
- Optimize the Network Management System Configuration for the Best Results
- Interfaces to Accept SNMP Requests
- Configure SNMP for Routing Instances
- Configure SNMP Remote Operations
- SNMP Traps
- SNMP Traps Supported by Junos OS
- Trace SNMP Activity
- Access Privileges for an SNMP Group
- Configure Local Engine ID on SNMPv3
- Configure SNMPv3
- Configure SNMPv3 Authentication Type and Encryption Type
- SNMPv3 Traps
- SNMPv3 Informs
- SNMP Communities
- MIB Views
- SNMP MIBs Supported by Junos OS and Junos OS Evolved
- Junos OS SNMP FAQs
- play_arrow Remote Network Monitoring (RMON) with SNMP Alarms and Events
- play_arrow Accounting Options
- play_arrow Monitoring Common Security Features
- play_arrow Performance Management
- play_arrow Port Mirroring
- play_arrow Port Mirroring and Analyzers
- Port Mirroring and Analyzers
- Configuring Port Mirroring and Analyzers
- Configuring Port Mirroring Instances
- Configuring Port Mirroring on Physical Interfaces
- Configuring Port Mirroring on Logical Interfaces
- Configuring Port Mirroring for Multiple Destinations
- Configuring Port Mirroring for Remote Destinations
- Configuring Port Mirroring Local and Remote Analysis
- 1:N Port Mirroring to Multiple Destinations on Switches
- Example: Configure Port Mirroring with Family any and a Firewall Filter
- Monitoring Port Mirroring
- Configure Packet Mirroring with Layer 2 Headers for Layer 3 Forwarded Traffic
- Troubleshooting Port Mirroring
-
- play_arrow System Log Messages
- play_arrow Network Management and Troubleshooting
- Compressing Troubleshooting Logs from /var/logs to Send to Juniper Networks Technical Support
- Monitoring and Troubleshooting
- Troubleshooting System Performance with Resource Monitoring Methodology
- Configuring Data Path Debugging and Trace Options
- Using MPLS to Diagnose LSPs, VPNs, and Layer 2 Circuits
- Using Packet Capture to Analyze Network Traffic
- On-Box Packet Sniffer Overview
- Troubleshooting Security Devices
- play_arrow Configuration Statements and Operational Commands
Alarm Overview
This section describes interface alarms and how to configure them.
Alarms alert you to conditions on a network interface, on the device chassis, or in the system software that might prevent the device from operating normally. You can set the conditions that trigger alarms on an interface. Chassis and system alarm conditions are preset.
An active alarm lights the ALARM LED on the front panel of the device. You can monitor active alarms from the J-Web user interface or the CLI. When an alarm condition triggers an alarm, the device lights the yellow (amber) ALARM LED on the front panel. When the condition is corrected, the light turns off.
Alarm Types
The device supports three types of alarms:
Interface alarms indicate a problem in the state of the physical links on fixed or installed Physical Interface Modules (PIMs). To enable interface alarms, you must configure them.
Chassis alarms indicate a failure on the device or one of its components. Chassis alarms are preset and cannot be modified.
System alarms indicate a missing rescue configuration or software license, where valid. System alarms are preset and cannot be modified, although you can configure them to appear automatically in the J-Web user interface or CLI.
Starting with Junos OS Release 15.1X49-D60 and Junos OS Release 17.3R1, a new system alarm is introduced to indicate that the PICs (I/O card or SPC) have failed to come online during system start time.
Starting in Junos OS Releases 12.3X48-D85, 15.1X49-D180, and 19.2R1,
a system alarm is triggered when the Network Security Process (NSD)
is unable to restart due to the failure of one or more NSD subcomponents.
The alarm logs about the NSD are saved in the messages log. The alarm
is automatically cleared when NSD restarts successfully. The show chassis alarms
and show system alarms
commands
are updated to display the following output when NSD is unable to
restart - NSD fails to restart because subcomponents
fail
.
Run the following commands when the CLI prompt indicates that an alarm has been raised:
show system alarms
show chassis alarms
show chassis fpc pic-status
For more information about the CLI commands, see show system alarms, show chassis alarms, and show chassis fpc.
Alarm Severity
Alarms have two severity levels:
Major (red)—Indicates a critical situation on the device that has resulted from one of the following conditions. A red alarm condition requires immediate action.
One or more hardware components have failed.
One or more hardware components have exceeded temperature thresholds.
An alarm condition configured on an interface has triggered a critical warning.
Minor (yellow)—Indicates a noncritical condition on the device that, if left unchecked, might cause an interruption in service or degradation in performance. A yellow alarm condition requires monitoring or maintenance.
A missing rescue configuration or software license generates a yellow system alarm.
Alarm Conditions
To enable alarms on a device interface, you must select an alarm condition and an alarm severity. In contrast, alarm conditions and severity are preconfigured for chassis alarms and system alarms.
For information about chassis alarms for your device, see the Hardware Guide for your device.
This section contains the following topics:
Interface Alarm Conditions
Table 1 lists the interface conditions, sorted by interface type, that you can configure for an alarm. You can configure each alarm condition to trigger either a major (red) alarm or minor a (yellow) alarm. The corresponding configuration option is included.
For the services stateful firewall filters (NAT, IDP, and IPsec), which operate on an internal adaptive services module within a device, you can configure alarm conditions on the integrated services and services interfaces.
Interface | Alarm Condition | Description | Configuration Option |
---|---|---|---|
DS1 (T1) | Alarm indication signal (AIS) | The normal T1 traffic signal contained a defect condition and has been replaced by the AIS. A transmission interruption occurred at the remote endpoint or upstream of the remote endpoint. This all-ones signal is transmitted to prevent consequential downstream failures or alarms. | ais |
Yellow alarm | The remote endpoint is in yellow alarm failure. This condition is also known as a far-end alarm failure. | ylw | |
Ethernet | Link is down | The physical link is unavailable. | link-down |
Integrated services | Hardware or software failure | On the adaptive services module, either the hardware associated with the module or the software that drives the module has failed. | failure |
Serial | Clear-to-send (CTS) signal absent | The remote endpoint of the serial link is not transmitting a CTS signal. The CTS signal must be present before data can be transmitted across a serial link. | cts-absent |
Data carrier detect (DCD) signal absent | The remote endpoint of the serial link is not transmitting a DCD signal. Because the DCD signal transmits the state of the device, no signal probably indicates that the remote endpoint of the serial link is unavailable. | dcd-absent | |
Data set ready (DSR) signal absent | The remote endpoint of the serial link is not transmitting a DSR signal. The DSR signal indicates that the remote endpoint is ready to receive and transmit data across the serial link. | dsr-absent | |
Loss of receive clock | The clock signal from the remote endpoint is not present. Serial connections require clock signals to be transmitted from one endpoint and received by the other endpoint of the link. | loss-of-rx-clock | |
Loss of transmit clock | The local clock signal is not present. Serial connections require clock signals to be transmitted from one endpoint and received by the other endpoint of the link. | loss-of-tx-clock | |
Services | Services module hardware down | A hardware problem has occurred on the device's services module. This error typically means that one or more of the CPUs on the module has failed. | hw-down |
Services link down | The link between the device and its services module is unavailable. | linkdown | |
Services module held in reset | The device's services module is stuck in reset mode. If the services module fails to start up five or more times in a row, the services module is held in reset mode. Startup fails when the amount of time from CPU release to CPU halt is less than 300 seconds. | pic-hold-reset | |
Services module reset | The device's services module is resetting. The module resets after it crashes or is reset from the CLI, or when it takes longer than 60 seconds to start up. | pic-reset | |
Services module software down | A software problem has occurred on the device's services module. | sw-down | |
E3 | Alarm indication signal (AIS) | The normal E3 traffic signal contained a defect condition and has been replaced by the AIS. A transmission interruption occurred at the remote endpoint or upstream of the remote endpoint. This all-ones signal is transmitted to prevent consequential downstream failures or alarms. | ais |
Loss of signal (LOS) | No remote E3 signal is being received at the E3 interface. | los | |
Out of frame (OOF) | An OOF condition has existed for 10 seconds. This alarm applies only to E3 interfaces configured in frame mode. The OOF failure is cleared when no OOF or LOS defects have occurred for 20 seconds. | oof | |
Remote defect indication | An AIS, LOS, or OOF condition exists. This alarm applies only to E3 interfaces configured in frame mode. | rdi | |
T3 (DS3) | Alarm indication signal | The normal T3 traffic signal contained a defect condition and has been replaced by the AIS. A transmission interruption occurred at the remote endpoint or upstream of the remote endpoint. This all-ones signal is transmitted to prevent consequential downstream failures or alarms. | ais |
Excessive number of zeros | The bit stream received from the upstream host has more consecutive zeros than are allowed in a T3 frame. | exz | |
Far-end receive failure (FERF) | The remote endpoint of the connection has failed. A FERF differs from a yellow alarm, because the failure can be any failure, not just an OOF or LOS failure. | ferf | |
Idle alarm | The Idle signal is being received from the remote endpoint. | idle | |
Line code violation | Either the line encoding along the T3 link is corrupted or a mismatch between the encoding at the local and remote endpoints of a T3 connection occurred. | lcv | |
Loss of frame (LOF) | An OOF or loss-of-signal LOS condition has existed for 10 seconds. The LOF failure is cleared when no OOF or LOS defects have occurred for 20 seconds. A LOF failure is also called a red failure. | lof | |
Loss of signal (LOS) | No remote T3 signal is being received at the T3 interface. | los | |
Phase-locked loop out of lock | The clocking signals for the local and remote endpoints no longer operate in lock-step. | pll | |
Yellow alarm | The remote endpoint is in yellow alarm failure. This condition is also known as a far-end alarm failure. | ylw |
System Alarm Conditions
Table 2 lists the two preset system alarms, the condition that triggers each alarm, and the action you take to correct the condition.
Alarm Type | Alarm Condition | Corrective Action |
---|---|---|
Configuration | The rescue configuration is not set. | Set the rescue configuration. |
License | You have configured at least one software feature that requires a feature license, but no valid license for the feature is currently installed. Note: This alarm indicates that you are in violation of the software license agreement. You must install a valid license key to be in compliance with all agreements. | Install a valid license key. |
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
show chassis alarms
and show system alarms
commands
are updated to display the following output when NSD is unable to
restart - NSD fails to restart because subcomponents
fail
.