Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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.

Detecting 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

Enabling 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.

Note

ACX5096 and ACX5048 routers do not support dying-gasp.

ACX Series routers can generate and receive dying-gasp packets. 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 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:

The dying-gasp functionality is disabled by default.