A second EIGRP path is not automatically a ready-to-use backup. The interview question is: what makes a neighbor a successor or feasible successor, and which distances does EIGRP compare?
Short answer: a successor is a neighbor providing a least-cost path that satisfies EIGRP's feasibility condition; a feasible successor is a neighbor whose reported distance is strictly less than the local feasible distance for that destination.[1]
Successor, feasible successor, FD and RD: the difference
EIGRP's DUAL algorithm tracks distances per destination and neighbor, rather than treating every alternative next hop as immediately safe.[1]
| Term | Meaning | Interview reminder |
|---|---|---|
| Successor | Neighbor providing a least-cost path and satisfying the feasibility condition.[1] | The selected EIGRP next hop; equal-cost successors can exist. |
| Feasible successor (FS) | Neighbor satisfying the feasibility condition for that destination.[1] | Often described as a prequalified backup; formally, successors also satisfy this definition. |
| Reported distance (RD) | Distance advertised by the neighbor for the destination.[1] | The neighbor's report, not your total cost through that neighbor. |
| Computed distance (CD) | Your total metric through a particular neighbor.[1] | Used to compare complete candidate paths. |
| Feasible distance (FD) | Lowest total metric recorded since the destination last transitioned from Active to Passive.[1] | A historical loop-prevention threshold, not necessarily today's best-path metric. |
You may also hear advertised distance (AD) used for reported distance. In that context, AD does not mean administrative distance, which is a different route-selection concept. To avoid ambiguity, use RD when discussing the feasibility test.
The feasibility condition: RD must be strictly less than FD
The test is candidate neighbor's RD < local FD for this destination; equality does not pass.[1]
Do not compare the candidate's complete path metric against FD and call that the feasibility condition: the RFC explicitly compares the neighbor's report against the local threshold.[1]
The condition is sufficient to establish loop freedom, but it is not necessary: failing it does not prove that the alternative path contains a loop.[1]
That distinction explains why a physically working second connection can exist without providing a feasible-successor backup.[1]
Worked example: which neighbor can be the backup?
This is an original, simplified teaching example, not captured router output. Assume R1 has a stable route to the documentation prefix 192.0.2.0/24, its local FD is 30, and these are the already-computed metrics. The numbers are illustrative metric units, not interface bandwidth values or a real EIGRP metric calculation.
| Neighbor | Neighbor's RD | R1's total metric through neighbor | Test against FD 30 | Initial role |
|---|---|---|---|---|
| R2 | 10 | 30 | 10 < 30: pass | Successor: lowest total metric |
| R3 | 20 | 45 | 20 < 30: pass | Non-successor feasible successor |
| R4 | 30 | 50 | 30 < 30: fail | Alternative, not currently feasible |
R3 qualifies even though its total metric is worse than R2's. R4 fails because equality is not enough. These classifications apply the RFC's strict feasibility test to the example values.[1]
If the R2 path disappears while the other reports remain unchanged, R3 is both feasible and the lowest-cost remaining path, allowing local successor replacement without a diffusing computation.[1]
If instead R3 is unavailable and only R4 remains, R1 cannot simply declare R4 safe based on its presence in the topology table; DUAL must coordinate a new computation before selecting a usable replacement.[1]
Avoid the blanket claim that any feasible successor anywhere in the table guarantees the route stays Passive: the RFC's precise condition requires a feasible neighbor providing the least-total-cost available path.[1]
Why FD is not always the current best metric
A useful beginner shortcut is “FD is the metric of the best route,” but the exact definition includes history: FD records the lowest total metric since the last Active-to-Passive transition.[1]
Consider a separate hypothetical event: R1's FD is 30 and its successor's total metric increases to 40 while that neighbor's RD remains 10; assume that path is still the least-cost path. The route can stay Passive, but the historical FD remains 30 rather than automatically becoming 40.[1]
An alternative advertising RD 35 therefore does not pass the current test: compare 35 against the historical FD 30, not against the current total metric 40.[1]
Troubleshooting lesson: collect both the displayed feasible distance and each path's metric pair; do not reconstruct FD from the current best path alone.
Route-state and message flow
A usable, converged EIGRP route is normally Passive; Active means a coordinated route computation is taking place, not that the route is successfully forwarding traffic.[1]
- A neighbor advertises destination information; EIGRP records its report and computes the local metric through that neighbor.[1]
- DUAL evaluates least-cost paths together with the feasibility condition.[1]
- A topology change causes those choices to be reevaluated.[1]
- If a least-cost remaining neighbor passes the feasibility test, the route can remain Passive.[1]
- Otherwise the route becomes Active and Query/Reply exchanges coordinate recomputation; completion can produce a new successor or establish that the destination is unreachable.[1]
Active alone is not the same as Stuck in Active: SIA concerns an Active computation that does not finish within the applicable timing behavior.[1]
Practical verification checklist
For a classic IPv4 Cisco IOS/IOS XE lab, these are useful starting commands. They are illustrative commands, not a transcript from an executed router test; named-mode, VRF and software-version syntax can differ.
show ip eigrp neighbors
show ip eigrp topology
show ip eigrp topology all-links
show ip eigrp topology 192.0.2.0 255.255.255.0
show ip route 192.0.2.0
show ip protocols
Use the following checklist rather than immediately changing configuration:
- Confirm the destination and routing context. Compare the same prefix, address family and VRF throughout.
- Check the neighbor first. Is the expected alternate peer actually established?
- Inspect the complete topology view. Use
all-linkswhen a candidate is missing from the normal display; a non-feasible alternative may still be known. - Read the metric pair carefully. In typical classic topology output,
(total metric / reported distance)distinguishes your complete path from the neighbor's report. - Apply the strict test. Compare each candidate RD with the displayed local FD, not with another candidate's RD.
- Check the route state and routing table separately. EIGRP's topology choice and the route ultimately installed for forwarding are different observations.
- Preserve evidence before making changes. Save the topology entry, neighbor uptime, interface metrics and relevant logs.
For a safe lab exercise, create two alternative paths to a test prefix. Record FD and each RD before removing the primary link, then repeat with an alternative that fails the test. Observe whether the destination stays Passive or enters Active. Use an isolated lab, not an unapproved production shutdown.
Common interview pitfalls
- “The second-best metric is always the feasible successor.” No: the neighbor must pass the RD-versus-FD test.[1]
- “RD equal to FD is acceptable.” No: the inequality is strict.[1]
- “No feasible successor means no alternate path exists.” No: the test may reject a genuinely loop-free path that requires coordinated recomputation.[1]
- “FD always equals the current successor metric.” No: FD is a historical minimum over the current Passive period.[1]
- “Passive means the route is broken.” No: Passive is the normal usable state; Active is the recomputation state.[1]
A concise interview answer
“A successor is the least-cost EIGRP next-hop neighbor that passes the feasibility condition, and a feasible successor is a neighbor already proven loop-free by that condition.[1]
“The test compares the neighbor's reported distance with my local feasible distance: RD must be strictly lower than FD.[1]
“FD is the lowest total metric since the last Active-to-Passive transition, so it is not always identical to the current best metric.[1]
“If the remaining least-cost path cannot pass that test, DUAL uses a coordinated Query/Reply computation rather than blindly selecting the next entry.”[1]
Related reading
- OSPF neighbor states: a different protocol's adjacency state machine
- HSRP vs VRRP vs GLBP: first-hop failover versus routing convergence
Summary
Remember the distinction: CD ranks complete paths; RD is the neighbor's advertised distance; FD is the local historical threshold; and RD < FD proves feasibility.[1]
Preparing for a network engineering interview? Recreate the example table without looking, explain why equality fails, and describe what changes when no remaining least-cost path passes the test.
Post a Comment