Date created: Monday, July 13, 2015 5:15:55 PM. Last modified: Wednesday, June 29, 2022 8:51:53 AM
OSPFv2 IPFRR - LFA & rLFA
References:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bfd/configuration/xe-3s/irb-xe-3s-book/irb-bi-fwd-det.html
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-3s/iro-lfa-frr-xe.html
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-3s/iro-xe-3s-book/iro-ipfrr-lfa.html
http://www.cisco.com/c/en/us/td/docs/routers/xr12000/software/xr12k_r4-1/routing/configuration/guide/routing_cg41xr12k_chapter4.html#con_1394056
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/mpls/configuration/guide/b-mpls-cg53x-asr9k/b-mpls-cg53x-asr9k_chapter_01010.html
http://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/iproute/iri-xe-3s-asr920-book/iri-lfa-frr.html#GUID-A96CBA57-FDC6-49C8-8BC0-C85A117CC670
OSPF IPv4 FRR LFA & rLFA is available in IOS 15.1(3)S and XE 3.4S and IOS-XR 3.9 onwards.This example shows per-prefix LFA only, not per-link LFA (which is IOS-XR only).
Contents:
Restrictions
Topology
IPFRR LFA
IPFRR rLFA
Microloops
- The OSPF IPv4 Remote Loop-Free Alternate IP Fast Reroute feature is not supported on devices that are virtual links headends.
- The feature is supported only in global VPN routing and forwarding (VRF) OSPF instances.
- The only supported tunneling method is MPLS.
- You cannot configure a traffic engineering (TE) tunnel interface as a protected interface. Use the MPLS Traffic Engineering—Fast Reroute Link and Node Protection feature to protect these tunnels. For more information, see the "MPLS Traffic Engineering—Fast Reroute Link and Node Protection" section in the Multiprotocol Label Switching Configuration Guide.
- You can configure a TE tunnel interface in a repair path, but OSPF will not verify the tunnel's placement; you must ensure that it is not crossing the physical interface that it is intended to protect.
- Not all routes can have repair paths. Multipath primary routes might have repair paths for all, some, or no primary paths, depending on the network topology, the connectivity of the computing router, and the attributes required of repair paths.
- Devices that can be selected as tunnel termination points must have a /32 address advertised in the area in which remote LFA is enabled. This address will be used as a tunnel termination IP. If the device does not advertise a /32 address, it may not be used for remote LFA tunnel termination.
- All devices in the network that can be selected as tunnel termination points must be configured to accept targeted LDP sessions using the mpls ldp discovery targeted-hello accept command.
- Logical interfaces namely Port-channel (PoCH) do not support LFA FRR and remote LFA-FRR.
- Micro loops may form due to traffic congestion.
- For TDM psuedowires, the interfaces supported are CEM (CESoP, SAToP) and IMA (PVC,PVP); supported both on OC-3 and T1/E1 controllers. A maximum of 500 VCs can be configured per OC-3 controller.
- Each bridge domain interface (BDI) protected by FRR can have only one EFP.
- The maximum number of bridge-domain interfaces(BDI) that can act as protected or protecting interfaces via FRR is 24.
- Remote LFA FRR with VPLS provides better convergence with SFP ports rather than copper ports. As a workaround for copper ports, BFD triggered FRR can be used.
- Asymmetric LFA FRR is not supported.
- FRR is not supported with POS and serial interfaces.
- The implicit-null keyword is not supported.
- The OSPF/ISIS configuration option "ispf" is not recommended although it is supported
On IOS-XR:
- BVI interface (IRB) is not supported either as primary or backup path.
- GRE tunnel is not supported either as primary or backup path.
- Cisco ASR 9000 Series SPA Interface Processor-700 POS line card on Cisco ASR 9000 Series Router is not supported as primary link. It can be used as LFA backup only on main interface.
- In a multi-topology scenerio, the route in topology T can only use LFA within topology T. Hence, the availability of a backup path depends on the topology.
Manual OSPF costs forcing all links to have an OSPF cost of 10 means the test machines have ECMP routes between the PEs ASR920 <> ME3800X. The initial network state without IP FRR configured is shown below:
ME3800#show run | s router ospf
router ospf 1
router-id 1.0.0.4
timers throttle spf 50 200 5000
timers throttle lsa 50 200 5000
timers lsa arrival 100
passive-interface default
no passive-interface TenGigabitEthernet0/1
no passive-interface TenGigabitEthernet0/2
network 1.0.0.4 0.0.0.0 area 0
bfd all-interfaces
mpls ldp sync
interface TenGigabitEthernet0/1
description ASR9001:Te0/0/1/3
no switchport
dampening
mtu 1600
ip address 10.0.3.2 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
ip ospf network point-to-point
ip ospf 1 area 0
ip ospf cost 10
load-interval 30
carrier-delay 5
ntp disable
mpls ip
bfd interval 50 min_rx 50 multiplier 3
no bfd echo
ME3800#show ip route | beg Gate
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 5 subnets
O 1.0.0.2 [110/21] via 10.0.3.1, 00:13:45, TenGigabitEthernet0/1
[110/21] via 10.0.4.2, 00:13:45, TenGigabitEthernet0/2
O 1.0.0.3 [110/11] via 10.0.3.1, 00:13:45, TenGigabitEthernet0/1
C 1.0.0.4 is directly connected, Loopback0
O 1.0.0.5 [110/11] via 10.0.4.2, 00:13:47, TenGigabitEthernet0/2
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O 10.0.1.0/30 [110/20] via 10.0.3.1, 00:13:45, TenGigabitEthernet0/1
O 10.0.2.0/30 [110/20] via 10.0.3.1, 00:13:45, TenGigabitEthernet0/1
C 10.0.3.0/30 is directly connected, TenGigabitEthernet0/1
L 10.0.3.2/32 is directly connected, TenGigabitEthernet0/1
C 10.0.4.0/30 is directly connected, TenGigabitEthernet0/2
L 10.0.4.1/32 is directly connected, TenGigabitEthernet0/2
ME3800#show ip ospf fast-reroute
OSPF Router with ID (1.0.0.4) (Process ID 1)
Loop-free Fast Reroute not configured.
ME3800#show bfd neighbors
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
10.0.3.1 1/2148073479 Up Up Te0/1
10.0.4.2 2/1 Up Up Te0/2
ME3800#show ip cef 1.0.0.2/32 detail
1.0.0.2/32, epoch 0
local label info: global/29
1 RR source [no flags]
nexthop 10.0.3.1 TenGigabitEthernet0/1 label 16001
Below OSPF IPFRR LFA is enabled and a route-map is used to prioritise loopback prefixes, point to point interface addresses are not important in this topology:
! IOS and IOS-XE ip prefix-list LOOPBACK-PREFIXES seq 5 permit 1.0.0.0/28 ge 32 route-map OSPF-SPF-PRIORITY permit 10 match ip address prefix-list LOOPBACK-PREFIXES exit router ospf 1 fast-reroute keep-all-paths ! Not needed, but it's nice to see whats going on. ! This keeps all candidate repair-paths in OSPF RIB (good for troubleshooting only). ! The default (without this key-word) means the router only the best repair path in the OSPF RIB. fast-reroute per-prefix enable area 0 prefix-priority high ! Onyl calculate LFA paths for high priority prefixes prefix-priority high route-map OSPF-SPF-PRIORITY exit ! Interface options: ! If an interface is not desired to be used for backup paths ! no ip ospf fast-reroute per-prefix candidate disable ! ! Primary routes pointing to this interface will not be protected ! no ip ospf fast-reroute per-prefix protection disable ! IOS-XR router ospf 1 fast-reroute per-prefix fast-reroute per-prefix priority-limit high commit
After configuring OSPF IPFRR LFA it can be seen below on the ME3800X that a backup path has been calculated and in the OSPF RIB the prefix of the ASR920 loopback (1.0.0.2/32) is marked as "HiPro". Also note that since there are two equal cost multi-paths around the ring between the ME3800X and ASR920 (clockwise and anti-clockwise), two routes are present in the FIB and thus four routes are available when using the repair paths (as each of the two ECMP paths are a backup path for each other):
ME3800#show ip route repair-paths 1.0.0.2 255.255.255.255
Routing entry for 1.0.0.2/32
Known via "ospf 1", distance 110, metric 21, type intra area
Last update from 10.0.4.2 on TenGigabitEthernet0/2, 00:27:36 ago
Routing Descriptor Blocks:
10.0.4.2, from 1.0.0.2, 00:27:36 ago, via TenGigabitEthernet0/2
Route metric is 21, traffic share count is 1
Repair Path: 10.0.3.1, via TenGigabitEthernet0/1
* 10.0.3.1, from 1.0.0.2, 06:20:51 ago, via TenGigabitEthernet0/1
Route metric is 21, traffic share count is 1
Repair Path: 10.0.4.2, via TenGigabitEthernet0/2
ME3800#show ip cef 1.0.0.2/32 de
1.0.0.2/32, epoch 0, per-destination sharing
local label info: global/32
1 RR source [no flags]
nexthop 10.0.3.1 TenGigabitEthernet0/1 label [16001|20]
repair: attached-nexthop 10.0.4.2 TenGigabitEthernet0/2
nexthop 10.0.4.2 TenGigabitEthernet0/2 label [20|16001]
repair: attached-nexthop 10.0.3.1 TenGigabitEthernet0/1
ME3800#show ip cef 1.0.0.2/32 internal
1.0.0.2/32, epoch 0, RIB[I], refcount 6, per-destination sharing
sources: RIB, RR, LTE
feature space:
IPRM: 0x00028000
LFD: 1.0.0.2/32 1 local label
local label info: global/32
contains path extension list
disposition chain 0x10BD19E4
label switch chain 0x10BD19E4
subblocks:
1 RR source [no flags]
non-eos chain loadinfo 10BD19E4, per-session, flags 001B, 6 locks
ifnums:
TenGigabitEthernet0/1(79): 10.0.3.1
TenGigabitEthernet0/2(80): 10.0.4.2
path 11E759EC, path list 11E9B1EC, share 1/1, type attached nexthop, for IPv4, flags has-repair
MPLS short path extensions: MOI flags = 0x20 label 16001
nexthop 10.0.3.1 TenGigabitEthernet0/1 label [16001|20], adjacency IP adj out of TenGigabitEthernet0/1, addr 10.0.3.1 12028FA0
repair: attached-nexthop 10.0.4.2 TenGigabitEthernet0/2 (11E7574C)
path 11E7574C, path list 11E9B1EC, share 1/1, type attached nexthop, for IPv4, flags has-repair
MPLS short path extensions: MOI flags = 0x20 label 20
nexthop 10.0.4.2 TenGigabitEthernet0/2 label [20|16001], adjacency IP adj out of TenGigabitEthernet0/2, addr 10.0.4.2 09DB86A0
repair: attached-nexthop 10.0.3.1 TenGigabitEthernet0/1 (11E759EC)
output chain:
loadinfo 10BD19E4, per-session, 2 choices, flags 001B, 9 locks
flags: Per-session, for-rx-IPv4, for-mpls-at-eos, for-mpls-not-at-eos
16 hash buckets
< 0 > label [20|16001]
FRR Primary (0x130291E0)
< 1 > label [16001|20]
FRR Primary (0x10B89240)
..... down to 15!
ME3800#show ip ospf rib 1.0.0.2 255.255.255.255
OSPF Router with ID (1.0.0.4) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
LSA: type/LSID/originator
*> 1.0.0.2/32, Intra, cost 21, area 0
SPF Instance 58, age 00:29:50
Flags: RIB, HiPrio
via 10.0.4.2, TenGigabitEthernet0/2
Flags: RIB
LSA: 1/1.0.0.2/1.0.0.2
repair path via 10.0.3.1, TenGigabitEthernet0/1, cost 21
Flags: RIB, Repair, IntfDj, BcastDj, PrimPath, NodeProt, Downstr
LSA: 1/1.0.0.2/1.0.0.2
via 10.0.3.1, TenGigabitEthernet0/1
Flags: RIB
LSA: 1/1.0.0.2/1.0.0.2
repair path via 10.0.4.2, TenGigabitEthernet0/2, cost 21
Flags: RIB, Repair, IntfDj, BcastDj, PrimPath, NodeProt, Downstr
LSA: 1/1.0.0.2/1.0.0.2
Below remote LFA (rLFA) is configured in additiona of LFA:
! IOS and IOS-XE mpls ldp explicit-null mpls ldp discovery targeted-hello accept router ospf 1 fast-reroute per-prefix remote-lfa area 0 tunnel mpls-ldp commit ! IOS-XR router ospf 1 area 0 fast-reroute per-prefix remote-lfa tunnel mpls-ldp
After enabling rLFA routes within OSPF which did not have an ECMP (unlike the Lo0 on the ME3800X to Lo0 on the ASR920 path) now show as having a repair path. From the output below, 1.0.0.5/32 on Lo0 on the ME3600X is reachable from the ME3800X via Te0/2, a backup/repair path exists going the other way around the ring, which has a higher cost so previously it wasn't considered by OSPF (unless un-equal cost mulipathing was enabled).
ME3800#show ip route repair-paths | beg Gate
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 4 subnets
O 1.0.0.2 [110/21] via 10.0.4.2, 00:39:17, TenGigabitEthernet0/2
Repair Path: 10.0.3.1, via TenGigabitEthernet0/1
[110/21] via 10.0.3.1, 06:32:32, TenGigabitEthernet0/1
Repair Path: 10.0.4.2, via TenGigabitEthernet0/2
O 1.0.0.3 [110/11] via 10.0.3.1, 00:39:22, TenGigabitEthernet0/1
Repair Path: 1.0.0.2, via MPLS-Remote-Lfa2
[RPR][110/120] via 1.0.0.2, 00:39:22, MPLS-Remote-Lfa2
C 1.0.0.4 is directly connected, Loopback0
O 1.0.0.5 [110/11] via 10.0.4.2, 00:39:17, TenGigabitEthernet0/2
Repair Path: 1.0.0.2, via MPLS-Remote-Lfa3
[RPR][110/30] via 1.0.0.2, 00:39:17, MPLS-Remote-Lfa3
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O 10.0.1.0/30 [110/20] via 10.0.4.2, 00:39:17, TenGigabitEthernet0/2
O 10.0.2.0/30 [110/20] via 10.0.3.1, 06:32:32, TenGigabitEthernet0/1
C 10.0.3.0/30 is directly connected, TenGigabitEthernet0/1
L 10.0.3.2/32 is directly connected, TenGigabitEthernet0/1
C 10.0.4.0/30 is directly connected, TenGigabitEthernet0/2
L 10.0.4.1/32 is directly connected, TenGigabitEthernet0/2
From the ME3600X we can see that only high priority paths are being protect (due to the route-map applied to the OSPF process on each PE) and the number of protected prefixes:
ME3600#show ip ospf fast-reroute ?
prefix-summary Prefix protection statistic
remote-lfa Remote LFA FastReroute information
| Output modifiers
ME3600#show ip ospf fast-reroute
OSPF Router with ID (1.0.0.5) (Process ID 1)
Loop-free Fast Reroute protected prefixes:
Area Topology name Priority Remote LFA Enabled
0 Base High Yes
Repair path selection policy tiebreaks (built-in default policy):
10 srlg
20 primary-path
30 interface-disjoint
40 lowest-metric
50 linecard-disjoint
60 node-protecting
70 broadcast-interface-disjoint
256 load-sharing
Last SPF calculation started 00:04:41 ago and was running for 4 ms.
ME3600#show ip ospf fast-reroute prefix-summary
OSPF Router with ID (1.0.0.5) (Process ID 1)
Base Topology (MTID 0)
Area 0:
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/1 Yes 3 2 1 2 2 0 66% 100% 0%
Te0/2 Yes 3 2 1 2 2 0 66% 100% 0%
Gi0/23 Yes 0 0 0 0 0 0 0% 0% 0%
Area total: 6 4 2 4 4 0 66% 100% 0%
Process total: 6 4 2 4 4 0 66% 100% 0%
In the case more predictable routing/forwarding is wanted the ECMP can be removed by adding "maximum-paths 1" to each PE's OSPF process. On the ME3800X there is now only one path via Te0/1 to the ASR920's loopback 1.0.0.2/32. The other path via Te0/2 and the ME3600 is a repair path.
ME3800#show ip route repair-paths | beg Gate
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 4 subnets
O 1.0.0.2 [110/21] via 10.0.3.1, 00:04:54, TenGigabitEthernet0/1
Repair Path: 10.0.4.2, via TenGigabitEthernet0/2
[RPR][110/111] via 10.0.4.2, 00:04:54, TenGigabitEthernet0/2
O 1.0.0.3 [110/11] via 10.0.3.1, 00:00:22, TenGigabitEthernet0/1
Repair Path: 1.0.0.2, via MPLS-Remote-Lfa11
[RPR][110/30] via 1.0.0.2, 00:00:22, MPLS-Remote-Lfa11
C 1.0.0.4 is directly connected, Loopback0
O 1.0.0.5 [110/11] via 10.0.4.2, 00:04:24, TenGigabitEthernet0/2
Repair Path: 1.0.0.2, via MPLS-Remote-Lfa10
[RPR][110/30] via 1.0.0.2, 00:04:24, MPLS-Remote-Lfa10
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O 10.0.1.0/30 [110/20] via 10.0.4.2, 00:04:24, TenGigabitEthernet0/2
O 10.0.2.0/30 [110/20] via 10.0.3.1, 00:05:37, TenGigabitEthernet0/1
C 10.0.3.0/30 is directly connected, TenGigabitEthernet0/1
L 10.0.3.2/32 is directly connected, TenGigabitEthernet0/1
C 10.0.4.0/30 is directly connected, TenGigabitEthernet0/2
L 10.0.4.1/32 is directly connected, TenGigabitEthernet0/2
ME3800#show ip cef 1.0.0.5/32 detail
1.0.0.5/32, epoch 0
local label info: global/31
nexthop 10.0.4.2 TenGigabitEthernet0/2 label [explicit-null|16]
repair: attached-nexthop 1.0.0.2 MPLS-Remote-Lfa10
nexthop 1.0.0.2 MPLS-Remote-Lfa10, repair
ME3800#show ip ospf fast-reroute remote-lfa tunnels
OSPF Router with ID (1.0.0.4) (Process ID 1)
Area with ID (0)
Base Topology (MTID 0)
Interface MPLS-Remote-Lfa10
Tunnel type: MPLS-LDP
Tailend router ID: 1.0.0.2
Termination IP address: 1.0.0.2
Outgoing interface: TenGigabitEthernet0/1
First hop gateway: 10.0.3.1
Tunnel metric: 20
Protects:
10.0.4.2 TenGigabitEthernet0/2, total metric 30
Interface MPLS-Remote-Lfa11
Tunnel type: MPLS-LDP
Tailend router ID: 1.0.0.2
Termination IP address: 1.0.0.2
Outgoing interface: TenGigabitEthernet0/2
First hop gateway: 10.0.4.2
Tunnel metric: 20
Protects:
10.0.3.1 TenGigabitEthernet0/1, total metric 30
ME3800#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
30 Pop Label 1.0.0.3/32 5269 Te0/1 10.0.3.1
31 explicit-n 1.0.0.5/32 17316 Te0/2 10.0.4.2
32 16001 1.0.0.2/32 457 Te0/1 10.0.3.1
33 No Label 192.168.4.0/24[V] \
0 aggregate/CUST1
ME3800#show ip cef 1.0.0.5/32 internal
1.0.0.5/32, epoch 0, RIB[I], refcount 5, per-destination sharing
sources: RIB, LTE
feature space:
IPRM: 0x00028000
LFD: 1.0.0.5/32 1 local label
local label info: global/31
contains path extension list
disposition chain 0x1274D198
label switch chain 0x1274D198
ifnums:
TenGigabitEthernet0/2(80): 10.0.4.2
MPLS-Remote-Lfa10(7420)
path 11E75BAC, path list 11E9B41C, share 1/1, type attached nexthop, for IPv4, flags has-repair
MPLS short path extensions: MOI flags = 0x20 label explicit-null
nexthop 10.0.4.2 TenGigabitEthernet0/2 label [explicit-null|16], adjacency IP adj out of TenGigabitEthernet0/2, addr 10.0.4.2 09DB86A0
repair: attached-nexthop 1.0.0.2 MPLS-Remote-Lfa10 (11E75CFC)
path 11E75CFC, path list 11E9B41C, share 1/1, type attached nexthop, for IPv4, flags repair, repair-only
nexthop 1.0.0.2 MPLS-Remote-Lfa10, repair, adjacency IP midchain out of MPLS-Remote-Lfa10 09DB7F20
output chain: label [explicit-null|16]
FRR Primary (0x13041320)
Output from the ASR9001 below. Here it can be seen the ASR9001 is not limited to creating repair paths for loopback addresses only, it has a repair path for /30 point-to-point interface range 10.0.4.0/30:
RP/0/RSP0/CPU0:ASR9001#show route | beg Gate
Gateway of last resort is not set
O 1.0.0.2/32 [110/0] via 10.0.2.1, 00:00:09, TenGigE0/0/1/2 (!)
[110/41] via 10.0.3.2, 00:00:09, TenGigE0/0/1/3
L 1.0.0.3/32 is directly connected, 1w4d, Loopback0
O 1.0.0.4/32 [110/0] via 10.0.2.1, 00:00:09, TenGigE0/0/1/2 (!)
[110/11] via 10.0.3.2, 00:00:09, TenGigE0/0/1/3
O 1.0.0.5/32 [110/0] via 10.0.2.1, 00:00:09, TenGigE0/0/1/2 (!)
[110/21] via 10.0.3.2, 00:00:09, TenGigE0/0/1/3
O 10.0.1.0/30 [110/0] via 10.0.2.1, 00:00:09, TenGigE0/0/1/2 (!)
[110/40] via 10.0.3.2, 00:00:09, TenGigE0/0/1/3
C 10.0.2.0/30 is directly connected, 00:00:09, TenGigE0/0/1/2
L 10.0.2.2/32 is directly connected, 00:00:09, TenGigE0/0/1/2
C 10.0.3.0/30 is directly connected, 1w4d, TenGigE0/0/1/3
L 10.0.3.1/32 is directly connected, 1w4d, TenGigE0/0/1/3
O 10.0.4.0/30 [110/0] via 10.0.2.1, 00:00:09, TenGigE0/0/1/2 (!)
[110/20] via 10.0.3.2, 00:00:09, TenGigE0/0/1/3
L 127.0.0.0/8 [0/0] via 0.0.0.0, 9w0d
Microloops can occur with FRR (r)LFR. Ideally they are so small it is not worth doing anything about however, if legacy hardware is present that is significantly slower than other devices then it is possible to delay updates to the RIB on the faster devices to prevent microloops during a reconvergence event.
Microloop avoidance is automatically enabled as soon as remote LFA (rLFA) is enabled. The options below are to restrict it to protected prefixes only (without the keyword "protected" it is applied to all prefixes) and to implement a RIB update delay):
router ospf 1 microloop avoidance protected
microloop avoidance rib-update-delay 1000 ! msec
If some old pokey serial link is still in the mixture of IGP links it can be excluded from the backup interface candidate selection process using the following interface level command:
interface x/y ip ospf fast-reroute per-prefix candidate disable
Previous page: OSPFv2 Inter-Area Filtering & Prefix-Suppression
Next page: IOS Regex