DUAL relies on three closely related concepts to decide which route goes in the routing table and which routes stand ready as instant backups. This guide defines each one precisely, works through a real Feasibility Condition check using the same topology and numbers established in How to Calculate EIGRP Metric, and covers how OSPF’s fundamentally different approach handles the same underlying problem.
Successor
It is the best route to a destination network — the single route EIGRP actually installs in the routing table and uses to forward traffic. A successor is selected based on which neighbor offers the lowest Feasible Distance: the local router’s own total computed cost to the destination via that specific neighbor, which combines the neighbor’s reported cost with the cost of reaching that neighbor in the first place.
Using the topology and calculation from How to Calculate EIGRP Metric: R1’s best path to the 192.168.2.0/24 network is through R3, with a Feasible Distance of 258,816 — the exact metric derived in that worked example. R3’s Gig0/1 interface, at IP address 10.10.10.2, is the actual next hop this route uses.
Feasible Distance (FD)
The Feasible Distance is the lowest calculated metric to reach a destination network via the current successor. It’s the value shown as the second number inside the brackets in show ip route output — for R1’s route above, that’s the 258816 in [90/258816]. Feasible Distance is sometimes referred to simply as “the metric” for a route, since it’s the number EIGRP actually uses to compare and rank candidate paths.
Feasible Successor (FS) and the Feasibility Condition
A Feasible Successor is a backup route to the same destination as the successor — a route that can be promoted immediately if the successor fails, without triggering any recalculation or Query/Reply exchange. This is possible because a FS has already been mathematically verified as loop-free at the moment it was added to the topology table, not just checked at the moment of failure.
That verification is the Feasibility Condition (FC): a candidate route qualifies as a feasible successor only if the neighbor’s Reported Distance (RD) — the metric that neighbor itself reports for reaching the destination, from its own perspective — is strictly less than the current successor’s Feasible Distance.
Checking Whether R2 Qualifies as a FS
With R3 already established as R1’s successor for 192.168.2.0/24 (Feasible Distance: 258,816), consider whether R2 — which also has a path to that same network — could serve as a feasible successor.
Suppose R2 reports a Reported Distance of 204,800 for reaching 192.168.2.0/24 from its own perspective. Comparing this against R3’s Feasible Distance:
Is R2's RD < R3's FD?
204,800 < 258,816 → Yes, the Feasibility Condition is satisfied.Since 204,800 is less than 258,816, R2’s route passes the Feasibility Condition and qualifies as a FS. This route gets stored in the topology table alongside the successor, ready for immediate use.
Now consider a different scenario: suppose instead R2 reported a Reported Distance of 300,000:
Is R2's RD < R3's FD?
300,000 < 258,816 → No, the Feasibility Condition fails.In this case, R2’s route does not qualify as a FS, even though it’s still a genuinely usable alternate path to the destination. It remains visible in the topology table only with the show ip eigrp topology all-links command, but DUAL won’t treat it as an instantly-promotable backup — if the successor failed, this path would still need to go through the full Query/Reply process before being used, since it hasn’t been pre-verified as loop-free.
Why the Feasibility Condition Matters for Loop Prevention
The Feasibility Condition isn’t an arbitrary threshold — it exists specifically to guarantee that a feasible successor can never route traffic back through the local router itself. If a neighbor’s Reported Distance were allowed to be equal to or greater than the local router’s Feasible Distance, there would be a real possibility that neighbor is actually relying on the local router (directly or indirectly) to reach that same destination — accepting that route as a backup could then create a loop.
Requiring the Reported Distance to be strictly lower rules this out mathematically, which is exactly what lets DUAL promote a feasible successor instantly without any additional verification at the moment of failure. This is the same underlying guarantee covered from a slightly different angle in What Is DUAL? — the Feasibility Condition is the specific mathematical rule that makes DUAL’s broader loop-free promise actually hold.
Designing for Feasible Successors
Since having a feasible successor available is what determines whether a route converges near-instantly or has to go through the slower Query/Reply process, it’s a factor worth considering deliberately in network design rather than treating as pure luck of the topology. A few practical implications:
Redundant links don’t automatically produce feasible successors. Two physical paths to the same destination only translate into a usable feasible successor relationship if the actual computed metrics satisfy the Feasibility Condition. A redundant link with a much higher metric than the primary path may never qualify, even though it’s genuinely usable as a last-resort path once DUAL goes through the Active-state process.
Symmetric, evenly-costed topologies tend to produce fewer feasible successors than asymmetric ones. Somewhat counterintuitively, a network where every path to a destination has a very similar metric is less likely to satisfy the strict Feasibility Condition inequality than one with a clear primary path and a meaningfully lower-cost secondary path relative to a specific neighbor’s reported distance.
Checking for feasible successors on critical paths is a worthwhile audit step. For destinations where fast failover genuinely matters — a data center interconnect, a path carrying voice traffic — explicitly checking show ip eigrp topology for a confirmed feasible successor, rather than assuming redundancy alone guarantees fast convergence, catches a real gap before it becomes a production incident.
Common Mistakes
Comparing Reported Distance against the wrong value. The Feasibility Condition specifically compares a candidate’s RD against the successor’s Feasible Distance — not against the candidate’s own FD, and not against any other neighbor’s values. Mixing these up produces an incorrect pass/fail result even when the underlying numbers were read correctly.
Assuming a higher-bandwidth or seemingly “better” path automatically qualifies as a feasible successor. As the worked example shows, qualification depends entirely on the Reported Distance versus Feasible Distance comparison — a path that looks intuitively better on paper can still fail the Feasibility Condition if the actual numbers don’t satisfy the strict-inequality test.
Forgetting the inequality must be strict. A candidate’s Reported Distance equal to the successor’s Feasible Distance does not satisfy the Feasibility Condition — it must be strictly less than, not less than or equal to. This detail matters in edge cases where two paths happen to compute to very close metrics.
Assuming show ip eigrp topology shows every route in the topology table. By default, it only shows the successor and any feasible successors. Routes that exist but failed the Feasibility Condition are invisible without adding all-links, which can make it look like fewer paths exist than actually do.
How This Compares to OSPF’s Approach
It’s worth briefly noting how differently OSPF handles the equivalent problem. OSPF doesn’t have a direct analog to feasible successors at all — it doesn’t pre-verify backup paths the way EIGRP’s Feasibility Condition does. Instead, OSPF maintains a complete link-state database and recalculates the shortest path using SPF whenever the topology changes, regardless of whether a backup was somehow already known to be safe.
This is a genuine architectural difference between the two protocols: EIGRP trades some computational effort up front (checking the Feasibility Condition as routes are learned) for potentially much faster failover later, while OSPF’s link-state approach means every router already has the full topology needed to recompute a new best path quickly, without needing a separate pre-verification step for backups specifically. Neither approach is strictly superior — they simply reflect the different underlying philosophies of a distance-vector-family protocol pushed toward faster convergence versus a link-state protocol built around maintaining a shared topology view from the start.
Verifying Successor and Feasible Successor Status
Router# show ip eigrp topologyShows the successor and any feasible successors for every destination — this is the default view, and any route lacking a feasible successor simply won’t show a second entry.
Router# show ip eigrp topology all-linksReveals every candidate route in the topology table, including ones that failed the Feasibility Condition and therefore aren’t treated as feasible successors — useful for understanding why a specific destination has no feasible successor available.
Router# show ip eigrp topology 192.168.2.0/24Shows detailed information for one specific destination, including the exact Feasible Distance and, for any qualifying entries, the Reported Distance — the most direct way to confirm a Feasibility Condition calculation by hand against the router’s actual computed values.
Frequently Asked Questions
What’s the difference between Feasible Distance and Reported Distance?
Feasible Distance is the local router’s own total computed cost to a destination via a specific path — the number that actually goes into the routing table. Reported Distance is the cost a neighbor reports for reaching that same destination from its own perspective, used specifically as an input to the Feasibility Condition test.
Can a route have more than one feasible successor?
Yes. If multiple neighbors each independently satisfy the Feasibility Condition against the current successor’s Feasible Distance, all of them are retained as feasible successors simultaneously, giving DUAL more than one instantly available backup option.
Why does a route without a feasible successor still show as reachable in the routing table?
The successor route itself is still fully valid and installed — lacking a feasible successor only affects what happens if that successor later fails. Without one, a failure forces the slower Active-state Query/Reply process rather than an instant promotion.
Does a route failing the Feasibility Condition mean it’s a bad route?
Not necessarily. A route can be a perfectly usable, loop-free path in reality while still failing the Feasibility Condition, simply because DUAL couldn’t mathematically guarantee its loop-freedom using only locally available information. Failing the condition just means it isn’t treated as an instantly promotable backup — it can still become the new successor after a normal Query/Reply exchange confirms it’s usable.
How can I check the exact numbers behind a Feasibility Condition decision on a live router?
show ip eigrp topology <network> shows the Feasible Distance for the destination directly. Comparing that against a specific neighbor’s Reported Distance — visible via show ip eigrp topology all-links for routes that didn’t qualify, or in the standard topology output for ones that did — lets you verify the Feasibility Condition math by hand exactly as shown in the worked examples above.
Why does R1’s route to 192.168.2.0/24 go through R3’s Gig0/1 interface specifically?
Because that’s the interface EIGRP has determined offers the lowest Feasible Distance to that destination based on the topology’s actual bandwidth and delay values, worked through step by step in How to Calculate EIGRP Metric. The next-hop IP address (10.10.10.2) simply identifies which specific interface on R3 the route actually uses to forward traffic.
Conclusion
Successor, Feasible Distance, and Feasible Successor describe three connected pieces of the same decision: which route actually gets used right now, what that route costs, and which alternate routes are already pre-verified as safe to switch to instantly. The Feasibility Condition — comparing a candidate’s Reported Distance against the successor’s Feasible Distance — is what makes that pre-verification possible, and understanding it precisely is what separates a surface-level grasp of EIGRP from being able to predict exactly how a specific network will behave when a link fails.
