EIGRP Part 3: Why feasible successor is a lie and won’t save you

Introduction

We already know about feasible successor from other post, as one of the best features that EIGRP has because it helps for fast path transition to a new path once the main path is down.

Feasible successor has some caveats: for example, the feasible successor stays in the EIGRP topology table but is not installed in the RIB or FIB (aka CEF) until is promoted to a successor.

As you remember successors are loop free path/s that are currently forwarding traffic to a destination prefix, if we have several successors, we can have equal or unequal load balancing.

Probably you had read more than once that if we have a feasible successor in the topology then we are good to go, nothing to worry if a route fails.

If there is not feasible successor, and the successor path goes down then we go into Active and we send Queries to nearby neighbors asking for an alternative route, and in the meantime, we are not forwarding traffic until we get a reply from all the neighbors.

However even with a feasible successor in the topology, there are cases where we will drop traffic and we will go into Active, asking neighbors for an alternate path with Queries.

What if Link from R7 to R2 goes down? Here R2 is our best path to destination.

Let’s see how in this example before link failure, let’s come back to route 88.88.88.88, command used is show ip eigrp topology all-links

Best path(successor) is via R2, eth0/2 as it has the lowest CD 269088.

Here the FD is 269088, and the only single feasible successor is via eth0/3 with a RD of 269088.

Direct link between R7 and R2 goes down and then after the 15 secs hold time the neighbor will be declared down (with BFD will be faster). We will drop packets for 15 secs until we realize that the neighbor is down.

After we declare the neighbor down via normal hold time or BFD fast detection, what will happen is:

1. Interface to active successor was lost(shutdown), so EIGRP will look into the topology table for the best path to destination.
2. The best path cost is via eth0/1, but this doesn’t match the feasibility condition!
3. EIGRP cannot assure that this path isn’t loop free, so actually it send queries to all the neighbors to ask for an alternative path. Route goes into Active state!
4. Updates from neighbors have a higher cost that from R7 point of view cost, so R7 finally determines that the best path to 88.88.88.88 is via eth0/1.
5. Now R7 updates the new FD as the cost of the best path via eth0/1 which is 550432 and that is our new FD.

Note: This is called diffused computation in EIGRP, because we go into Active and we have to use DUAL.

Notice it evaluates the feasible successor with RD 259872 but it realizes that the best path cost is actually via 1.71.0.1 metric 550432(which is not a feasible sucesor). Hence it says “not found Dmin”, meaning is not the best metric.

After resolving the best path using DUAL, the new topology view is as such, after we received all the queries and the route go Passive state. Now with a new FD as the best current cost 550432 via eth0/1 R1:

New sucessor is via Eth0/1 now, and we have a new feasible succesor via eth0/3.

Do realize that R3 via eth0/3 was feasible successor all the time, but it was never promoted to a successor!!

This is because EIGRP first try to find the best path(least cost) and then it will check if it complies with the feasibility condition.

What if link between R1 – R8 goes down after?

Before shutting down looks like:

1 successor via Eth0/1, 1 feasible successor now via 0/3

Notice that in the RIB we only have the single successor via eth0/1, and not the FS which is via 0/3

Now after we shut the next successor via R1-R8 link, what will happen is we will look into the topology table and find the best path cost which will be via eth 0/3.

But however, compared with last event now the best path via 0/3 is a feasible successor for which the EIGRP won’t go into Active state andwill install this route into the RIB/FIB table.

This is called local computation; we stay Passive and don’t go into Active sending Queries.

See how we receive a query from R1 via 1.71.0.1 asking us if we have a path to 88.88.88.88 since we lost link R1 to R8. We send a reply to R1 1.71.0.1 sending we found a feasible successor via 1.73.0.3.

We found that best path cost complies with FS condition (found Dmin in the picture), and then we just install the route and don’t go into Active for an alternative route.

Notice three things about this last section:

• First, if you compare with the previous debug now we have “found Dmin” which means the next best path is a feasible successor.
• The second thing is that we immediately install the route via 1.73.0.3 eth0/3 and we updated our neighbors about that. Here we don’t go Active and send queries.
• FD kept the best value 550432, as it is a historic record of the best path cost since the last Active sate. We will only update the FD when we go into Active. This time we stayed in Passive state.

In this case the feasible successor R3 via eth0/3 was promoted to successor!

Conclusion

We have to be careful with the rules about installing the feasible successor into the RIB and FIB, and remember that all protocols goal is to find the lowest cost path.

I hope this was an interesting article to see that feasible successor lies.

Did you know about this?