Routing Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Release

PDF

Fast reroute with local loop-free alternate

Updated: June 30, 2026

Want to summarize with AI?

Explains how loop-free alternate fast reroute protects traffic by calculating backup paths and redirecting packets quickly around failed links or nodes through remote alternates.

Fast reroute loop-free alternate is a network recovery feature that

calculates backup paths to protect against link or node failures
enables rapid traffic redirection to a remote loop-free alternate, and
supports multi-hop protection while integrating with routing protocols during topology changes.

Prerequisites for IPv4/IPv6 loop-free alternate fast reroute

Loop-Free Alternate (LFA) Fast Reroute (FRR) can protect paths that are reachable through an interface only if the interface is a point-to-point interface.

Restrictions for loop-free alternate fast reroute

Configure the remote LFA backup path for MPLS traffic by using only LDP.

Restrict LFA calculations to interfaces or links in the same level or area.

Excluding all neighbors on the same LAN during backup LFA computation can make repair paths unavailable in some topologies.

Protect only physical interfaces. Subinterfaces, tunnels, and virtual interfaces are not supported.

IPv4 and IPv6 LFA FRR over TE tunnels are not supported.

Loop-free alternate as a backup path

A loop-free alternate (LFA) provides a backup path that redirects traffic after a network failure. It sends traffic to a node other than the primary neighbor so that forwarding can continue during the transition.

An LFA makes the forwarding decision without knowing the exact point of failure. The backup path must not use the failed element, route traffic through the protecting node in a way that creates dependency on the failure, or create a forwarding loop. By default, LFA is enabled on all supported interfaces that can serve as a primary path.

Per-prefix LFAs provide these advantages:

The repair path forwards traffic while the primary link is down.
All destinations that have a per-prefix LFA remain protected. Only some destinations beyond the failure can remain unprotected.

How repair paths and LFA calculation maintain traffic flow

Repair paths and loop-free alternate (LFA) calculation help maintain traffic flow during routing transitions. They reduce packet loss by precomputing alternate paths that can be used after a link or router failure.

Repair paths forward traffic while the network converges. When a link or router fails because of a physical-layer signal loss, only the adjacent routers detect the failure immediately. Other routers remain unaware until the routing protocol propagates the update, which can take several hundred milliseconds. During this interval, traffic must be redirected along an alternate path.

Summary

This process uses these components:

Adjacent router: Uses repair paths for packets that would otherwise traverse the failed link until routing convergence is complete.
Repair paths: Are precomputed so that the router can activate them as soon as it detects a failure.

Workflow

These stages describe the implementation of repair paths and LFA calculation.

The LFA FRR feature uses specific repair paths to maintain connectivity:
- Equal-cost multipath (ECMP): Uses another member of an equal-cost path set as an alternate path when one link fails.
- Loop-free alternate (LFA): Acts a next hop that can reach the destination without sending the packet into a loop. Downstream paths are a subset of LFAs.
IS-IS calculates LFAs based on RFC 5286, with modifications that optimize memory usage.
- IS-IS performs shortest path first (SPF) calculation for each neighbor.
- IS-IS evaluates prefixes for each result.
- IS-IS retains only the best repair path, so it does not need to store SPF results for all neighbors.

Result

After routing convergence completes, all routers update their forwarding information, and the failed link is removed from the routing computation.

How tiebreaking selects repair paths for candidate LFAs

A routing protocol computes repair paths for prefixes by applying tiebreaking rules. The result is a set of prefixes with primary paths, where some primary paths also have repair paths.

Summary

A routing protocol computes repair paths for prefixes by applying tiebreaking rules to candidate LFAs. This process removes extra candidates and selects one LFA for each primary path and prefix.

Workflow

These stages describe the tiebreaking process for candidate LFAs.

Identify candidate LFAs. The routing protocol starts with a set of candidate LFAs for prefixes that have primary paths. Some of these primary paths can also have repair paths.
The routing protocol evaluates candidate LFAs against specific attributes to narrow down the selection. The routing protocol applies default tiebreaking rules to narrow the set of candidate LFAs. You can modify these rules if needed.
- Downstream: Eliminates candidates whose metric to the protected destination is lower than the protecting node's metric to that destination.
- Linecard-disjoint: Eliminates candidates that share the same line card as the protected path.
- Shared Risk Link Group (SRLG): Eliminates candidates that belong to the same SRLG as the protected path.
- Load-sharing: Distributes the remaining candidates among prefixes that share the protected path.
- Lowest-repair-path-metric: Eliminates candidates whose metric to the protected prefix is higher.
- Node protecting: Eliminates candidates that do not provide node protection.
- Primary-path: Eliminates candidates that are not equal-cost multipath (ECMP) paths.
- Secondary-path: Eliminates candidates that are ECMP paths.
Skip any rule that removes all candidates. If a tiebreaking rule would eliminate all candidate LFAs, the routing protocol skips that rule. At least one candidate LFA remains available for selection.
Select the repair path. After evaluating the candidate LFAs, the routing protocol selects one LFA for each primary path and prefix. The routing protocol assigns one repair path to each eligible primary path and prefix to help distribute traffic if the primary path fails.

Result

The routing protocol selects a single repair path for each eligible primary path and prefix, which helps maintain traffic flow after a primary path failure.

IS-IS support for IP fast reroute

IP fast reroute (FRR) is a network resiliency feature that

lets IS-IS compute loop-free alternate (LFA) next-hop routes for use when the primary path fails
computes LFA next-hop routes for each prefix
appliess tiebreaking rules to select one LFA when multiple candidates exist, and
distributes prefixes evenly across available LFA paths.

IS-IS failure recovery process

When a local link fails, IS-IS performs this recovery process:

Recomputes the primary next-hop routes for all affected prefixes.
Updates the routing information base (RIB) and forwarding information base (FIB) with the new routes.

Warning

Without IP FRR, traffic to affected prefixes is dropped until the forwarding plane is updated. This update can take several hundred milliseconds.

Configure FRR with local LFA using IS-IS

Use this task to configure the IS-IS routing process for IPv4 unicast and enable per-prefix fast reroute on an interface.

This example uses IS-IS process ring, Loopback0, and HundredGigE 0/2/0/0. Replace these sample values with values from your environment.

This example shows an IPv4 LFA FRR configuration. IPv6 LFA FRR is also supported.

Procedure

Enter IS-IS router configuration mode and configure the IS-IS process attributes.

Example:

Router# configure
Router(config)# router isis ring
Router(config-isis)# is-type level-1
Router(config-isis)# net 49.0001.0000.0000.0007.00
Router(config-isis)# nsf cisco
Router(config-isis)# address-family ipv4 unicast
Router(config-isis-af)# metric-style wide

Configure Loopback0 for IPv4 unicast under the IS-IS process.

Example:

Router(config-isis-af)# exit
Router(config-isis)# interface Loopback0
Router(config-isis-if)# point-to-point
Router(config-isis-if)# address-family ipv4 unicast

Configure the physical interface and enable per-prefix fast reroute.

Example:

Router(config-isis-if)# exit
Router(config-isis)# interface HundredGigE 0/2/0/0
Router(config-isis-if)# point-to-point
Router(config-isis-if)# address-family ipv4 unicast
Router(config-isis-if-af)# fast-reroute per-prefix
Router(config-isis-if-af)# commit

The router is configured for IS-IS IPv4 unicast, and per-prefix fast reroute is enabled on the interface.

IS-IS fast reroute is configured on the router and enabled on the specified interface.

Configure OSPF per-prefix local LFA fast reroute

Use this task to configure OSPF and enable per-prefix local LFA fast reroute on an interface.

This example uses OSPF process 50, router ID 10.1.1.1, area 0, Loopback0, and HundredGigE 0/2/0/0. Replace these sample values with values from your environment.

This example shows an IPv4 LFA FRR configuration. IPv6 LFA FRR is also supported.

Procedure

Enter OSPF router configuration mode and configure the OSPF process for IPv4 unicast.

Example:

Router# configure
Router(config)# router ospf 50
Router(config-ospf)# router-id 10.1.1.1
Router(config-ospf)# address-family ipv4 unicast
Router(config-ospf-af)# area 0

Add Loopback0 to OSPF area 0.

Example:

Router(config-ospf-af-area)# interface Loopback0

Add HundredGigE 0/2/0/0 to OSPF area 0 and enable per-prefix local LFA fast reroute.

Example:

Router(config-ospf-af-area)# interface HundredGigE 0/2/0/0
Router(config-ospf-af-area-if)# fast-reroute per-prefix
Router(config-ospf-af-area-if)# commit

OSPF is configured for IPv4 unicast, and per-prefix local LFA fast reroute is enabled on the interface.

The router is configured for local LFA fast reroute with OSPF on the specified interface.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.