- play_arrow Overview
- 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 Options
- play_arrow Interface Alarms
- play_arrow IP Monitoring
- play_arrow sFlow Monitoring Technology
- play_arrow Adaptive Sampling for Routers and Switches
- play_arrow Packet Flow Accelerator Diagnostics Software
-
- 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
Remote Fault Detection for Link Fault Management
Use this topic to understand more about remote faults and how they are detected and also how to enable the dying gasp feature to avoid file system corruption for LFM.
Detect Remote Faults
Fault detection is either based on flags or fault event type, length, and values (TLVs) received in OAM protocol data units (PDUs). Flags that trigger a link fault are:
Critical Event
Dying Gasp
Link Fault
The link event TLVs are sent by the remote DTE by means of event notification PDUs. Link event TLVs are:
Errored Symbol Period Event
Errored Frame Event
Errored Frame Period Event
Errored Frame Seconds Summary Event
See Also
Enable Dying Gasp Functionality
Dying gasp means an unrecoverable condition such as a power failure. In this condition, the local peer informs the remote peer about the failure state. When the remote peer receives a dying-gasp PDU, it takes an action corresponding to the action profile configured with the link-adjacency-loss event. Dying gasp helps to avoid file system corruption.
ACX5096 and ACX5048 routers do not support dying-gasp.
When LFM is configured on an interface, a dying-gasp PDU is generated for the interface on the following failure conditions:
Power failure
Packet Forwarding Engine panic or a crash
ACX Series routers support the receipt of dying-gasp packets, but cannot generate them.
ACX Series routers support the following CLI statements to enable dying-gasp functionality:
dgasp-int—Enables dying-gasp functionality.dgasp-usb—Resets USB port during dying-gasp event.
The dgasp-int and dgasp-usb CLI statements
are added under the [edit system] hierarchy to enable dying-gasp
functionality.
To enable dying-gasp functionality, you need to configure the dgasp-int and dgasp-usb CLI statements as shown
below:
root@host% cli root@host> configure Entering configuration mode [edit] root@host# set system dgasp-int [edit] root@host# set system dgasp-usb [edit] root@host# commit commit complete [edit] root@host# show system dgasp-int; dgasp-usb;
The dying-gasp functionality is disabled by default.
