Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Example: Configuring Topology Independent Loop-Free Alternate with Segment Routing for IS-IS

This example shows topology-independent loop-free alternate (TI-LFA) with segment routing for the IS-IS protocol to provide MPLS fast reroute (FRR) backup paths corresponding to the post-convergence path for a given failure by using deeper label stacks to construct backup paths. TI-LFA provides protection against link failure, node failure, and fate-sharing failures. In link failure mode, the destination is protected if the link fails. In node protection mode, the destination is protected if the neighbor connected to the primary link fails. To determine the node-protecting post-convergence path, the cost of all the links leaving the neighbor is assumed to increase by a configurable amount. With fate-sharing protection, a list of fate-sharing groups are configured on each PLR with the links in each fate-sharing group identified by their respective IP addresses.


Our content testing team has validated and updated this example.


This example uses the following hardware and software components:

  • Nine MX Series routers

  • Junos OS Release 17.4 or later running on all devices

    • Updated and revalidated using vMX on Junos OS Release 21.1R1.

Before you configure TI-LFA routes using SPRING for IS-IS, be sure you configure SPRING or segment routing.


Are you interested in getting hands-on experience on this feature?

Visit Juniper vLabs to reserve your pre-configured vLab Sandbox: Segment Routing - Basic and try it out for free!


Junos OS allows you to enable TI-LFA for IS-IS by configuring the use-post-convergence-lfa statement at the [edit protocols isis backup-spf-options] hierarchy level. You can enable the creation of post-convergence backup paths for a given interface by configuring the post-convergence-lfa statement at the [edit protocols isis interface interface-name level level] hierarchy level.

TI-LFA provides protection against link failure, node failure, and failures of fate-sharing groups. You can enable link-protection mode using the post-convergence-lfa statement. You can enable node-protection mode, or fate-sharing-protection mode, or both modes, for a given interface at the [edit protocols isis interface interface-name level level post-convergence-lfa] hierarchy level. To ensure that the fate-sharing protection is enabled for a given fate-sharing group, you need to configure the use-for-post-convergence-lfa statement at the [edit routing-options fate-sharing group group-name] hierarchy level.


TI-LFA supports protection of routes for both IPv4 and IPv6 prefixes. This example demonstrates protection of routes for IPv4 prefixes.




CLI Quick Configuration

To quickly configure link-protection in this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.










Configuring R1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R1:

  1. Configure the interfaces.

  2. Configure the router ID.

  3. Configure MPLS.

  4. Configure IS-IS.

  5. Configure to install backup route along the link-protecting post-convergence path on interface ge-0/0/2.

  6. Configure the maximum number of labels for segment routing routed paths for protection of backup shortest-path-first attributes.

  7. Configure IPv4 index and index range for node segments in segment routing for the IS-IS protocol.

  8. (Optional) Enable node-protection on interface ge-0/0/2.

  9. (Optional) Configure the fate-sharing group cost.

  10. (Optional) Configure the fate-sharing group to indicate that link from Device R1 to Device R2 and the link from Device R21 to Device R22 share fate and allow it to be used for post-convergence-lfa.

  11. (Optional) Enable fate-sharing protection for ge-0/0/2 on Device R1.

  12. Configure a per packet load-balance policy for TI-LFA to work and ensure faster convergence.

  13. Apply the policy to export the routes into the forwarding table.


From configuration mode, confirm your configuration by entering the show interfaces, show protocols and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.


Confirm that the configuration is working properly.

Verify the TI-LFA routes using node SIDs


Verify the link-protecting backup path for primary next hops on interface ge-0/0/2 for Device R1 and verify if the backup path to reach has been created and has the correct label stack.


From operational mode, run the show route command to display the routing table information.


The primary path to reach (corresponding to Device R3) is through the interface ge-0/0/2 with a label of 801003, corresponding to the node-SID of Device R3. If the interface ge-0/0/2 fails, the backup path using the interface ge-0/0/0 using the label stack [801024, 801003] becomes active. The link-protecting post-convergence path is R1-R21-R22-R23-R24-R3. The top label on the label stack is 801024 and corresponds to the node SID to reach R24. The 801003 label corresponds to the node SID on R23 to reach R3 on the shortest path R23-R2-R3.

Verify adjacency SIDs

Verify adjacency SIDs of devices that have IS-IS adjacencies with Device R1.


The SID values can vary in your configuration setup.


From operational mode, run the show isis adjacency detail command to display the adjacency information on Device R1.


Adjacency SIDs are assigned to each adjacency of Device R1 in the segment routing domain:

  • Device R21 - 299840
  • Device R31 - 299808
  • Device R2 - 299776

The adjacency SIDs have local significance and can be used to steer traffic along specific outgoing interfaces. When you do not configure adjacency SIDs, they are dynamically assigned with a value outside of the default (or configured) SRGB range.

Verify the TI-LFA routes using adjacency SIDs


Increase the cost of the post-convergence path from R1 to R3 and verify the TI-LFA routes using adjacency SIDs to avoid the primary path to reach the destination, Device R3.


From the configuration mode, increase the cost of the interface connecting Device R22 and R23, ge-0/0/0.

From operational mode, again run the show route command.


The TI-LFA backup paths are now using the adjacency SID (in this case, 299808) instead of the node SID (801003) to reach Device R3. This is because node SIDs always use the shortest path between two nodes, and when the R22-R23 link cost went up, the shortest path to R1 overlaps with the primary path. Because TI-LFA cannot take a primary path to reach the destination, adjacency SIDs are used to take R31-R34 as the new post-convergence path to reach Device R3.