Segment Routing Configuration Guide for Cisco NCS 540 Series Routers, IOS XR Release 7.11.x
Bias-Free Language
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.
Topology-Independent Loop-Free Alternate (TI-LFA) uses segment routing to provide link, node, and Shared Risk Link Groups (SRLG) protection in topologies where other fast reroute techniques cannot provide protection.
Classic Loop-Free Alternate (LFA) is topology dependent, and therefore cannot protect all destinations in all networks. A
limitation of LFA is that, even if one or more LFAs exist, the optimal LFA may not always be provided.
Remote LFA (RLFA) extends the coverage to 90-95% of the destinations, but it also does not always provide the most desired
repair path. RLFA also adds more operational complexity by requiring a targeted LDP session to the RLFAs to protect LDP traffic.
TI-LFA provides a solution to these limitations while maintaining the simplicity of the IPFRR solution.
The goal of TI-LFA is to reduce the packet loss that results while routers converge after a topology change due to a link
or node failure. Rapid failure repair (< 50 msec) is achieved through the use of pre-calculated backup paths that are loop-free and
safe to use until the distributed network convergence process is completed.
The optimal repair path is the path that the traffic will eventually follow after the IGP has converged. This is called the
post-convergence path. This path is preferred for the following reasons:
Optimal for capacity planning — During the capacity-planning phase of the network, the capacity of a link is provisioned while
taking into consideration that such link with be used when other links fail.
Simple to operate — There is no need to perform a case-by-case adjustments to select the best LFA among multiple candidate
LFAs.
Fewer traffic transitions — Since the repair path is equal to the post-convergence path, the traffic switches paths only once.
The following topology illustrates the optimal and automatic selection of the TI-LFA repair path.
Figure 1. TI-LFA Repair Path
Node 2 protects traffic to destination Node 5.
With classic LFA, traffic would be steered to Node 4 after a failure of the protected link. This path is not optimal, since
traffic is routed over edge node Node 4 that is connected to lower capacity links.
TI-LFA calculates a post-convergence path and derives the segment list required to steer packets along the post-convergence
path without looping back.
In this example, if the protected link fails, the shortest path from Node2 to Node5 would be:
Node2 → Node6 → Node7 → Node3 → Node5
Node7 is the PQ-node for destination Node5. TI-LFA encodes a single segment (prefix SID of Node7) in the header of the packets
on the repair path.
TI-LFA Protection Types
TI-LFA supports the following protection:
Link protection — The link is excluded during the post-convergence backup path calculation.
Node protection — The neighbor node is excluded during the post convergence backup path calculation.
Shared Risk Link Groups (SRLG) protection — SRLG refer to situations in which links in a network share a common fiber (or
a common physical attribute). These links have a shared risk: when one link fails, other links in the group might also fail.
TI-LFA SRLG protection attempts to find the post-convergence backup path that excludes the SRLG of the protected link. All
local links that share any SRLG with the protecting link are excluded.
When you enable link protection, you can also enable node protection, SRLG protection, or both, and specify a tiebreaker priority
in case there are multiple LFAs.
The following example illustrates the link, node, and SRLG protection types. In this topology, Node2 applies different protection
models to protect traffic to Node7.
Figure 2. TI-LFA Protection Types
Limitations
Only two backup labels are supported.
Usage Guidelines and Limitations
The TI-LFA guidelines and limitations are listed below:
IGP directly programs a TI-LFA backup path requiring 3 or fewer labels, including the label of the protected destination prefix.
The platform does not support programming of TI-LFA backup paths requiring more than 3 labels.
Maximum number of labels that can be pushed on the backup path (including the label of the protected prefix)
3
3
BFD-triggered
Supported
Supported
BFDv6-triggered
Supported
N/A
Prefer backup path with lowest total metric
Supported
Supported
Prefer backup path from ECMP set
Supported
Supported
Prefer backup path from non-ECMP set
Supported
Supported
Load share prefixes across multiple backups paths
Supported
Supported
Limit backup computation up to the prefix priority
Supported
Supported
1 Unless specified, IS-IS support is IS-ISv4 and IS-ISv6
Configuring TI-LFA for IS-IS
This task describes how to enable per-prefix Topology Independent Loop-Free Alternate (TI-LFA) computation to converge traffic
flows around link, node, and SRLG failures.
Before you begin
Ensure that the following topology requirements are met:
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix tie-breaker srlg-disjoint index 100
Enables TI-LFA node or SRLG protection and specifies the tiebreaker priority. Valid priority values are from 1 to 255. The lower the priority value, the higher the priority of the rule. Link protection always has a lower priority than node or SRLG protection.
Note
The same attribute cannot be configured more than once on an interface.
Note
For IS-IS, TI-LFA node protection and SRLG protection can be configured on the interface or the instance.
TI-LFA has been successfully configured for segment routing.
Configuring TI-LFA for OSPF
This task describes how to enable per-prefix Topology Independent Loop-Free Alternate (TI-LFA) computation to converge traffic
flows around link, node, and SRLG failures.
Note
TI-LFA can be configured on the instance, area, or interface. When configured on the instance or area, all interfaces in the
instance or area inherit the configuration.
Before you begin
Ensure that the following topology requirements are met:
RP/0/RP0/CPU0:router(config-ospf-ar-if)# fast-reroute per-prefix tie-breaker srlg-disjoint index 100
Enables TI-LFA node or SRLG protection and specifies the tiebreaker priority. Valid priority values are from 1 to 255. The higher the priority value, the higher the priority of the rule. Link protection always has a lower priority than node or SRLG protection.
Note
The same attribute cannot be configured more than once on an interface.
TI-LFA has been successfully configured for segment routing.
TI-LFA Node and SRLG Protection: Examples
The following examples show the configuration of the tiebreaker priority for TI-LFA node and SRLG protection, and the behavior of post-convergence backup-path. These examples use OSPF, but the same configuration and
behavior applies to IS-IS.
Example: Enable link-protecting and node-protecting TI-LFA
router ospf 1
area 1
interface GigabitEthernet0/0/2/1
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa
fast-reroute per-prefix tiebreaker node-protecting index 100
Both link-protecting and node-protecting TI-LFA backup paths will be computed. If the priority associated with the node-protecting
tiebreaker is higher than any other tiebreakers, then node-protecting post-convergence backup paths will be selected, if it
is available.
Example: Enable link-protecting and SRLG-protecting TI-LFA
router ospf 1
area 1
interface GigabitEthernet0/0/2/1
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa
fast-reroute per-prefix tiebreaker srlg-disjoint index 100
Both link-protecting and SRLG-protecting TI-LFA backup paths will be computed. If the priority associated with the SRLG-protecting
tiebreaker is higher than any other tiebreakers, then SRLG-protecting post-convergence backup paths will be selected, if it
is available.
Example: Enable link-protecting, node-protecting and SRLG-protecting TI-LFA
router ospf 1
area 1
interface GigabitEthernet0/0/2/1
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa
fast-reroute per-prefix tiebreaker node-protecting index 200
fast-reroute per-prefix tiebreaker srlg-disjoint index 100
Link-protecting, node-protecting, and SRLG-protecting TI-LFA backup paths will be computed. If the priority associated with
the node-protecting tiebreaker is highest from all tiebreakers, then node-protecting post-convergence backup paths will be
selected, if it is available. If the node-protecting backup path is not available, SRLG-protecting post-convergence backup
path will be used, if it is available.
Configuring Global Weighted SRLG Protection
A shared risk link group (SRLG) is a set of links sharing a common resource and thus shares the same risk of failure. The
existing loop-free alternate (LFA) implementations in interior gateway protocols (IGPs) support SRLG protection. However,
the existing implementation considers only the directly connected links while computing the backup path. Hence, SRLG protection
may fail if a link that is not directly connected but shares the same SRLG is included while computing the backup path. Global
weighted SRLG protection feature provides better path selection for the SRLG by associating a weight with the SRLG value and
using the weights of the SRLG values while computing the backup path.
To support global weighted SRLG protection, you need information about SRLGs on all links in the area topology. You can flood
SRLGs for remote links using ISIS or manually configuring SRLGS on remote links.
Configuration Examples: Global Weighted SRLG Protection
There are three types of configurations that are supported for the global weighted SRLG protection feature.
local SRLG with global weighted SRLG protection
remote SRLG flooding
remote SRLG static provisioning
This example shows how to configure the local SRLG with global weighted SRLG protection feature.
RP/0/RP0/CPU0:router(config)# srlg
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/0
RP/0/RP0/CPU0:router(config-srlg-if)# name group1
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/1
RP/0/RP0/CPU0:router(config-srlg-if)# name group1
RP/0/RP0/CPU0:router(config-srlg)# name group value 100
RP/0/RP0/CPU0:router(config)# router isis 1
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix srlg-protection weighted-global
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix tiebreaker srlg-disjoint index 1
RP/0/RP0/CPU0:router(config-isis)# interface TenGigE0/0/0/0
RP/0/RP0/CPU0:router(config-isis-if)# point-to-point
RP/0/RP0/CPU0:router(config-isis-if)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix ti-lfa
RP/0/RP0/CPU0:router(config-isis)# srlg
RP/0/RP0/CPU0:router(config-isis-srlg)# name group1
RP/0/RP0/CPU0:router(config-isis-srlg-name)# admin-weight 5000
This example shows how to configure the global weighted SRLG protection feature with remote SRLG flooding.The configuration
includes local and remote router configuration. On the local router, the global weighted SRLG protection is enabled by using
the fast-reroute per-prefix srlg-protection weighted-global command. In the remote router configuration, you can control the SRLG value flooding by using the advertise application lfa link-attributes srlg command. You should also globally configure SRLG on the remote router.
The local router configuration for global weighted SRLG protection with remote SRLG flooding is as follows:
The remote router configuration for global weighted SRLG protection with remote SRLG flooding is as follows:
RP/0/RP0/CPU0:router(config)# srlg
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/0
RP/0/RP0/CPU0:router(config-srlg-if)# name group1
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/1
RP/0/RP0/CPU0:router(config-srlg-if)# name group1
RP/0/RP0/CPU0:router(config-srlg)# name group value 100
RP/0/RP0/CPU0:router(config-srlg)# exit
RP/0/RP0/CPU0:router(config)# router isis 1
RP/0/RP0/CPU0:(config-isis)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-af)# advertise application lfa link-attributes srlg
This example shows configuring the global weighted SRLG protection feature with static provisioning of SRLG values for remote
links. You should perform these configurations on the local router.
This feature allows the router (as ABR) to program a Generic Routing Encapsulation (GRE) tunnel as an outgoing interface for
TI-LFA backup paths computed by the IGP in a Segment Routing network. Single-segment TI-LFA scenario is supported. In this
scenario, the router pushes one extra label when programming the backup path.
Note
GRE is a tunneling protocol that provides a simple generic approach to transport packets of one protocol over another protocol
by means of encapsulation. See the
Configuring GRE Tunnels chapter in the Interface and Hardware Component Configuration Guide for Cisco NCS 540 Series Routers.
Multi-Level Network Topology
The following example shows a multi-level network topology with interconnecting links between ABRs.
Note
This could also be a multi-instance network topology.
Two links between ABR 2 and ABR 3 are required, one in each IS-IS level. These links provide protection in each direction
and ensure that there is always an alternate path inside the IGP domain.
Note
Alternatively, a single link with two logical sub-interfaces could be used between the ABRs.
TI-LFA performs the backup path calculation inside the domain (process, level, or area) of the failed link.
For example, if the link between nodes 2 and 5 failed, the link between ABR 2 and 3 would create a TI-LFA path in L1 IS-IS
level. If the link between nodes 1 and 2 failed, the link between ABR 2 and 3 would create a TI-LFA path in L2 IS-IS level.
However, if the interconnecting link between ABRs are in the same Shared Risk Link Groups (SRLG) as other links inside the
domain (for example, the link between Nodes 2 and 3 are in the same SRLG as link between Nodes 2 and 5), TI-LFA with local
SRLG protection would not find an alternate path.
In cases where it is not feasible to provide interconnecting links between ABRs (for example, the ABR nodes might be in different
locations with no connectivity options), TI-LFA will not be able to compute backup paths for all of the prefixes.
To address these issues, you can create a GRE tunnel in each domain, between the ABRs, which can be used as TI-LFA backup
paths.
Now, if a link failure occurs in either IS-IS level (for example, between nodes 1 and 2 or between nodes 2 and 5), the path
is protected by the GRE tunnel.
Backup Path for Link Failure Between Nodes 2 and 5
Traffic from node 1 is rerouted over the GRE tunnel TI-LFA backup path between ABR nodes 2 and 3.
Traffic flowing in the opposite direction, from node 5 to node 1, is simply routed over nodes 6-3-4 to node 1.
Limitations
The following behaviors and limitations apply to the router when a GRE tunnel is programmed as backup interface for TI-LFA:
The MPLS label of a protected prefix must be the same in the primary and backup paths (SWAP scenario)
Single-segment TI-LFA is supported. In this scenario, the router pushes one extra label when programming the backup path.
The total label stack is 2, including the primary label and backup label.
Double-segment (or more) TI-LFA is not supported. In this scenario, the router pushes two or more extra labels when programming
the backup path.
GRE tunnel as a primary or backup path for an SR policy with TI-LFA protection is not supported.
Example: SR-MPLS over GRE as TI-LFA Backup Path
The examples in this section use the following network topology:
Configurations Without Interconnecting ABR Links
The following sample configurations show OSPF configurations for nodes 2, 3 and 5. Nodes 2 and 3 are ABRs between Area 0 and
Area 100. There is no connection between the ABRs.
RP/0/RSP0/CPU0:ABR2# show ospf neighbor area-sorted
Fri Jul 19 09:43:59.328 UTC
Neighbors for OSPF 100
Area 0
Neighbor ID Pri State Dead Time Address Up Time Interface
10.1.1.1 1 FULL/ - 00:00:35 10.1.2.1 1d20h Te0/0/1/10
Total neighbor count: 1
Area 100
Neighbor ID Pri State Dead Time Address Up Time Interface
5.5.5.5 1 FULL/ - 00:00:33 10.2.5.5 1d20h Te0/0/1/11
Total neighbor count: 1
RP/0/RSP0/CPU0:ABR3# show ospf neighbor area-sorted
Fri Jul 19 09:33:35.816 UTC
Neighbors for OSPF 100
Area 0
Neighbor ID Pri State Dead Time Address Up Time Interface
4.4.4.4 1 FULL/ - 00:00:36 10.3.4.4 2d17h Te0/0/0/9
Total neighbor count: 1
Area 100
Neighbor ID Pri State Dead Time Address Up Time Interface
6.6.6.6 1 FULL/ - 00:00:36 10.3.6.6 2d19h Te0/0/0/3
Total neighbor count: 1
Configuration on Node 5
segment-routing mpls
!
set-attributes
address-family ipv4
sr-label-preferred
!
connected-prefix-sid-map
address-family ipv4
5.5.5.5/32 index 5 range 1
!
interface TenGigabitEthernet0/0/26
description ***Connected to ABR 2
ip address 10.2.5.5 255.255.255.0
ip ospf network point-to-point
cdp enable
!
interface TenGigabitEthernet0/0/27
description ***Connected to Node 6
ip address 10.5.6.5 255.255.255.0
ip ospf network point-to-point
cdp enable
router ospf 100
router-id 5.5.5.5
segment-routing area 100 mpls
segment-routing mpls
fast-reroute per-prefix enable prefix-priority low
fast-reroute per-prefix ti-lfafast-reroute per-prefix ti-lfa area 100
passive-interface default
no passive-interface TenGigabitEthernet0/0/26
no passive-interface TenGigabitEthernet0/0/27
network 10.2.5.0 0.0.0.255 area 100
network 10.5.5.0 0.0.0.255 area 100
network 10.5.6.0 0.0.0.255 area 100
network 5.5.5.5 0.0.0.0 area 100
RP/0/RSP0/CPU0:Node5# show ip ospf neighbor
Load for five secs: 4%/1%; one minute: 4%; five minutes: 4%
Time source is NTP, 09:50:51.417 UTC Fri Jul 19 2019
Neighbor ID Pri State Dead Time Address Interface
6.6.6.6 0 FULL/ - 00:00:32 10.5.6.6 TenGigabitEthernet0/0/27
2.2.2.2 0 FULL/ - 00:00:36 10.5.2.5 TenGigabitEthernet0/0/26
TI-LFA Fast Reroute Coverage on Node 5
The following output shows that this configuration provides only 52% TI-LFA fast reroute coverage on Node 5:
RP/0/RSP0/CPU0:Node5# show ip ospf fast-reroute prefix-summary
Load for five secs: 4%/1%; one minute: 4%; five minutes: 4%
Time source is NTP, 10:32:20.236 UTC Fri Jul 19 2019
OSPF Router with ID (5.5.5.5) (Process ID 100)
Base Topology (MTID 0)
Area 100:
Interface Protected Primary paths Protected paths Percent protected
All High Low All High Low All High Low
Lo0 Yes 0 0 0 0 0 0 0% 0% 0%
Te0/0/27 Yes 7 4 3 1 1 0 14% 25% 0%
Te0/0/26 Yes 10 5 5 8 4 4 80% 80% 80%
Area total: 17 9 8 9 5 4 52% 55% 50%
Process total: 17 9 8 9 5 4 52% 55% 50%
GRE Tunnel Configuration
The following examples show how to configure GRE tunnels between the ABRs in each area to provide TI-LFA backup paths for
the Segment Routing network.
GRE BLU is configured in Area 0 using Loopback50 (on ABR2) and Loopback 60 (on ABR 3). These loopbacks are advertised in Area 100:
Figure 3. GRE BLU
GRE RED is configured in Area 100 using Loopback55 (on ABR2) and Loopback 66 (on ABR3). These loopbacks are advertised in Area 0:
Figure 4. GRE RED
Configuration on ABR 2
interface Loopback0
ipv4 address 2.2.2.2 255.255.255.255
!
interface Loopback50
description Lo for GRE BLU
ipv4 address 50.0.0.50 255.255.255.0
!
interface Loopback55
description Lo for GRE RED
ipv4 address 55.55.55.55 255.255.255.255
!
interface tunnel-ip5060
description GRE virtual link for Area 0 BLU
ipv4 address 66.3.2.2 255.255.255.0
tunnel source Loopback50
tunnel destination 60.0.0.60
!
interface tunnel-ip5566
description GRE virtual link for Area 100 RED
ipv4 address 100.3.2.2 255.255.255.0
tunnel source Loopback55
tunnel destination 66.66.66.66
router ospf 100
router-id 2.2.2.2
segment-routing mpls
segment-routing forwarding mpls
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
segment-routing sr-prefer
area 0
interface Loopback0
prefix-sid index 2
!
interface Loopback55
passive enable
!
interface tunnel-ip5060cost 1000
!
interface TenGigE0/0/1/10
network point-to-point
!
!
area 100interface Loopback50
passive enable
!
interface tunnel-ip5566cost 1000
!
interface TenGigE0/0/1/11
network point-to-point
Note
In the above configuration, GRE tunnel-ip5060 belongs to area 0, but its source and destination addresses are advertised in
area 100. This ensures disjointness between the GRE tunnel and the links in area 0 that it protects. The same applies to GRE
tunnel-ip5566 which belongs to area 100 and its source and destination addresses are advertised in area 0.
A high cost is applied to the GRE tunnel interfaces so that they are used only as a backup path.
Configuration on ABR 3
interface Loopback0
ipv4 address 3.3.3.3 255.255.255.255
!
interface Loopback60
description Lo for GRE BLU
ipv4 address 60.0.0.60 255.255.255.0
!
interface Loopback66
description Lo for GRE RED
ipv4 address 66.66.66.66 255.255.255.255
!
interface tunnel-ip5060
description GRE virtual link for Area 0 BLU
ipv4 address 66.3.2.3 255.255.255.0
tunnel source Loopback60
tunnel destination 50.0.0.50
!
interface tunnel-ip5566
description GRE virtual link for Area 100 RED
ipv4 address 100.3.2.3 255.255.255.0
tunnel source Loopback66
tunnel destination 55.55.55.55
router ospf 100
router-id 3.3.3.3
segment-routing mpls
segment-routing forwarding mpls
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
segment-routing sr-prefer
area 0
interface Loopback0
prefix-sid index 3
!
interface TenGigE0/0/0/9
network point-to-point
!
interface Loopback66
passive enable
!
interface tunnel-ip5060cost 1000
!
area 100
interface TenGigE0/0/0/3
network point-to-point
!
interface Loopback60
passive enable
!
interface tunnel-ip5566cost 1000
Note
In the above configuration, GRE tunnel-ip5060 belongs to area 0, but its source and destination addresses are advertised in
area 100. This ensures disjointness between the GRE tunnel and the links in area 0 that it protects. The same applies to GRE
tunnel-ip5566 which belongs to area 100 and its source and destination addresses are advertised in area 0.
A high cost is applied to the GRE tunnel interfaces so that they are used only as a backup path.
TI-LFA Fast Reroute Coverage on Node 5 After GRE Tunnel Configuration
The following output shows that this configuration provides 100% TI-LFA fast reroute coverage on Node 5:
RP/0/RSP0/CPU0:Node5# show ip ospf fast-reroute prefix-summary
Load for five secs: 5%/1%; one minute: 4%; five minutes: 4%
Time source is NTP, 11:20:31.743 UTC Fri Jul 19 2019
OSPF Router with ID (5.5.5.5) (Process ID 100)
Base Topology (MTID 0)
Area 100:
Interface Protected Primary paths Protected paths Percent protected
All High Low All High Low All High Low
Lo0 Yes 0 0 0 0 0 0 0% 0% 0%
Te0/0/27 Yes 9 6 3 9 6 3 100% 100% 100%
Te0/0/26 Yes 11 6 5 11 6 5 100% 100% 100%
Area total: 20 12 8 20 12 8 100% 100% 100%
Process total: 20 12 8 20 12 8 100% 100% 100%
Traffic Flow with GRE Tunnel as TI-LFA Backup
With a link failure between Node 1 and ABR 2, traffic flowing from Node 1 to Node 5 is simply routed through Nodes 4-3-6 to
Node 5.
With GRE tunnel as TI-LFA backup, traffic flowing from Node 5 to Node 1 will be encapsulated at ABR2 and routing over the
GRE tunnel.
With a link failure between Node 5 and ABR 2, traffic flowing from Node 5 to Node 1 is simply routed through Nodes 6-3-4 to
Node 1.
With GRE tunnel as TI-LFA backup, traffic flowing from Node 1 to Node 5 will be encapsulated at ABR2 and routing over the
GRE tunnel.
Feedback