Interfaces and Hardware Component Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

PDF

Interfaces and Hardware Component Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

Link Loss Forwarding

Updated: July 31, 2026

Want to summarize with AI?

Log in

This topic describes Link Loss Forwarding (LLF), a mechanism used in networking to propagate the status of a network link to other connected devices.

Link Loss Forwarding (LLF) is a networking mechanism that

  • propagates the status of a network link to other connected devices

  • ensures that link failure information is forwarded to other network devices, and

  • takes appropriate actions to maintain network stability and performance.

LLF uses Connectivity Fault Management (CFM) to transmit notification of a signal loss or fault across the network. When there is a fault on a link to a device on one side of the network, the connection to the port on the other side needs to be shutdown so that the device re-routes the traffic.

You can enable LLF on a network by one of these methods:

  • Link State Monitor and Propagation by CFM: LLF uses Connectivity Fault Management (CFM) to transmit notification of a signal loss or fault across the network. When there is a fault on a link to a device on one side of the network, the connection to the port on the other side needs to be shutdown so that the device re-routes the traffic.

  • Remote Link State Propagation: LLF uses this method for Layer 2 transport events to propagate link failures to remote endpoints. When a link failure occurs, LLF ensures that the failure is communicated to other devices in the network. This enables the other devices to take appropriate action, such as rerouting traffic or triggering failover mechanisms.

Supported interface and MEP types for LLF

Configure Link Loss Forwarding only on the interface and MEP types that support it.

  • Link loss forwarding is not permitted on subinterfaces.

  • Link loss forwarding is permitted only on UP MEPs. The UP MEPs send the frames into the bridge relay function and not through the wire connected to the port where the MEP is configured. For more information on UP MEPs, see Maintenance End Points and Connectivity Fault Management processes.

  • Link loss forwarding does not work on bundle interfaces configured with LACP.

Damping timer behavior for interface state transitions

A damping or restore timer governs transitions of an interface from TX-disabled state to TX-enabled state.

  • By default, the period of the damping timer is three times the configured CCM interval. You cannot configure the damping timer.

  • The damping timer is not provided for transitions of an interface from TX-enabled state to TX-disabled state.

Link State Monitoring is a network management mechanism that

  • tracks the status of network links to ensure they are operational and performing as expected

  • propagates link state changes throughout the network so other devices can adjust routing and operations accordingly, and

  • manages interface transitions such as TX-disable to maintain network stability.

When there is a fault on a link to a device on one side of the network, the connection to the port on the other side needs to be shutdown so that the device re-routes the traffic. This requires the interface to be TX-disabled.

Link Loss Forwarding (LLF) uses Connectivity Fault Management (CFM) to transmit notification of a signal loss or fault across the network. If a local attachment circuit (AC) on a bridged interface fails, one of the following signals or packet types are sent to the neighboring device:

  • Continuity Check Message (CCM) – The CCMs are heartbeat messages exchanged periodically between all the Maintenance End Points (MEPs) in a service. MEPs are members of a particular service within a domain and are responsible for sourcing and sinking CFM frames. Each MEP sends out multicast CCMs, and receives CCMs from all the other MEPs in the service. This allows each MEP to discover its peer MEPs, and to verify that there is connectivity between them.

  • Alarm Indication Signal (AIS) – These are messages sent periodically by MEPs that have detected a fault, to the MEPs in the next highest maintenance domain level.

  • Client Signal Fail (CSF) – A mechanism for error detection. When a MEP detects an issue, the MEP sends CSF packets to its peer MEPs. For more information on MEPs, see Maintenance points.

How interface state transition works

The Connectivity Fault Management Daemon (CFMD) and Ether-MA are processes that run on the router's control plane, coordinating interface state transitions based on fault notifications. Ether-MA manages owner channel communication and resynchronization from CFMD, L2VPN, and other Ether-MA processes. It handles TX-disable and TX-enable events triggered by CFMD notifications.

Summary

These actors and components participate in the process:

  • Connectivity Fault Management Daemon (CFMD): Receives Continuity Check Message (CCM), Alarm Indication Signal (AIS), or Client Signal Fail (CSF) fault indications and notifies Ether-MA.

  • Ether-MA: Handles TX-disable and TX-enable events on the interface based on notifications from CFMD.

  • Restore or damping timer: Runs for 3.5 times the packet interval duration and determines when the interface returns to the TX-enable state.

  • Interface: Transitions to the TX-disable state on a fault and back to the TX-enable state when the restore timer expires without additional faults.

Workflow

This coordinated process ensures rapid response to link faults and controlled restoration of interface operation to maintain network stability and performance.

These stages describe how the router handles a fault notification and transitions the interface between the TX-disable and TX-enable states:

  1. Stage 1 — CFMD receives a fault indication. When the system receives a Continuity Check Message (CCM) or Alarm Indication Signal (AIS) with a fault indication, or a Client Signal Fail (CSF) error packet, CFMD communicates with Ether-MA to transition the interface to the TX-disable state.
  2. Stage 2 — The interface transitions to TX-disable. Upon receiving a fault notification, the interface is immediately transitioned to the TX-disable state.
  3. Stage 3 — The restore or damping timer starts. A restore or damping timer with a 3.5 * packet interval duration is started.
  4. Stage 4 — The interface transitions back to TX-enable. If no additional fault packets are received before the restore timer expires, the TX-disable state is cleared, and the interface transitions back to the TX-enable state.

Remote link state propagation is a LLF feature that

  • allows the status of a link to be communicated to remote devices

  • ensures that all relevant parts of the network are aware of link state changes, and

  • maintains accurate link status information crucial for network performance and reliability, which is particularly useful in Layer 2 transport networks.

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

Remote link state propagation

 Release 26.1.1

Introduced in this release on: Centralized Systems (8400 [ASIC: K100]) (select variants only*)

*This feature is supported on Cisco 8404-SYS-D router.

Remote link state propagation

Release 25.4.1

Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100]) (select variants only*)

*This feature is supported on:

  • 8711-48Z-M

  • 8011-32Y8L2H2FH

  • 8011-12G12X4Y-A/D

Remote link state propagation

 Release 25.1.1

Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])

This feature is now supported on:

  • 8712-MOD-M

  • 8011-4G24Y4H-I

Remote Link State Propagation

Release 24.4.1

Introduced in this release on: Fixed Systems (8200, 8700); Modular Systems (8800 [LC ASIC: P100]) (select variants only*)

*This feature is now supported on:

  • 8212-32FH-M

  • 8711-32FH-M

  • 88-LC1-12TH24FH-E

Remote link state propagation

Release 24.3.1

Introduced in this release on: Fixed Systems (8200 [ASIC: Q200, P100], 8700 [ASIC: P100]); Centralized Systems (8600 [ASIC:Q200]); Modular Systems (8800 [LC ASIC: Q100, Q200, P100])

Remote Link State Propagation allows the status of a link to be communicated to remote devices, ensuring that all relevant parts of the network are aware of link state changes. Link Loss Forwarding (LLF) uses this feature to propagate link failures to remote endpoints.

By enabling remote state propagation and LLF on an interface, you can ensure that the link state changes are communicated to remote devices, allowing for quick failover and rerouting of traffic.

This feature introduces the propagate remote-status command.

Link Loss Forwarding for Layer 2 Transport

Link Loss Forwarding (LLF) uses Remote Link State Propagation to propagate link failures to remote endpoints. When a link failure occurs, LLF ensures that the failure is communicated to other devices in the network, allowing them to take appropriate action, such as rerouting traffic or triggering failover mechanisms. LLF helps avoid packet loss and triggers network convergence through alternate links. It works by sending signals across the pseudowire (PW) to the neighboring device, bringing the PW and far-end attachment circuit (AC) down if the local AC goes down.

You can configure LLF for the Layer 2 transport events, using the propagate remote-status command. You can enable LLF on the following interface types: 1G, 10G, 25G, 40G, 100G, and 400G.

Remote State Propagation with LLF for L2 Transport

When you configure LLF for L2 transport events, the following are the processes that happen:

  1. Link State Detection: The network device detects a change in the link state, such as a link going down.

  2. Remote State Propagation: When remote state propagation is enabled, the detected link state change is propagated to remote devices. This ensures that all relevant devices are aware of the link failure and can take appropriate action.

  3. LLF Activation: LLF uses the propagated link state information to trigger failover mechanisms or reroute traffic. This helps maintain network performance and reliability by quickly responding to link failures.

When you enable remote state propagation and LLF on an interface, the link state changes are communicated to remote devices allowing for quick failover and rerouting of traffic.