OSPF Loop-Free Alternate (LFA) Fast Reroute (FRR)

Lessons Discussion
15

Hi Kamal,

It is confusing indeed. In these two documents:

http://www.massimilianosbaraglia.it/documenti/engineering/routing/cisco/LFA%20fast%20reroute.pdf

They explain that high priority prefixes get programmed before low priority prefixes. A high priority prefix is a /32 prefix.

In this document:

They state:

Low priority specifies that all prefixes have the same eligibility for protection. High priority specifies that only high-priority prefixes are protected.

So, the only thing left to do is a lab it up :slight_smile:

To see this in action, I’ll enable all OSPF LFA debugs:

R1#debug ip ospf fast-reroute rib
OSPF Loop-free FastReroute local RIB debugging is on

R1#debug ip ospf fast-reroute spf
OSPF Loop-free FastReroute SPF computation debugging is on

R1#debug ip ospf fast-reroute ti-lfa rib
OSPF TI-LFA Loop-free FastReroute local RIB debugging is on

R1#debug ip ospf fast-reroute ti-lfa spf
OSPF TI-LFA Loop-free FastReroute SPF computation debugging is on

Let’s enable prefix-priority high:

R1(config)#router ospf 1
R1(config-router)#fast-reroute per-prefix enable area 0 prefix-priority high

And I’ll add a new /8 prefix on a physical interface of R5:

R5(config)#interface GigabitEthernet1 
R5(config-if)#ip address 55.55.55.55 255.0.0.0

R5(config)#router ospf 1
R5(config-router)#network 55.0.0.0 0.255.255.255 area 0

Let’s check R1:

R1#show ip route 55.0.0.0   
Routing entry for 55.0.0.0/8
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 192.168.15.5 on GigabitEthernet3, 00:01:36 ago
  Routing Descriptor Blocks:
  * 192.168.15.5, from 5.5.5.5, 00:01:36 ago, via GigabitEthernet3
      Route metric is 2, traffic share count is 1

It doesn’t have a repair path. In the debug, you can see why:

OSPF-1 FRRIB: Add to LRIB repair path 55.0.0.0/255.0.0.0 via neighbor 5.5.5.5, area 0, type Intra, D(N,D)=1, ext2 metric 0 
OSPF-1 FRRIB:   Prefix priority is lower than cfg threshold

So it sees the prefix but ignores it because of the threshold. I looked for a command that allows me to change the threshold but I couldn’t find anything. Let’s try another prefix:

R5(config)#interface GigabitEthernet 1
R5(config-if)#ip address 55.55.55.55 255.255.0.0

Still the same error:

OSPF-1 FRRIB: Add to LRIB repair path 55.55.0.0/255.255.0.0 via neighbor 2.2.2.2, area 0, type Intra, D(N,D)=3, ext2 metric 0 
OSPF-1 FRRIB:   Prefix priority is lower than cfg threshold

Another test:

R5(config)#interface GigabitEthernet 1
R5(config-if)#ip address 55.55.55.55 255.255.255.0
OSPF-1 FRRIB: Add to LRIB repair path 55.55.55.0/255.255.255.0 via neighbor 5.5.5.5, area 0, type Intra, D(N,D)=1, ext2 metric 0 
OSPF-1 FRRIB:   Prefix priority is lower than cfg threshold

Same problem, let’s try a /31:

R5(config)#interface GigabitEthernet 1
R5(config-if)#ip address 55.55.55.55 255.255.255.254
OSPF-1 FRRIB: Add to LRIB repair path 55.55.55.54/255.255.255.254 via neighbor 5.5.5.5, area 0, type Intra, D(N,D)=1, ext2 metric 0 
OSPF-1 FRRIB:   Prefix priority is lower than cfg threshold

Same issue, I can’t configure a /32 on a Physical interface but I can on a loopback. Let’s try that /31 first:

R5(config)#interface Loopback 1
R5(config-if)#ip address 55.55.55.55 255.255.255.254
R5(config-if)#ip ospf network point-to-point
OSPF-1 FRRIB: Add to LRIB repair path 55.55.55.54/255.255.255.254 via neighbor 5.5.5.5, area 0, type Intra, D(N,D)=1, ext2 metric 0 
OSPF-1 FRRIB:   Prefix priority is lower than cfg threshold

Same issue…no repair path. Last try:

R5(config)#interface Loopback 1
R5(config-if)#ip address 55.55.55.55 255.255.255.255

Now we have a repair path:

R1#show ip route 55.55.55.55
Routing entry for 55.55.55.55/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 192.168.15.5 on GigabitEthernet3, 00:00:23 ago
  Routing Descriptor Blocks:
  * 192.168.15.5, from 5.5.5.5, 00:00:23 ago, via GigabitEthernet3
      Route metric is 2, traffic share count is 1
      Repair Path: 3.3.3.3, via MPLS-Remote-Lfa1

So it seems that with prefix-priority high, only /32 prefixes get a repair path. The debug message tells me that we should somehow be able to set a threshold but I’m unable to do so on my router:

R1#show version 
Cisco IOS XE Software, Version 16.06.01
Cisco IOS Software [Everest], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.6.1, RELEASE SOFTWARE (fc2)

It seems that on Cisco IOS XE, it means that only /32 prefixes get a backup path since I can’t configure a threshold. On other platforms and/or IOS versions this might be different.

Hope this helps!

Rene

1 Like