skip to content

DUAL Algorithm

DUAL accepts a backup path only if its reported distance is below the current feasible distance, which stays loop-free without a map. Interviewers then ask what stuck-in-active means.

on this pageshow

questions

6

In EIGRP, what is the feasibility condition, and how does it decide which neighbours become feasible successors for a prefix?

level: middleimportance: must knowfreq 30%

answer

  1. judge the neighbour's distance, not the total
  2. reported distance versus feasible distance
  3. strictly less than
  4. best distance since the route went passive

basics

~20 s

A neighbour meets EIGRP's feasibility condition when its reported distance to a prefix is strictly below this router's feasible distance, its best distance since the route last went passive; that neighbour is a feasible successor, a guaranteed loop-free backup.

solid answer

~50 s

Every EIGRP neighbour advertises a **reported distance** (RD) to each prefix. The router adds the link cost to get a computed distance through that neighbour, and keeps a **feasible distance** (FD): the lowest distance it has had to the prefix since the route last became passive. The **feasibility condition** is `RD < FD`, strictly. A neighbour that meets it is a **feasible successor**; the one that meets it and gives the lowest total cost is the **successor**, the next hop in use. Say the FD is 20: a neighbour reporting 15 over a costly link qualifies, while one reporting exactly 20 does not, however cheap its link. The test looks only at the neighbour's own distance, because a neighbour whose path ran through this router would have to report more than this router's distance. When the successor fails, a feasible successor takes over immediately; without one, the route goes active.

code

pseudocode · 17 lines
pseudocode
fd = 20   // R1's best distance to 10.1.50.0/24 since the route last went passive
neighbours = [
  { name: N1, rd: 10, link: 10 },
  { name: N2, rd: 15, link: 20 },
  { name: N3, rd: 20, link: 20 },
  { name: N4, rd: 30, link: 15 }
]
for n in neighbours:
  n.cd = n.rd + n.link          // N1 20, N2 35, N3 40, N4 45
  n.feasible = n.rd < fd        // strict: N3 (20) fails
feasible = [n in neighbours where n.feasible]   // N1, N2
successor = feasible with lowest cd             // N1 (cd 20)
feasible_successors = feasible minus successor  // N2
if successor fails and feasible_successors not empty:
  successor = lowest cd among feasible_successors   // N2, route stays passive
else if successor fails:
  mark route active and send QUERY to neighbours

go deeper

for a junior

Remember the one-line rule: a neighbour's reported distance must be strictly lower than this router's feasible distance for it to count as a backup.

for a middle

Work a table of neighbours by hand: compute each total, pick the successor, and show why a costlier neighbour can pass while a cheaper one fails.

for a senior

Explain why the feasible distance is a historical minimum and why that choice keeps the test safe while the router's own distance changes.

for a principal

Discuss the cost of a conservative test: designs where the backup fails the condition pay a query on every failure, so metric design affects convergence.

## The two numbers the test compares An EIGRP router learns, from each neighbour, that neighbour's **reported distance** (RD) to a prefix: the neighbour's own metric to it. The router adds the cost of the link to that neighbour and gets the **computed distance** through it. The topology table records the RD of every neighbour that advertises the prefix. The router also keeps one **feasible distance** (FD) per prefix. RFC 7868 defines it carefully: the lowest distance this router has had to the prefix **since the route last went from active to passive**. It is a historical minimum, not necessarily the current distance. While the route stays passive the FD can fall but never rise; it is reset only when an active computation finishes. The **feasibility condition** compares those two: - a neighbour meets it when **its RD is strictly less than this router's FD**; - a neighbour that meets it is a **feasible successor**; - a feasible successor that also gives the **least total cost** is a **successor**, the next hop used for forwarding. RFC 7868 says EIGRP uses the Source Node Condition and describes it plainly: the condition is met when the neighbour is closer to the destination than this router has ever been since the route last became passive. ## A worked example The numbers below are kept small for illustration; real EIGRP metrics are much larger values computed from bandwidth and delay. Router R1 has four neighbours for `10.1.50.0/24`: | Neighbour | Reported distance | Link cost | Computed distance | RD < FD (20)? | Role | |---|---|---|---|---|---| | N1 | 10 | 10 | 20 | yes | successor | | N2 | 15 | 20 | 35 | yes | feasible successor | | N3 | 20 | 20 | 40 | no, equal | not feasible | | N4 | 30 | 15 | 45 | no | not feasible | N1 gives the lowest computed distance and meets the condition, so it is the successor and R1's FD is 20. N2's path is costlier in total, yet it qualifies because its own distance, 15, is below 20. N3 reports exactly 20: the test is strict, so it fails. N4 reports 30 and fails. If the link to N1 fails, R1 switches to N2 at once. The route stays **passive**, R1 sends an update with its new distance of 35, and no other router is asked anything. Had N2 not existed, only N3 and N4 would remain, both failing the test, and the route would go **active** and R1 would query its neighbours. ## Why the neighbour's distance is what counts The condition never asks whether the backup is cheap; it asks whether the backup is **safe**. A neighbour whose path to the prefix ran through R1 would have to report at least R1's own distance plus positive link costs, which is more than R1's FD. So a neighbour reporting less than the FD cannot be depending on R1, and using it cannot close a loop. A neighbour reporting more might be depending on R1 or might simply be far away; R1 only knows distances, not paths, so it cannot tell which, and does not risk it. Two consequences follow: 1. A **feasible successor is not simply the second-best path.** The second-cheapest neighbour may fail the test, and a costlier one may pass it. 2. The test is **conservative.** Some neighbours with perfectly loop-free paths fail it, and losing the successor then costs a query instead of an instant switch. ## The check, step by step 1. For each neighbour, compute the total: reported distance plus link cost. 2. Mark a neighbour feasible if its reported distance is strictly below the feasible distance. 3. Among feasible neighbours, the one with the lowest total is the successor; the others are feasible successors. 4. If the successor is lost and a feasible successor remains, use the cheapest one and stay passive; otherwise go active. The check runs for every prefix independently, and RFC 7868 makes every path selection in DUAL subject to it: whenever a neighbour's reported distance or a link cost changes, DUAL asks again whether the least-cost neighbour still meets the condition. ## What the condition does not cover - **How distances are computed** is the composite metric's job; the condition only compares the results. - **How the candidates are stored and installed** in the routing table, including equal-cost successors and unequal-cost load sharing, belongs to the topology table. - **What happens when nothing qualifies** is the active state and the query process: the condition decides whether that process starts.

  • Why does EIGRP compare against the feasible distance rather than the router's current distance?
    The FD is the lowest distance the router has had since the route last went passive, so every distance it has advertised in that time is at least the FD. A neighbour whose path runs through this router built its distance on one of those advertisements plus positive link costs, so it reports more than the FD. Comparing with the current distance, which may have risen, would let such a neighbour slip through.
  • Does a feasible successor have to be the second-cheapest path?
    No. The condition tests the neighbour's reported distance, not the total cost through it. A neighbour with a low total cost can fail because it reports a distance at or above the feasible distance, while a neighbour behind an expensive link can pass because its own distance is small. Cost picks the successor among feasible neighbours; feasibility decides who is eligible.
  • What happens to a neighbour that fails the condition?
    Its distance is still recorded, so it remains a candidate the router knows about, but it is not used as a backup. If the successor is lost and only such neighbours remain, the route goes active and the router queries its neighbours; a neighbour that failed the test may well become the new successor once the computation finishes and the feasible distance is reset.

You are lost and ask passers-by the way to the station. You only rely on someone who is nearer the station than you have been at any point since you last knew where you were: a person that close cannot be getting there by walking back past you. Someone farther away may know a fine route, but you cannot tell, so you do not count on them.

saying these in an interview costs you the question

  • A feasible successor is simply the neighbour with the second-lowest total cost
  • The condition compares the total cost through a neighbour with the successor's total cost
  • A neighbour whose reported distance equals the feasible distance still qualifies
  • The feasible distance is always the router's current distance to the prefix
  • Every neighbour that advertises the prefix is a feasible successor
open as a page

What does stuck-in-active mean for an EIGRP route, how do SIA-QUERY and SIA-REPLY change the outcome, and what usually causes it?

level: seniorimportance: must knowfreq 18%

basics

~20 s

An EIGRP route is stuck in active when a queried neighbour fails to reply in time; an SIA-QUERY asks whether it is still computing, an SIA-REPLY says yes, and a silent neighbour loses the route or its whole adjacency.

open as a page

What is DUAL in EIGRP, and how does it let a router change paths after a failure without creating a routing loop?

level: juniorimportance: should knowfreq 25%

basics

~20 s

DUAL, the Diffusing Update Algorithm, is how EIGRP picks routes: it keeps backup next hops that pass a loop-freedom test and switches to one at once; when none exists, it freezes the route and queries its neighbours before choosing again.

open as a page

When an EIGRP router loses its successor and has no feasible successor, how does DUAL's query-and-reply diffusing computation find a new path?

level: seniorimportance: should knowfreq 15%

basics

~20 s

The EIGRP route goes active and unusable; the router queries its neighbours, unaffected ones reply at once, affected ones go active and query onward, and once every reply is in it resets its feasible distance and picks the best answer.

open as a page

How do summarisation and stub routing bound EIGRP's query domain, and why does a bounded query domain make DUAL more stable?

level: seniorimportance: should knowfreq 12%

basics

~20 s

An EIGRP query ends at any router with no entry for the failed prefix, which replies at once with an infinite metric; summarisation hides specific prefixes beyond a boundary, and stub routing, an implementation feature, exempts routers that offer no transit.

open as a page

Why does EIGRP's feasibility condition guarantee that a feasible successor's path is loop-free, and why does it still reject some loop-free paths?

level: seniorimportance: nice to knowfreq 10%

basics

~20 s

A neighbour routing through this EIGRP router must report more than this router's feasible distance, having added positive link costs to its advertisement; a lower report proves independence. But a long independent path also reports high, so it is rejected too.

open as a page