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

[lagapidis (Lazarus Agapidis)]

Hello Abdul

When creating a pseudo-wire, you are essentially creating a Layer 2 tunnel over a Layer 3 infrastructure. The overlay, in this case, is the Layer 2 pseudowire, while the underlay is whatever infrastructure you have that is tunneling that data, which in your case is an OSPF-routed infrastructure and MPLS.

The path that the tunneled pseudowire will take will necessarily be whatever routing behavior has been configured on that underlay. Imagine instead of two routers, you have 20 in that infrastructure between the two loopback with dozens of possible routes. Whatever the routing enabled on that underlay, that is the path that the pseudowire will take.

Now having said all of that, if you have equal cost paths, then you should see both paths being utilized equally. But this will not only depend upon the OSPF cost but also on the methodology of equal cost load balancing. This has little to do with the pseudowire configuration but more to do with how the routers are configured to perform load balancing in such cases and in particular, how the use CEF. More on this can be found at this NetworkLessons note on the subject.

Now how can you verify this? Well, you can use various methods to check this out. First check to see if both paths exist in the routing tables of the routers. If they are there, then load balancing will be applied. Secondly, you can set up an access list that will match your traffic on the interfaces and use the log keyword. That way, you can track the number of packets that take a particular path. You can also use Wireshark to ensure that you see pseudowire packets arriving via both paths.

For more info on pseudowire, take a look at this lesson:

L2TPv3 (Layer 2 Tunnel Protocol Version 3)

I hope this has been helpful!

Laz

[davidilles]

Hello, everyone!

I don’t know if this is a CML bug but take a look at this:

Here’s my topology. I’ve added the total cost to reach the 5.5.5.5/32 network on the right for each link R1 has.

Here are my tiebreakers

The top link is the best path since it has the lowest cost. Now, using LFA, shouldn’t either G3 or G4 be picked as the backup path because of the primary-path tiebreaker? Because that says that an LFA which is a part of ECMP should be preferred, so shouldn’t this ditch the path through R3? Because for some reason, it is picking the path through R3

Then I’ve tried a different topology with the interface-disjoint tiebreaker

After shutting down R2’s G0/0 interface, it didn’t install the LFA even though it did specify it in the output before I shutdown that interface.

Any ideas what am I doing wrong here?

Thank you all!
David

[lagapidis (Lazarus Agapidis)]

Hello David

@davidilles

The top link is the best path since it has the lowest cost. Now, using LFA, shouldn’t either G3 or G4 be picked as the backup path because of the primary-path tiebreaker? Because that says that an LFA which is a part of ECMP should be preferred, so shouldn’t this ditch the path through R3? Because for some reason, it is picking the path through R3

This is expected behavior. Remember that the list of characteristics that are being compared are tiebreakers. But to have the tiebreakers kick in, you must first have a tie. In your scenario, the best alternative is the path via R3, which has a cost of 4. There is no other path that has a cost of 4. The other two paths via R4 and R6 have a cost of 5, so there is no tie.

You see, the first thing that is checked (before any tiebreakers) when applying LFA is the cost. Assuming the candidate backup path satisfies the loop-free condition, the only thing considered is cost.

Now, if your path via R3 had a cost of 5, then there would indeed be a tie, and the tiebreakers would kick in. Using the primary-path tiebreaker, it would prefer to use the ECMP option (links via R4 and R6) rather than the one via R3.

@davidilles

After shutting down R2’s G0/0 interface, it didn’t install the LFA even though it did specify it in the output before I shutdown that interface.

This is indeed behavior contrary to the way the LFA functions. If you have a declared repair path via 10.0.0.5 and once the deadtime interval expires on the R1 R2 adjacency, it installs a next hop of 192.168.1.3, something else is going on in the meantime. Something else may have caused the SPF algorithm to kick in and reevaluate the next hop. Without LFA, based on the costs and the topology, what next hop would OSFP have chosen? If it is indeed the 192.168.1.3 next hop, then it may be that once LFA kicked in, something else triggered the SPF algorithm changing the next hop. Can you do some more investigation with related debugs to see how this took place?

I hope this has been helpful!

Laz

[rivc1982 (Christopher R)]

Trying this out based on the topology above. My issue is that I am trying to favor an ECMP path over a lower cost link by using a tie breaker of primary-path as the only tie breaker. Destination is 6.6.6.6 on R6. Weird thing to note (#1) - If I set it to required (mandatory), the output of the show ip ospf RIB does not list the ECMP G3 and G4 as loadshare. Once I remove the required option it lists them appropriately in the show ip ospf rib 6.6.6.6 output.
Weird thing to note (#2) - Even after the output of the show ip ospf RIB command lists an ECMP path over the lower cost as an LFA, it still uses the lower cost path after shutting down the primary path G1 on CSR router.

This is the CSR router FRR configuration:

All seems to look well with it choosing to use a ECMP link as a repair path due to my specifying it as my only tie breaker:

But when I shut my primary path link G1 down, it still changes and chooses the lower cost path via R2-3 on interface G2 (as seen below) which it said it would ignore in the output above.

In reference to weird thing to note item #1: This is what the OSPF RIB looks like when I use the below command

[ReneMolenaar]

Hi Christopher,

Sorry for the late reply. Looking at this output, I can’t really tell why this happens. Did you try it on both IOSv and a CSR1000v?

I’d have to lab it up to see what is happening. It’s probably not a quick lab to do and I’m limited with my time at the moment. If anyone else has seen this before, please share

Rene

[rivc1982 (Christopher R)]

No worries. I have come to the conclusion that this is more a hardware dependent technology that I just can’t fully virtualize. I feel I have a really good understanding of it and am comfortable with it.

Thanks for following up.

[bnmikica (Mikica M)]

Hi Rene,

Thank you for the great lesson!

Can you please explain, why in R5 configuration under interfaces GigabitEthernet2, GigabitEthernet3, GigabitEthernet4 are configured ospf cost values of 1,10,10 respectively? Probably because of symmetric routing?

[ReneMolenaar]

Hi @bnmikica ,

I understand the confusion. Those ip ospf cost commands on the Gigabit interfaces of R5 don’t have any effect because we only look at routing from R1 > R5. I just got rid of those and replaced them with the same cost as R2, R3, and R4 use. It’s not needed, but we’ll keep it symmetric.

I also updated the diagrams and added some extra start/final configs.

Rene

[davidilles]

Hello, everyone.

If we follow the default algorithm:

• 10 srlg

• 20 primary-path

• 30 interface-disjoint

• 40 lowest-metric

• 50 linecard-disjoint

• 60 node-protecting

• 70 broadcast-interface-disjoint

• 256 load-sharing

Two questions.

1. Under normal circumstances, would broadcast-interface-disjoint ever be used to evaluate the repair path? There is already the interface-disjoint which prefers candidates that use a different interface which should eliminate 70 altogether, or not? If there’s a candidate route on a different interface, 30 breaks the tie. If there are only candidate routes on the same interface, 30 won’t break the tie and the tiebreakers will continue further down. Once it reaches 70, that also won’t break the tie if the candidate routes only exist out of that same interface.
2. About primary-path. This gives preference to paths that are a part of ECMP with the primary path. Say that I enable LFA on a router that has three ECMP paths to reach a network, like 1.1.1.1/32. If I enable LFA, it will precompute a repair path for all those 3 ECMPs. Will the convergence be any faster in this case? I mean, even if LFA wasnt enabled, if one of the paths went down, the other 2 would still be able to forward traffic since they were computed and installed into the CEF table

Thank you.
David

[lagapidis (Lazarus Agapidis)]

Hello David

@davidilles

Under normal circumstances, would broadcast-interface-disjoint ever be used to evaluate the repair path? There is already the interface-disjoint which prefers candidates that use a different interface which should eliminate 70 altogether, or not?

No, broadcast-interface-disjoint is not redundant. While there is overlap, they serve distinct purposes:

• interface-disjoint (priority 30): Prefers LFA candidates that use a different local outgoing interface than the primary path (e.g., Gi0/0 vs Gi0/1).
• broadcast-interface-disjoint (priority 70): Prefers candidates that avoid the same broadcast network/L2 segment as the primary path’s first hop.

How can both operate at the same time and complement each other? On broadcast/multi-access networks, multiple OSPF neighbors can exist on the same broadcast segment but appear as different logical interfaces to the router. Consider this scenarios:

Multiple neighbors on same LAN

• Router connects to a switch via Gi0/0
• Primary path exits Gi0/0 to Neighbor A on VLAN 10
• Multiple candidates also exit Gi0/0 but to different neighbors on the same LAN

Here, priority 30 cannot break the tie (same interface), but priority 70 can prefer alternates that reach the destination via a completely different broadcast segment, avoiding fate-sharing if the LAN or switch fails.

So broadcast-interface-disjoint protects against shared L2/broadcast segment failures that interface-disjoint cannot detect. In simple point-to-point topologies, you’re right that priority 70 rarely matters, but in complex enterprise/SP networks, it provides valuable additional failure isolation.

@davidilles

About primary-path. This gives preference to paths that are a part of ECMP with the primary path. Say that I enable LFA on a router that has three ECMP paths to reach a network, like 1.1.1.1/32. If I enable LFA, it will precompute a repair path for all those 3 ECMPs. Will the convergence be any faster in this case?

Hmm, the answer to this is probably scenario-dependent. The primary-path tiebreaker (priority 20) prefers LFA repair paths that are also members of the pre-failure ECMP set. If an alternate is already a primary next-hop (already in FIB/CEF and load-balancing), it can serve as an immediate repair. Arguably, for a single-link ECMP failure, the benefit of LFA is probably minimal.

But for more complex failures it can be of benefit. For example, if you have all ECMP paths transit the same next hop node, and that node fails, you must wait for the SPF to kick in. Or if multiple ECMP next hops fail simultaneously due to a shared link, again, you need to rerun the SPF. In such cases, LFA does guarantee sub-second convergence regardless of the topology. Therefore, relying solely on ECMP is insufficient.

So, for particularly more complex scenarios, LFA does indeed provide benefit, enabling immediate failover without the need to wait for SPF convergence.

I hope this has been helpful!

Laz