EIGRP Explained: Feasible Successors, DUAL and the Metric Formula
EIGRP, the Enhanced Interior Gateway Routing Protocol, is Cisco's advanced distance vector routing protocol, proprietary until Cisco published it as informational RFC 7868 in 2016, and its defining feature is the feasible successor: a backup path the router has already proved loop free before the primary ever fails.
Here is what that buys. A branch link fails at 2am and the network is back before the monitoring graph finishes drawing the dip. No router recalculated a topology, no query left the building, nothing was flooded. That is EIGRP promoting a feasible successor, the best idea in the protocol and the one most tutorials get wrong, starting with the claim that any of it is a CCNA topic.
It is not. CISNET teaches it in the CCNA bootcamp anyway, deliberately. This guide covers both decisions, plus the configuration and the verification output, so you finish knowing what EIGRP does and how it looks on a real router.
Is EIGRP on the CCNA exam?
No, and the cost is real: every hour on DUAL is an hour not spent on the IP Connectivity domain that carries 25 percent of a 120 minute exam. EIGRP, RIP and BGP do not appear in the current blueprint.
| Blueprint | Routing protocols named | EIGRP tested? |
|---|---|---|
| CCNA 200-301 v1.1, through February 2, 2027 | Topic 3.4, single area OSPFv2 | No |
| CCNA 200-301 v2.0, from February 3, 2027 | Topic 3.3, single area OSPFv2 plus OSPFv3 | No |
| CCNP ENARSI 300-410 v1.1 | Topic 1.9, troubleshoot EIGRP | Yes |
Read the source, not a forum post: Cisco publishes the CCNA 200-301 exam topics and the CCNP ENARSI 300-410 exam topics. EIGRP is a named objective on CCNP ENARSI, whose sub-topic 1.9.c lists reported distance, feasible distance, successors, feasible successors and stuck in active by name. The CCNA study guide has the domain breakdown, and the CCNA v2.0 vs v1.1 comparison covers what changes in February 2027.
Why EIGRP is an advanced distance vector protocol
Cisco's documentation calls it "an enhanced distance vector protocol", and RFC 7868 calls it "a routing protocol based on Distance Vector technology". Neither says hybrid, a 1990s marketing word Cisco abandoned. What makes it advanced is that it keeps every neighbour's advertisement in a topology table and runs DUAL over that table to prove a backup loop free before anything fails, instead of relearning on a timer as RIP does.
What it does not change is how much it knows. EIGRP never sees the topology graph, only what each neighbour claims its distance is. That is why it is still distance vector, and why its loop test has to be conservative. Compare OSPF, where every router in an area holds an identical map and runs Dijkstra across it.
| EIGRP | OSPF | |
|---|---|---|
| Algorithm | DUAL, a diffusing computation | Dijkstra shortest path first |
| View of the network | Neighbour distances only | Identical link state database per area |
| Transport | IP protocol 88, multicast 224.0.0.10 | IP protocol 89, multicast 224.0.0.5 and 224.0.0.6 |
| Backup path | Pre-validated feasible successor | Recompute SPF after the change |
The three tables, and what has to match
The neighbor table holds adjacencies with hold time, SRTT and RTO. The topology table holds every path any neighbour advertised, with its bandwidth, delay and distances. The routing table holds successors only, as D at administrative distance 90 for internal routes and D EX at 170 for external ones redistributed in from another protocol.
One warning repairs most people's mental model. Cisco's EIGRP command reference says that without keywords show ip eigrp topology shows "only topology entries with feasible successors", so paths that failed the condition never print. Only all-links shows everything.
Before any of that, four things must agree: the autonomous system number, the K values, a common subnet, and authentication where configured. Hello and hold timers need not, because the hold time rides inside every hello. The failure modes are asymmetric, and that asymmetry is what costs people hours. A K value mismatch is loud: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down: K-value mismatch. An autonomous system mismatch is silent: no syslog, no adjacency, nothing but discarded hellos, visible only under debug eigrp packets hello.
Configure and verify EIGRP
Classic mode is a few lines per router. The autonomous system number must match on every router in the domain, and network takes a wildcard mask, not a subnet mask.
router eigrp 1
network 10.1.10.0 0.0.0.255
network 10.1.50.0 0.0.0.255
no auto-summaryno auto-summary is the default on IOS 15 and later but was not on older trains, so configure it explicitly and the intent survives a refresh. Named mode replaces scattered interface level commands with one container, and it is what ENARSI asks you to configure:
router eigrp CISNET-LAB
address-family ipv4 unicast autonomous-system 1
network 10.1.10.0 0.0.0.255
network 10.1.50.0 0.0.0.255
af-interface Serial0
hello-interval 5
hold-time 15
exit-af-interface
exit-address-familyVerify in that order. Adjacency first:
R1# show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.50.1 Se0 13 00:04:21 26 156 0 12
1 10.1.60.2 Se1 12 00:04:18 31 186 0 9
2 10.1.70.2 Se2 11 00:03:57 44 264 0 7Read three columns. Uptime resetting to seconds is a flapping adjacency, not a routing problem. Hold resets on every hello, so a value drifting toward zero means hellos are being lost. Q Cnt should be zero; anything else means reliable packets sit unacknowledged for that neighbour, the first symptom of the slow neighbour that later causes a stuck in active event. An empty table after configuring both ends almost always means the autonomous system numbers differ, because that failure prints nothing.
show ip eigrp interfaces comes next: it lists only the interfaces the network statements actually matched, which beats re-reading your own wildcard masks. Then read the topology table, with all-links so nothing is hidden:
R1# show ip eigrp topology all-links
P 10.1.10.0/24, 1 successors, FD is 20307200
via 10.1.50.1 (20307200/20281600), Serial0
via 10.1.60.2 (46277376/307200), Serial1
via 10.1.70.2 (47019776/46277376), Serial2The header line gives the destination, the successor count, and the feasible distance. The first via is the successor: lowest computed distance, so it is the path in the routing table. The second is a feasible successor, reporting 307,200, comfortably under the feasible distance of 20,307,200. The third reports 46,277,376, larger than the feasible distance, so it fails the condition and is not a backup. Drop all-links and that third line disappears, which is why people conclude a path is missing when the router is refusing to trust it.
Feasible distance, reported distance, and the third one nobody mentions
Feasible distance (FD) is the lowest total metric this router has known to a destination since that route last went from active to passive. One per prefix, a historical low water mark rather than the current best path's metric.
Reported distance (RD) is the composite metric a neighbour advertises for its own path. Cisco also calls it advertised distance, which collides badly with administrative distance. The two are unrelated: RD describes a neighbour's path, administrative distance is a 0 to 255 trust rating applied locally to the route source.
Computed distance (CD) is that neighbour's RD plus the local link cost. In the output above, the bracketed pair on every via line is computed distance then reported distance. It is not FD then RD, and misreading that bracket is the single biggest reason the feasibility condition confuses people.
The feasibility condition
The rule is RD < FD. Strictly less than, not less than or equal to. A neighbour is usable as a backup only if it is already closer to the destination than this router has ever been since the route last went passive. Anything worse might be looping back through me.
Cisco's own numbers make it concrete. Router One reaches Network A through Router Three at a computed distance of 20,307,200, so its FD is 20,307,200. Router Four advertises a reported distance of 307,200, well under that FD, so it becomes a feasible successor. The failing case sits one router away: Router Three's FD is 20,281,600, while its alternates through Router Two and Router One both compute to 47,019,776. Both exceed the FD, so neither is installed, and that rejection is what stops Router Three handing traffic back to a neighbour that already routes through Router Three.
RFC 7868 section 3.3 states the philosophy almost nothing online repeats: "every path meeting the Feasibility Condition is guaranteed to be loop free; however, not all loop-free paths meet the Feasibility Condition." EIGRP discards some usable backups in exchange for deciding instantly and locally.
A successor meets the condition and is least cost, so it forwards traffic. A feasible successor meets it but is not least cost, so it waits in the topology table as a pre-validated spare, promoted by a lookup, with no algorithm and no packet.
How DUAL guarantees a loop free path
DUAL is a finite state machine that runs independently per destination prefix.
- A topology change arrives: a link drops, or a metric rises past the FD.
- The router tests every topology table entry for that prefix against the condition.
- If a feasible successor exists, promote it, stay passive, send an update.
- If none exists, mark the route active, hold the feasible distance, and query every neighbour.
- A neighbour with its own feasible successor replies at once. One without goes active and diffuses the query outward.
- Replies return, the router picks a new successor, records a new FD, and goes passive.
Step four is where most write ups go wrong. The feasible distance is held at the value that was best when the route went active, not reset, because every reply is tested against it. Relax it and every reply passes, destroying the loop free guarantee. The FD is re-recorded only at step six.
When DUAL gets stuck in active
If a query goes unanswered the router sends an SIA-QUERY probe at 90 seconds, half the stuck in active interval. If that also goes unanswered it declares the route stuck in active at the end of the three minute active timer and resets that neighbor session. One slow router at the edge of a query domain tears down a healthy adjacency.
timers active-time raises the limit, and Cisco's stuck in active troubleshooting guide tells you not to: "The better solution, however, is to redesign the network to reduce the range of queries".
The metric, actually calculated
RFC 7868 writes the classic composite metric as:
metric = 256 * ({(K1*BW) + [(K2*BW)/(256-LOAD)] + (K3*DELAY)} * (K5/(REL+K4)))Defaults are K1=1, K2=0, K3=1, K4=0, K5=0. With K5 zero Cisco drops the reliability term entirely rather than multiplying by it, leaving 256 * [(10,000,000 / lowest bandwidth in kbps) + sum of delays in tens of microseconds].
Two rules and one trap. Bandwidth is the minimum along the path, not an average. Delay is the sum of every outbound interface delay. The trap: both show ip eigrp topology and show interface print delay in microseconds, so divide by 10 first.
| Path | Lowest bandwidth | Total delay | Metric |
|---|---|---|---|
| Via Router Four | 56 kbps | 2200 | (10000000/56 + 2200) x 256 = 46,277,376 |
| Via Router Three | 128 kbps | 1200 | (10000000/128 + 1200) x 256 = 20,307,200 |
Hop count is absent: metric maximum-hops defaults to 100 and is a scope limit, never a tiebreaker. Load and reliability stay off because both are rolling averages that move with traffic, so enabling K2, K4 or K5 makes the metric churn and routes flap. Tune delay, not bandwidth, because EIGRP throttles itself to 50 percent of configured interface bandwidth. Named mode also carries 64 bit wide metrics, and variance 2 load balances over paths up to twice the successor's metric, but only paths that already passed the feasibility condition.
How CISNET teaches EIGRP
I am Mani Poopal, CCIE certified, and I spent twenty years running enterprise networks and designing them for a Fortune 500 before teaching full time. Two things I keep seeing are worth more than any feature list.
The first is a classroom pattern. In the DUAL lab, the step that fails most often in every cohort is not the configuration, it is reading the bracket. Students see (20307200/20281600), call the first number the feasible distance because that is how most tutorials describe it, test the wrong value against the feasibility condition, decide a good backup should have been installed, and start changing delay to chase a problem the router does not have. I now teach the bracket before the condition itself, with all-links open on the screen, and that lab stops going sideways.
The second is from production. The mismatch that costs the most time in the field is not the K value mismatch, because that one shouts at you in the log. It is the autonomous system mismatch, which says nothing. A new site goes in, routes never appear, both routers look healthy, every interface up. If you do not know EIGRP silently discards a hello from the wrong AS, you will spend an afternoon on cabling and access lists before checking two numbers that should have matched. Understanding why a router keeps a backup it is not using, and why it stays quiet when it rejects a neighbour, teaches routing better than almost any exam objective. That is why the CCNA bootcamp covers EIGRP in the IP Routing module beside administrative distance and route selection, with hands on Packet Tracer labs, even though the exam will not ask for it. CCNP ENARSI takes it further, to named mode, stub design and query scoping.
Frequently Asked Questions
Is EIGRP on the CCNA 200-301 exam?
No. The CCNA 200-301 v1.1 blueprint names one interior gateway protocol, topic 3.4, "Configure and verify single area OSPFv2", and the announced v2.0 blueprint adds only OSPFv3. EIGRP is a named objective on CCNP ENARSI 300-410, topic 1.9, instead. Older guides call it CCNA because it was one on the retired 200-125 track.
How do I configure EIGRP on a Cisco router?
In classic mode, enter router eigrp 1, where 1 is the autonomous system number that must match on every router in the domain, add a network statement with a wildcard mask for each connected subnet you want advertised, such as network 10.1.10.0 0.0.0.255, and confirm no auto-summary. Verify with show ip eigrp neighbors for adjacency, show ip eigrp interfaces to confirm the network statements matched the interfaces you expected, and show ip eigrp topology all-links to see every path, including those that failed the feasibility condition.
What is the difference between feasible distance and reported distance in EIGRP?
Feasible distance is the lowest total metric your router has known to a destination since that route last went from active to passive, so there is one per prefix. Reported distance is what a neighbour advertises for its own path, so there is one per neighbour. The bracketed pair in show ip eigrp topology is computed distance then reported distance, not feasible then reported.
What is the feasibility condition in EIGRP?
A neighbour satisfies the feasibility condition when its reported distance is strictly less than your router's feasible distance for that prefix, less than rather than less than or equal to. A neighbour already closer to the destination than you have ever been cannot be looping back through you. The test is sufficient but not necessary, so some genuinely loop free paths are discarded.
What is the administrative distance of EIGRP?
Internal EIGRP routes carry an administrative distance of 90 and appear as D, external EIGRP routes carry 170 and appear as D EX, and our administrative distance guide has the full table of route source values.
Why is my EIGRP route stuck in active?
A route goes active when the feasibility condition fails and no feasible successor exists, so the router queries its neighbours. If one does not reply, the querying router sends an SIA-QUERY probe at 90 seconds and, if that is also unanswered, declares the route stuck in active at the end of the three minute active timer and resets that neighbor session. Cisco's fix is a smaller query domain, bounded by summarisation, autonomous system boundaries, distribution lists and eigrp stub routers.
