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

Restrictions:

On IOS/IOS-XE:
  • 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.

 

Topology:

IPFRR LFA:

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

IP FRR rLFA:

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

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