This topic is to discuss the following lesson:
Hi Rene,
Very nice lesson. You are the BOSS as always!!
So can we deploy LFA-FRR for Inter-Area/External Prefix ?? Thx
br//zaman
Hello Zaman
LFA-FFR for OSPF is defined in RFC 5286. According to this RFC there are several situations where LFA-FRR should not be used for Inter-area and external routes. For example, on Page 7 of the RFC it states the situations where inter-area routes and external routes should not use LFAs.
I hope this has been helpful!
Laz
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
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
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
Hello Hamood.
Using the Cisco Feature navigator, the platforms that support OSPF LFA FRR are the following:
The IOS versions that support it are the following:
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
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!
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.
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 
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 
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 onLet’s enable prefix-priority high:
R1(config)#router ospf 1
R1(config-router)#fast-reroute per-prefix enable area 0 prefix-priority highAnd 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 0Let’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 1It 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 thresholdSo 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.0Still 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.0OSPF-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.254OSPF-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-pointOSPF-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.255Now 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-Lfa1So 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
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.