Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Topology-Independent Loop-Free Alternates (TI-LFA)

The Juniper Cloud-Native Router supports Topology-Independent Loop-Free Alternates (TI-LFA) with fast reroute (FRR) for SR-MPLS implementations.

TI-LFA Overview

Cloud-Native Router supports implementing Topology-Independent Loop-Free Alternates (TI-LFA) with fast reroute (FRR) in SR-MPLS. In the sections below we will look at Cloud-Native Router TI-LFA implementation in detail.

Fast Reroute (FRR)

Fast Reroute (FRR) technology is used in modern routing protocols to minimize disruption and packet loss in the event of a network failure. Unlike traditional routing protocols, FRR speeds up the convergence process by proactively pre-computing backup paths for critical traffic flows. The backup paths are readily available and instantly activated upon failure, ensuring minimum loss of data communication.

Loop-Free Alternates (LFAs) play a critical role in FRR implementations. LFAs are pre-calculated, loop-free backup paths that are leveraged by FRR protocols to quicky switch traffic to the chosen backup path.

There are two key aspects to FRR:

  • Detection:

    • Fault Detection—Rapidly identify link or node failures within a network through continuous monitoring of network elements.

    • Detection Methods—Applying one of the various methods for fault detection, including proactive methods such as periodic link probing or reactive methods that sense failure when it occurs. In some cases Bidirectional Forwarding Detection (BFD) may be used for quick fault detection. Cloud-Native Router detects failure by monitoring the link status events from the Poll Mode Driver (PMD).

  • Handling:

    • Precomputed Backup Paths—Using predetermined and optimised backup paths that are quickly activated when a failure is detected.

    • Fast Switchover—Network devices participating in the FRR process quickly switching to precomputed backup paths to minimize the impact on the network's forwarding capabilities.

The control plane is responsible for preparing the backup paths and detecting when failure occurs. It also re-calculates the best path based on the updated network topology and propagates information about the new path to other routers in the network. This ensures the network converges to the optimal path in the long run. The data plane is responsible for quickly failing over to the backup path in the event of a failure detection. Typically, with LFA implementations, pre-configured forwarding entries or next-hop information for the LFA are already installed on the router. The data plane also adjusts its forwarding tables when it receives a new path from the control plane upon re-calculation. Efficient communication between the control and data planes is critical to minimize lag in traffic reroute, ensuring reduced downtime, improved performance and enhanced reliability.

Topology-Independent Loop-Free Alternates (TI-LFA)

IS-IS and OSPF can calculate LFA backup paths in a plain IP network. However, the LFA feature requires any backup path to be guaranteed loop-free. For this reason, in a plain IP network, LFA cannot offer backup paths to every single known destination. LFA only offers partial topology coverage. TI-LFA is a topology independent implementation of LFA. TI-LFA can push a Segment ID stack that can navigate around any potential loops along the backup path. In other words, backup paths can be calculated independent of the topology. It defines LFAs based on the traffic flow itself and can function effectively regardless of the underlying network layout. TI-LFA uses the pre-computed post-convergence path of the routing protocol. TI-LFA finds the path that would be calculated in the event of a particular link or node failure, and uses that exact path as the backup path. This is not always possible in regular LFA, due to the requirement for a loop-free backup path. By using the post-convergence path, TI-LFA reduces jitter during failover and the network operator only needs to ensure the network has enough capacity to carry the traffic on the post-convergence path after a failure. TI-LFA has multiple advantages:

  • Simplified configuration—TI-LFA automatically computes backup paths, eliminating the need to manually configurate LFAs for each network element.

  • Faster failover—TI-LFA uses the pre-computed post-convergence path of the routing protocol that enables it to activate backup paths significantly faster than traditional LFAs.

  • Improved scalability—TI-LFA scales efficiently in large and complex networks because it is topology independent in contrast to LDP and RSVP which require additional state to create backup paths.

Cloud-Native Router supports TI-LFA for SR-MPLS implementations with link and node failure protection. You can read more about TI-LFA in the Junos documentation.

An IGP identifies the primary and post-convergence (backup for TI-LFA) paths for a prefix based on its criterion. The paths are associated with a weight metric to signify priority (numerically lower the weight, higher the priority). The paths are calculated during the network's initial setup and stored in the routers' forwarding tables.

When link protection is implemented, TI-LFA uses the pre-computed post-convergence path of the routing protocol as the backup path to bypass a protected link. When an upstream node detects a link failure, it immediately initiates the pre-computed backup path to reroute the packet, bypassing the failed failed link.

When node protection is implemented, TI-LFA uses the pre-computed post-convergence path of the routing protocol as the backup path to bypass a protected node's Segment Identifier (SID). When an upstream node detects an intermediate node failure, it immediately initiates the pre-computed backup path to reroute the packet, bypassing the failed node entirely. This process ensures minimal packet loss and maintains network connectivity even in the event of node failures.

When both link-protection and node-protection are implemented, the Cloud-Native Router prefers backup paths that avoid the failed node entirely, rather than just the failed link.

The Cloud-Native Router control plane (cRPD) sends the primary and backup path to the data plane via the vRouter agent. The vRouter data plane implements FRR by identifying the primary path and quickly switching over to backup path if a link failure was detected.

Key points to note about the Cloud-Native Router TI-LFA implementation:

  • TI-LFA is supported for SR-MPLS on IS-IS implementations.

  • TI-LFA is supported for SR-MPLS on OSPF implementations (Tech Preview Feature Only)

  • TI-LFA is supported when Cloud-Native Router is deployed as head-end, transit or egress node in an SR-MPLS domain.

  • Both TI-LFA node and link protection are supported.

  • Multiple primary and single backup path is supported.

  • Both physical and bond interfaces are supported (FRR is triggered for bond interfaces only if all the links in the bond are down).

  • BGP Multipath with underlay ECMP deployments are supported.

  • FRR is triggered based on link status events detected by the Poll Mode Drivers (PMD) followed by Interior Gateway Protocol (IGP) updates.

TI-LFA Configuration (SR-MPLS on IS-IS)

Steps to configure TI-LFA

You must perform configuration on the Cloud-Native Router control plane using a Configlet. Review Customize Cloud-Native Router Configuration for more details.

Consider the following topology that uses IS-IS as IGP and BGP for VPN services.

The configlet configures segment routing for IS-IS protocol. Key points to note:

  • Segment routing configuration defines a node SID and segment routing global block (SRGB) range.
  • Link protection is supported by default.
  • The maximum-backup-paths is set to 1 since Cloud-Native Router supports only one backup path.

  • The interfaces are configured to install backup route along the link-protecting post-convergence path.

  • The interfaces are also configured with node protection (Optional, if node protection is required).

    Verify Configuration

    • To verify the TI-LFA configuration you can access the cRPD shell and verify Cloud-Native Router's support in a topology with multiple primary and backup paths for the destination 10.30.24.11:

    • Use the vRouter CLI to verify the interface list:

    • On the vRouter CLI use the frr --dump command to verify the FRR state before any FRR trigger. vif1 and vif2 are primary interfaces while vif4 is secondary. The nhchain --get command shows the hierarchical next hops.

      In the output above, only the primary next-hop (Id: 61) shows an increasing NH count, indicating that traffic is being forwarded exclusively through the primary path. The NH counts for the other next-hops remain at zero.

    • When primary interface enp10s0 is down, verify the FRR state:

      In the output above, only the primary next-hop (Id: 51) shows an increasing NH count, indicating that traffic is being forwarded exclusively through the primary path. The NH counts for the other next-hops remain at zero. The FRR state for vif1 is cleared since the interface is down.

    • Upon bringing the second primary interface enp7s0 down, verify the FRR state:

      With both primary paths down, only a single next-hop remains in the forwarding list. As a result, no FRR state is maintained. The VPN route now points to the tunnel that previously served as the secondary path.