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

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:

I hope this has been helpful!

Laz

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
obrĂĄzok

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 :smiley:
obrĂĄzok

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

Hello David

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.

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


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:
image

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
image

image

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 :slight_smile:

Rene

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.

1 Like