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

Lessons Discussion
#4

Hi Laz ,
Thanks for your valuable reply .
I cant understand the tie breakers . It will check one by one like BGP attribute do ??

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

Could you please help me to understand clearly ?

br//zaman

#5

Hello Zaman

The tie breakers will be checked based on the number found after the index keyword. That number is essentially a priority index. The lower the number, the more important the attribute. So the order the attributes will be checked will be in ascending order of the index number.

Each tie breaker will eliminate paths with specific attributes. The attributes indicated in your example eliminate the following paths:

Primary-path—Eliminates candidates that are not ECMPs
Interface-disjoint—Eliminates candidates sharing the same interface with the protected path
Lowest-metric — Eliminates the path with the lowest metric
Linecard-disjoint—Eliminates candidates sharing the same linecard with the protected path
Broadcast-interface-disjoint — Eliminates candidates sharing the same interface and the broadcast network connected to it

You can find more info at this Cisco documentation.

I hope this has been helpful!

Laz

#6

Hello Rene,

Great lesson as always and very helpful to understand. Please let me know what router and IOS version I can use to test in GNS3.

Thanks
Hamood

#7

Hello Hamood.

Using the Cisco Feature navigator, the platforms that support OSPF LFA FRR are the following:
image

The IOS versions that support it are the following:

image

Note that the IOS version are in the “S” train, that is, service providers.

In general, this is a feature that is available in higher end platform and IOS versions.

I hope this has been helpful!

Laz

#8

Hi Laz, Rene,

Great article! Thank you!

One question about design considerations for the LFA FRR - how should be future deployed in network? On all routes and using same algorithm to avoid possible loops, or just cherry picking some destinations at some routers and ensuring that algorithm you used wouldn`t cause suboptimal routing?

Also after we switched to the backup path will router still run SPF algorithm and re-calculate and install newly calculated path or it will continue using path chosen by LFA FRR? Cos if two adjustment routers use topology view of their respective neighbor to make they FRR decision but neighbor indeed is not relying on it`s own SPF calculated bestpath but on path chosen by FRR, it could possibly lead to unpredictable results.

Thanks!

#9

Hi Alexey,

The main advantage of LFA FRR is the increased convergence time so it’s probably best only to use this on routers where switching over from the primary to backup path really makes a difference, like routers forwarding VoIP traffic where the lower convergence time is important. I wouldn’t just enable this on all routers in your network.

Once it switches over to the backup path, it does run SPF to re-calculate. You can see it in action if you enable debug ip ospf fast-reroute and debug ip ospf spf.

#10

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

#11

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

#12

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

1 Like
#13

Hello Mark

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

Thanks once again!

Laz

#14

Thanks Mark, just fixed this.

#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

#16

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.
#17

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

1 Like
#18

Hello Bahri

Thanks for sharing your solution with us!

Laz

#19

thank you very much your reply

Laz

1 Like
#20

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

#21

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.

#22

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

#23

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