Why Your VPN Backup Is Not an EIGRP Feasible Successor

A second tunnel comes up, the routing table still shows one path, and the obvious conclusion is that the protocol has not noticed. Usually it noticed and declined. EIGRP installs a backup only when it passes a specific loop-free test, and a tunnel being up says nothing about whether the neighbour's reported distance passes it. That distinction is the whole answer, and it is arithmetic rather than a timer.

The condition, stated exactly

RFC 7868 defines the feasibility condition as a sufficient check for a neighbour's loop-free path: the neighbour's reported distance for a destination must be strictly less than the local feasible distance. Strictly. Not less than or equal.

That single inequality is what makes an alternate a feasible successor. Everything else here is bookkeeping around it.

Two distances with different jobs

The reported distance is what the neighbour advertises for the destination. The feasible distance is a record of the least-known total metric since the last ACTIVE-to-PASSIVE transition, which is why it can differ from the current best path's metric. Mixing those two up produces confident wrong conclusions.

In an operational display several distance-looking columns sit side by side. Read the header of the column you are using, and remember that a neighbour's full computed path metric is not the same quantity as the distance it reported to you.

One worked comparison

Take a declared example with a feasible distance of 1,000. A neighbour reporting 900 passes the test and can become a feasible successor. A neighbour reporting 1,000 fails it, because the condition is a strict inequality and equality is not enough.

Those numbers are arithmetic, not link speeds. Do not read them as a prediction about any particular router or as a recommended metric.

Detection is not eligibility

A mechanism can notice a dead peer quickly while EIGRP still has no eligible replacement. Noticing is one stage; coordinated route computation is another, and it starts only when no feasible successor exists. Failing the condition does not prove the alternate is physically looped. It means the local shortcut test did not establish the guarantee, so the computation has to handle the result.

Shortening a liveness timer cannot create reachability that was never there, and changing a configured bandwidth or delay value is not a measurement of capacity.

Read the fields, then test the application

Record the destination, the current successor, the candidate neighbour, its reported distance, the feasible distance and the resulting route state. show ip eigrp topology 10.10.10.0/24 gives you most of that for a single prefix. Then tie the decision to the tunnel path that actually carries the next hop, because the routing table and the tunnel table can disagree about which interface is in use.

Under an approved observation, follow three things separately: detection, route selection and the application's own recovery. That sequence tells you whether the missing piece is an eligible backup, the VPN path underneath, or the workload reconnecting, instead of assuming every slow recovery needs another timer.

The useful habit is to check the inequality before touching anything else. It takes one command and it settles the argument.