EIGRP DUAL: How Feasible Distance and Advertised Distance Decide Whether You Converge in Milliseconds or Minutes

EIGRP converges in milliseconds when it has a feasible successor and in seconds — occasionally minutes — when it does not. That single distinction is the whole reason DUAL exists and the reason four terms are worth understanding precisely rather than approximately. Advertised distance is what a neighbour tells you its cost to a destination is. Feasible distance is the lowest cost you have ever computed to that destination since it last stabilised. A successor is the neighbour on your best path. A feasible successor is a neighbour whose advertised distance is strictly less than your feasible distance, which proves it cannot be routing through you and therefore makes it safe to use immediately without asking anyone.

The subtlety that catches people is that feasible distance is historical, not current. It is the minimum ever recorded, not simply today's best metric, and it only resets when the route goes active. That design choice is what makes the feasibility condition safe: if a neighbour's cost to a destination is lower than the best cost you have ever achieved, then your own path cannot be part of the neighbour's path, because that would require the neighbour's cost to exceed yours. The condition is sufficient for loop freedom but not necessary, which means EIGRP sometimes rejects a perfectly good backup path. That is a deliberate trade — instant convergence when the test passes, in exchange for occasionally going active when a usable alternative existed.

This article works through DUAL from the four terms to the failure modes. Section one defines AD, FD, successor and feasible successor with worked numbers from a real topology table. Section two explains why the feasibility condition guarantees loop freedom and why it is conservative. Section three follows a route through the active process — query, reply, and the stuck-in-active timer. Section four is topology-table reading and verification, including the output that tells you why a candidate was rejected. Section five covers the design mistakes that turn a fast protocol into a slow one: unbounded query scope, missing feasible successors, and the summarisation choices that fix both.

 

What Are AD, FD, Successor and Feasible Successor?

How do the four terms relate to each other?

Advertised distance, also called reported distance, is the metric a neighbour advertises for a destination — its own cost to reach it, excluding the link between you. Total metric is that advertised distance plus the cost of the link to that neighbour. Feasible distance is the lowest total metric this router has ever computed for the destination since it last went active; it is a historical minimum, not the current best. The successor is the neighbour offering the lowest total metric, and its path is what goes into the routing table. A feasible successor is any other neighbour whose advertised distance is strictly less than the feasible distance — a backup that DUAL can install immediately without querying anyone.

A Deeper Dive into the Four Quantities

Reading them out of the topology table

The topology table prints the two numbers in a parenthesised pair. The first is the total metric through that neighbour; the second is that neighbour's advertised distance. Getting the order right is the whole skill, because the feasibility test uses the second number and almost every explanation people carry in their heads uses the first.

R1# show ip eigrp topology 10.9.9.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1) for 10.9.9.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
  Descriptor Blocks:
  10.0.13.3 (GigabitEthernet0/2), from 10.0.13.3, Send flag is 0x0
      Composite metric is (3072/2816), route is Internal
                            ^total  ^advertised
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 20 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
  10.0.12.2 (GigabitEthernet0/1), from 10.0.12.2, Send flag is 0x0
      Composite metric is (3072/1792), route is Internal
! ^ AD 1792 < FD 3072, so R2 is a feasible successor.

Why feasible distance is historical

FD records the minimum total metric ever computed for the destination while it has remained passive. If the successor's metric worsens — a link degrades, a delay is increased upstream — the total metric rises but FD does not rise with it. FD only increases when the route goes active and the process completes with a new, higher best path. This asymmetry is deliberate, and it is the source of both DUAL's safety and its occasional conservatism.

! FD stays at the historical minimum even as the current metric worsens
R1# show ip eigrp topology 10.9.9.0/24 | include FD|Composite
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
      Composite metric is (3328/3072), route is Internal
! ^ Current best is now 3328 but FD remains 3072. Any candidate must
!   still beat 3072 to be feasible, which is now harder than before.

The four quantities side by side

Where the metric numbers come from

With default K values the metric is a bandwidth term plus a delay term, scaled. Bandwidth uses the minimum along the entire path; delay is cumulative. That asymmetry matters for DUAL: adding a hop always increases the delay term, so a neighbour further from the destination than you almost always has a higher AD — which is exactly the property the feasibility condition exploits.

! Classic metric, default K values (K1=K3=1, K2=K4=K5=0)
!   metric = 256 x [ (10^7 / min_bandwidth_kbps) + (sum_of_delays / 10) ]
!
! For a 1 Gbps path with 20 usec total delay:
!   bandwidth term = 10^7 / 1000000 = 10
!   delay term     = 20 / 10        = 2
!   metric = 256 x (10 + 2) = 3072
!
! Check the components EIGRP is using on an interface
R1# show interfaces GigabitEthernet0/2 | include BW|DLY
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

Why Does the Feasibility Condition Guarantee a Loop-Free Path?

What is the proof, in one paragraph?

Suppose neighbour N advertises a cost to destination D that is strictly less than your feasible distance to D. If N's path to D went through you, then N's cost would equal the cost of the link from N to you plus your own cost to D. Your own cost to D is at least your feasible distance, since FD is the minimum you have ever achieved. Link costs are positive, so N's cost would have to exceed your FD. But we assumed it is strictly less. The assumption that N routes through you therefore contradicts the premise, so N cannot be routing through you, and installing N's path cannot create a loop. No coordination with any other router is required, which is why a feasible successor can be promoted instantly.

A Deeper Dive into the Condition and Its Limits

The condition is sufficient, not necessary

Every path that passes the test is loop-free. Not every loop-free path passes the test. A neighbour sitting on a completely independent path to the destination can still have an advertised distance higher than your FD — perhaps because its path is genuinely longer, or because your FD is unusually low from a previous topology. DUAL rejects it. That path may be perfectly usable, but proving so would require asking other routers, which is exactly what the active process does and exactly what the feasibility condition exists to avoid.

This is the trade at the heart of EIGRP. A local test that is fast and always safe, at the cost of sometimes going active unnecessarily. The design bet is that in a well-built topology most failures have a feasible successor available, so the slow path is rare.

! A loop-free path that fails the test - look at all-links
R1# show ip eigrp topology all-links 10.9.9.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1) for 10.9.9.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
  Descriptor Blocks:
  10.0.13.3 (Gi0/2), from 10.0.13.3, Send flag is 0x0
      Composite metric is (3072/2816), route is Internal
  10.0.12.2 (Gi0/1), from 10.0.12.2, Send flag is 0x0
      Composite metric is (3072/1792), route is Internal
  10.0.14.4 (Gi0/3), from 10.0.14.4, Send flag is 0x0
      Composite metric is (4096/3584), route is Internal
! ^ R4's AD 3584 exceeds FD 3072. Not feasible, so it is absent
!   from the plain 'show ip eigrp topology' output entirely.

Why FD is not simply the current metric

If FD tracked the current best metric upward, the proof above would break. Consider a path whose metric worsens because a downstream router increased its delay. If FD rose with it, a neighbour that is routing through you could suddenly appear feasible, because its advertised distance — which includes your inflated cost — might now fall below the new higher FD. Keeping FD pinned at the historical minimum guarantees the comparison stays conservative in the right direction.

! FD only rises through the active process, never passively
!
!   route stays Passive  -> FD holds at the minimum ever seen
!   route goes Active    -> FD is recomputed when it returns Passive
!
! Watch the transition in the EIGRP event log
R1# show ip eigrp events | include 10.9.9.0
12   14:22:31.418 Change queue emptied, entries: 1
11   14:22:31.418 Route installed: 10.9.9.0/24 10.0.12.2
10   14:22:31.417 FC not sat Dmin/RD: 4096 3584
9    14:22:31.417 Find FS for dest 10.9.9.0/24. FD is 3072, RD is 3072
! ^ 'FC not sat' = feasibility condition not satisfied, with the two
!   numbers that failed. This is the definitive diagnostic.

Split horizon, poison reverse, and what neighbours actually hear

Two behaviours shape the advertised distances you receive. Split horizon suppresses advertising a route back out the interface it was learned on, so on a point-to-point link a neighbour never hears its own path echoed. Poison reverse goes further: when a router selects a new successor through a neighbour, it advertises the route back to that neighbour with an infinite metric, explicitly stating "do not use me for this". Both exist to stop the very loops the feasibility condition also guards against, operating at the advertisement layer rather than the computation layer.

What Happens When a Route Goes Active?

What is the active process?

When a router loses its successor and has no feasible successor, it cannot prove any remaining path is loop-free on its own. It marks the route active and sends a query to every neighbour except the one it lost the route through, asking whether they have a path. Each neighbour either replies with its own distance — if it has a successor or can find one — or itself goes active and propagates the query further. The originating router cannot converge until every query has been answered. If a reply does not arrive within the active timer, three minutes by default, the route is declared stuck-in-active and the offending adjacency is reset.

A Deeper Dive into Query Propagation and SIA

The sequence, step by step

• The successor is lost — an adjacency drops, or an update arrives with an unreachable metric.
• DUAL checks the topology table for a feasible successor. If one exists, it is promoted immediately, the route never goes active, and convergence is sub-second.
• If none exists, the route enters the active state and a query is flooded to all neighbours except the one the route was lost through.
• Each receiving neighbour checks its own table. With a successor or feasible successor it replies at once. Without one it goes active itself and queries its own neighbours, excluding the querier.
• Queries stop propagating at a router that has an answer, at a router with no other neighbours, at a stub router, at a summarisation boundary, or at a distribute-list boundary.
• Replies flow back along the query tree. Only when every outstanding reply has arrived does the originator recompute, install a path, set a new FD, and return to passive.

! Catch a route in the active state
R1# show ip eigrp topology active
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia status

A  10.9.9.0/24, 0 successors, FD is Inaccessible
        1 replies, active 00:00:04, query-origin: Local origin
        via 10.0.12.2 (Infinity/Infinity), r, Q
             Remaining replies:
             via 10.0.12.2, r, GigabitEthernet0/1
! ^ 'r' = reply still outstanding from this neighbour. The route cannot
!   converge until every 'r' clears.

Stuck-in-active and the SIA-Query mechanism

The active timer defaults to three minutes. Historically, a reply that did not arrive within that window caused the router to tear down the adjacency with the silent neighbour — a blunt response that could cascade, because resetting the adjacency invalidated more routes and generated more queries. Modern EIGRP adds SIA-Query and SIA-Reply: at roughly half the active timer the router asks the silent neighbour whether it is still working on the query, and a neighbour that answers buys more time. Up to three such exchanges occur before the adjacency is reset, which distinguishes a slow neighbour from a dead one.

! The log messages, in escalation order
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.12.2 (Gi0/1) is down:
 stuck in active
!
%EIGRP-3-SIA: EIGRP-IPv4 100: Route 10.9.9.0/24 stuck-in-active state
 in EIGRP-IPv4 100. Cleaning up
!
! Tune the active timer - raising it hides the problem, lowering it
! resets adjacencies faster. Neither is the fix; query scoping is.
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  timers active-time 3
  ! 'disabled' removes the timer entirely - never do this in production
 exit-address-family

What stops a query

Query scope is the single biggest determinant of EIGRP convergence in a large network, because the originator waits for the slowest branch of the query tree. Five things bound it, and a design that uses none of them will propagate a single link failure to every router in the autonomous system.

How Do I Read the Topology Table and Verify DUAL's Decisions?

Which command answers which question?

show ip eigrp topology lists successors and feasible successors for every prefix — anything absent from it failed the feasibility test. show ip eigrp topology all-links adds the rejected paths, which is how you answer "why is there no backup". show ip eigrp topology <prefix> gives the vector metric components so you can see whether bandwidth or delay is driving the number. show ip eigrp topology active shows anything currently querying, with an r flag per outstanding reply. And show ip eigrp events is the underused one: it records the actual feasibility computations with both numbers, including the failures.

A Deeper Dive into Verification

The state line and what each field means

R1# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia status

P  10.9.9.0/24, 2 successors, FD is 3072
        via 10.0.13.3 (3072/2816), GigabitEthernet0/2
        via 10.0.12.2 (3072/1792), GigabitEthernet0/1
P  10.8.8.0/24, 1 successors, FD is 3328
        via 10.0.13.3 (3328/3072), GigabitEthernet0/2
        via 10.0.12.2 (5120/2816), GigabitEthernet0/1
! ^ For 10.8.8.0/24: R2's AD 2816 < FD 3328, so it IS a feasible
!   successor despite the much worse total metric of 5120.

Two successors on the first prefix means both paths have the identical lowest total metric and both are installed — equal-cost load balancing. On the second prefix there is one successor and one feasible successor; the feasible successor is not in the routing table unless variance is configured, but it is held ready for instant promotion.

Making a feasible successor actually carry traffic

Variance installs feasible successors whose total metric is within a multiple of the feasible distance. It is the only way EIGRP performs unequal-cost load balancing, and it only ever considers paths that already passed the feasibility test — a non-feasible path cannot be used no matter how large the variance.

! Variance 2 installs any FS whose metric is within 2 x FD
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  topology base
   variance 2
   maximum-paths 4
   ! Distribute traffic proportionally to metric, not evenly
   traffic-share balanced
  exit-af-topology
 exit-address-family
!
R1# show ip route 10.8.8.0
Routing entry for 10.8.8.0/24
  Known via "eigrp 100", distance 90, metric 3328
  Routing Descriptor Blocks:
  * 10.0.13.3, from 10.0.13.3, via GigabitEthernet0/2
      Route metric is 3328, traffic share count is 154
    10.0.12.2, from 10.0.12.2, via GigabitEthernet0/1
      Route metric is 5120, traffic share count is 100
! ^ 5120 <= 2 x 3328, so the FS is installed. Share is inversely
!   proportional to metric, not equal.

The events log, which shows the arithmetic

This is the most direct evidence available and almost nobody uses it. The EIGRP event log records each feasibility computation with the two numbers compared, so a rejected path is visible as an explicit failure rather than an absence.

R1# show ip eigrp events 1 20
Event information for AS 100:
1    14:31:02.891 Rcv update dest/nh: 10.9.9.0/24 10.0.14.4
2    14:31:02.891 Find FS for dest 10.9.9.0/24. FD is 3072, RD is 3072
3    14:31:02.891 FC not sat Dmin/RD: 4096 3584
4    14:31:02.892 Not active net/1=SH, 10.9.9.0/24
! ^ Line 3 is the answer: the feasibility condition was not satisfied
!   because the reported distance 3584 is not below the FD.
!
! Enable a larger event buffer before troubleshooting
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  eigrp event-log-size 5000
 exit-address-family

Neighbour-level verification

R1# show ip eigrp neighbors detail
EIGRP-IPv4 Neighbors for AS(100)
H  Address     Interface  Hold Uptime   SRTT  RTO   Q   Seq
                          (sec)         (ms)        Cnt Num
1  10.0.12.2   Gi0/1        13 02:14:07    4   100   0   214
   Version 23.0/2.0, Retrans: 0, Retries: 0, Prefixes: 21
   Topology-ids from peer - 0
0  10.0.13.3   Gi0/2        12 02:14:11    5   100   0   198
   Version 23.0/2.0, Retrans: 0, Retries: 0, Prefixes: 24
! Q Cnt is the queue of unsent reliable packets. Persistently non-zero
! means the neighbour is not acknowledging - a precursor to SIA.
! Rising Retrans/Retries points at packet loss on that link.

Which DUAL-Related Design Mistakes Cause SIA and Slow Convergence?

What turns a fast protocol into a slow one?

Four things. A flat autonomous system with no summarisation, so every query reaches every router and the slowest link in the network determines convergence everywhere. A hub-and-spoke topology with no stub configuration, so the hub floods queries to hundreds of spokes and waits for all of them. Redundant paths that carry no feasible successor because the metrics were never designed for it. And unreliable low-bandwidth links in the query path, where a lost query or reply is retransmitted slowly enough to hit the active timer.

A Deeper Dive into the Design Failures

Flat design with no query boundary

EIGRP has no areas, so nothing bounds a query except the mechanisms you configure. In a network of four hundred routers with contiguous but unsummarised addressing, the loss of a single access-layer prefix generates a query that traverses the entire autonomous system. Every router burns CPU, and the originator waits for the last reply from the most distant, slowest branch. The fix is summarisation at the distribution layer, which is a design decision about addressing rather than about EIGRP.

! Distribution-layer summarisation - the single highest-value change
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  af-interface TenGigabitEthernet1/1/1
   summary-address 10.1.0.0 255.255.0.0
  exit-af-interface
  af-interface TenGigabitEthernet1/1/2
   summary-address 10.1.0.0 255.255.0.0
  exit-af-interface
 exit-address-family
! ^ Must be on EVERY uplink. A missed one leaks specifics and the
!   query boundary silently does not exist for those prefixes.
!
! Verify the boundary works: the summariser replies from its own table
DIST-1# show ip eigrp topology 10.1.0.0/16 | include Summary|via
      via Summary (2816/0), Null0

Hub-and-spoke without stub

A hub with two hundred spokes and no stub configuration queries all two hundred on every failure, and must receive two hundred replies before converging. Worse, each spoke that lacks an answer queries its own LAN, adding latency. Marking spokes as stub removes them from the query set entirely — the hub knows a stub router has no transit paths and does not ask.

! Classic stub on a single-router branch
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  eigrp stub connected summary
 exit-address-family
!
! Confirm on the HUB that queries are suppressed toward this peer
R-HUB# show ip eigrp neighbors detail 10.1.0.5
   Version 23.0/2.0, Retrans: 0, Retries: 0, Prefixes: 3
   Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
   Suppressing queries

Redundant paths with no feasible successor

Two uplinks of identical speed and cost produce two successors and instant failover. Two uplinks where the backup traverses a longer path can easily produce an advertised distance above the FD, giving redundancy that exists physically but not in DUAL. The result is a network that looks redundant on the diagram and goes active on every failure. Auditing for this is straightforward and rarely done.

! Audit: how many prefixes have NO feasible successor?
R1# show ip eigrp topology | include successors
! Count the entries showing '1 successors' and then check each
! against all-links to see whether an alternative exists but failed.
!
! Fix by lowering the backup path's advertised distance - adjust
! delay on the interfaces along it, never bandwidth
interface GigabitEthernet0/3
 delay 50
! ^ Lowering delay upstream reduces the AD the neighbour advertises,
!   which may bring it under the local FD and create an FS.

Measuring convergence rather than assuming it

The difference between a feasible-successor failover and an active-process failover is three orders of magnitude, and it is easy to measure. Fail the primary link during a maintenance window with a continuous ping running, and compare the loss against the topology-table state immediately afterwards. Zero or one lost packet means a feasible successor was promoted. Several seconds of loss means the route went active, and the event log will show exactly which prefixes did so and for how long. Doing this once per design change turns "we have redundancy" from an assumption into a measured property.

! Before the test: does this prefix have a feasible successor?
R1# show ip eigrp topology 10.9.9.0/24 | include successors
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
!
! Fail the primary, then read how long anything stayed active
R1# show ip eigrp events | include Active|Peer
5    14:44:12.104 Active net rt to 10.9.9.0/24, 0 replies
4    14:44:12.104 Peer down: 10.0.13.3 Gi0/2
! ^ Went active. Timestamps between 'Active net rt' and the following
!   'Route installed' give the real convergence time for that prefix.

Conclusion

DUAL is a mechanism for avoiding coordination. Every distance-vector protocol faces the same problem — how do you know a backup path does not loop back through you — and most solve it with timers, holddowns, and waiting. EIGRP solves it with a local arithmetic test. If a neighbour's own cost to a destination is strictly below the best cost you have ever achieved, that neighbour cannot be routing through you, and you may install its path immediately without asking anyone. That is the entire content of the feasibility condition, and it is why EIGRP converges in milliseconds when the test passes.

Everything else follows from what happens when the test fails. There is no local proof available, so the router has to ask, and asking means a query that propagates until it finds routers with answers. The originator then converges at the speed of the slowest branch of that query tree. This is why query scope, not metrics or timers, is the variable that governs EIGRP behaviour at scale, and why summarisation and stub configuration are the two highest-leverage changes available on an EIGRP network. Raising the active timer, the intuitive response to SIA messages, addresses none of it and makes every unresolved failure last longer.

The practical habit worth building is reading the topology table in the right order: the FD on the state line first, then each descriptor block's second number — the advertised distance — compared against it. That comparison, applied mechanically, answers every question about why a backup exists or does not. When it does not, show ip eigrp topology all-links shows the rejected candidates and show ip eigrp events shows the arithmetic that rejected them. Build a four-router topology with three paths of deliberately different costs, then watch which candidates pass and fail as you adjust delay upstream. The point at which a path flips from non-feasible to feasible is the point where you have internalised the condition.

External Links Recommendations

• RFC 7868 — Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP): DUAL, the feasibility condition, the active process, and the SIA mechanism.
• Cisco — Introduction to EIGRP: the composite metric, feasible distance, and worked topology-table examples.
• Cisco — EIGRP Stub Routing: query suppression, the stub options, and their effect on convergence.
• Cisco — What Does the EIGRP DUAL-3-SIA Error Message Mean?: the stuck-in-active process and how to diagnose it.
• Cisco — How Does Unequal Cost Path Load Balancing Work in EIGRP?: variance, traffic share, and the requirement that a path be feasible.
• Cisco IOS-XE EIGRP Configuration Guide: current syntax for variance, summary-address, eigrp stub, and timers active-time.
• Cisco Learning Network — CCIE Enterprise Infrastructure: current blueprint and lab equipment list.

Reference Notes

1. RFC 7868, Section 3.4 — the Diffusing Update Algorithm: successor, feasible successor, feasible distance, and reported distance definitions.
2. RFC 7868, Section 3.4.1 — the Feasibility Condition: a neighbour qualifies when its reported distance is strictly less than the local feasible distance.
3. RFC 7868, Section 3.4.2 — feasible distance is the minimum computed distance to the destination since the route last transitioned from active to passive.
4. RFC 7868, Section 3.5 — the active state: a route goes active when the successor is lost and no feasible successor exists, causing queries to be sent to all neighbours except the one lost through.
5. RFC 7868, Section 3.5 — query propagation stops at a router that can reply from its own topology table.
6. RFC 7868, Section 5.5 — the composite metric with default coefficients K1 = K3 = 1, using minimum bandwidth along the path and cumulative delay.
7. RFC 7868, Section 4.5 — split horizon and poison reverse behaviour in EIGRP update processing.
8. RFC 7868, Section 5.3.6 — the stuck-in-active condition and the SIA-Query and SIA-Reply exchange used to distinguish a slow neighbour from an unresponsive one.
9. Cisco, "What Does the EIGRP DUAL-3-SIA Error Message Mean?" — the default three-minute active timer and the consequences of adjusting it.
10. Cisco, "EIGRP Stub Routing" — stub routers are not queried by their neighbours, which bounds query scope at the stub boundary.
11. Cisco, "How Does Unequal Cost Path Load Balancing Work in EIGRP?" — variance installs feasible successors within the multiplier of the feasible distance; non-feasible paths are never installed.
12. Cisco IOS-XE EIGRP Configuration Guide — show ip eigrp topology all-links displays paths that failed the feasibility condition, and show ip eigrp events records the comparison that rejected them.