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

Hello,
The Cisco documentation states the below regarding the High and Low options:
Low priority specifies that all prefixes have the same eligibility for protection. High priority specifies that only high-priority prefixes are protected.
You have mentioned above that OSPF treats loopback and /32 prefixes with higher priority, calculating an LFA for these a bit earlier than other prefixes which contradicts the Cisco documentation.
I am a little confused :roll_eyes:
Regards,
Kamal

Hello Kamal

You are absolutely right, I found the same documentation stating that. However, I have also found this documentation supporting what @ReneMolenaar said in the lesson.


I will differ the issue to Rene to clarify.

Thanks very much for catching that!!

Laz

The subnets shown on the network topologies for this lesson are not correct.

1 Like

Hello Mark

You are absolutely correct, thank’s for catching that. I’ll let @ReneMolenaar know to correct the values…

Thanks once again!

Laz

Thanks Mark, just fixed this.

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

Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.6(3)M2, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright © 1986-2017 by Cisco Systems, Inc.
Compiled Wed 29-Mar-17 14:05 by prod_rel_team

Do you have an idea ?

R1(config-router)#fast-reroute per-prefix enable area 0 prefix-priority low
 ^
% Invalid input detected at '^' marker.

i solved it
IOSv doesnt support
IOS XE Release 3S support
i changed the router
now i use CSR1000v

1 Like

Hello Bahri

Thanks for sharing your solution with us!

Laz

thank you very much your reply

Laz

1 Like

Thank you very much for taking the time to look at this.

Could you please elaborate more on what means “LFA coverage on an interface”?
Say, we execute “show ip ospf fast-reroute prefix-summary” and we get this statistics per interface.
It’s quite confusing though. What means “100% of prefixes are protected on an interface”? Whose prefixes? All prefixes that are being kept in ospf database of a given router? In some labs I’ve seen tweaking cost value on some links to make this LSA coverage = 100% for an interface. In Cisco docs there’s some “madness” with several inequalities. This is one of the most complicated topics in the whole CCIE blueprint probably.

Hello Dmiry

Cisco’s documentation about this command states the following:

The following example displays information about prefixes that are protected by the OSPFv2 loop-free alternate FRR feature. It displays information on the number of prefixes by area and by priority (high or low) and how many are protected, that is, have repair paths configured.

Taken from this command reference document:

So the percentage is a percentage of the prefixes of that area that are protected via that interface. That interface has a directly ready alternate route configured for X% of the routes in the OSPF area.

I hope this has been helpful!

Laz

Hello,

I have a question related to the node protected scenario. How does R1 know that R3 routes the traffic for 5.5.5.5/32 via R2 too (so when R2 fails, the best path fails for both R1 and R3 and R3 has to re-run the SPF)? As far as I know…R1 sees the destinations from his point of view.

Many thanks,
Stefanita

Hello Staut

Remember that OSPF is a link state routing protocol. One of the characteristics of a link state protocol is that it has a full picture of the network’s topology, including costs of particular links. This information is enough for a router, when node protection as a tie breaker is enabled, to know what the next hop of another router will be to reach a particular destination. If that next hop is the same as the primary next hop for the particular destination, then the node protection tie breaker kicks in and chooses another route as the repair route.

I hope this has been helpful!

Laz

1 Like

Many thanks! I forgot that OSPF keeps the topology table besides the routing table.

1 Like

Is it beneficial to have OSPF remote LFA FRR considering the overhead of configuring LDP everywhere in network ? Is it really used practically ? Any known use case?

Hello Madhu

I personally haven’t seen OSPF LFA FRR implemented in a production network, however, there are many situations where it is beneficial, even with the substantial overhead involved in its configuration. Imagine a large corporate network where the headquarters is composed of five or six buildings in a campus setup with 3500 employees. Imagine also several branch locations, say 5 or 10 throughout the country each with at least 500 employees. Also, imagine that this corporate network relies on OSPF for routing.

Now such a network, providing network services to over 8000 employees across multiple sites will have hundreds, if not more subnets, with real-time services like VoIP and video conferencing that require continuous routing between these subnets. Additional services such as financial transactions that are sensitive to real-time fluctuations in network availability may also exist on the network.

Now there are literally thousands of such organizations throughout the world, and there are many that may have even larger infrastructures. For such organizations, it is imperative that voice/video/financial transaction communications have the utmost redundancy and resiliency, especially if these operations are mission critical to their business. A network failure where OSPF must rerun SPF may cause hundreds of phone or video conferences to go off line, causing them to have to redial and reconnect. Financial transactions will delay causing a possible change in their results.

So for such requirements, it is not unusual to require the implementation of LFA FRR.

I hope this has been helpful!

Laz

excuse but i don’t understand the following command what exactly do:
R1(config-router)#fast-reroute per-prefix tie-break node-protecting required index 5

you said:
Let’s enable node protecting and change the priority to the lowest value of all currently active tie breakers
and you show:

*>  5.5.5.5/32, Intra, cost 5, area 0
     SPF Instance 13, age 00:18:13
     Flags: RIB, HiPrio
      via 192.168.12.2, GigabitEthernet2 label 1048578
       Flags: RIB
       LSA: 1/5.5.5.5/5.5.5.5
      repair path via 192.168.14.4, GigabitEthernet4 label 1048578, cost 9
       Flags: RIB, Repair, IntfDj, BcastDj, NodeProt
       LSA: 1/5.5.5.5/5.5.5.5
      repair path via 192.168.13.3, GigabitEthernet3, cost 7
       Flags: Ignore, Repair, IntfDj, BcastDj, Downstr
       LSA: 1/5.5.5.5/5.5.5.5

the cost remain 9 for repair path via 192.168.14.4 and cost remain 7 for repair path via 192.168.13.3… i don’t understand

Hello Andrea

The statement:

refers to the priorities that are given to the tie breakers. Remember the following in the lesson?

R1#show running-config all | incl break
 fast-reroute per-prefix tie-break primary-path index 10
 fast-reroute per-prefix tie-break interface-disjoint index 20
 fast-reroute per-prefix tie-break lowest-metric index 30
 fast-reroute per-prefix tie-break linecard-disjoint index 40
 fast-reroute per-prefix tie-break broadcast-interface-disjoint index 50

Here Rene is showing the priorities that are given to the tie breakers, which are shown at the end of each line. Originally, node protection is not included by default. But with the fast-reroute command, Rene assigns a priority to the tiebreaker of 5. This priority is the lowest value of all currently active tie breakers.

These changes do not actually change the OSPF cost of the repair paths. What it does do is it changes the way the paths are evaluated. That results in OSPF preferring router 4 with a cost of 9 over router 3 with a cost of 7 as the next repair path, simply because R3 has the same next hop as R1 originally did.

I hope this has been helpful!

Laz

1 Like