EIGRP Stuck in Active (SIA) means that a route's distributed computation has not received a required Reply within the permitted time; Cisco implementations can reset the unresponsive neighbor and remove routes learned through it.[1] For an interview, distinguish normal Active route computation from Stuck in Active, then explain how you would trace the missing reply and reduce query scope.[1][2]
What does Active mean in EIGRP?
Passive means that DUAL is not performing a diffusing computation for that destination; it is normally the desired stable state.[1] A common transition to Active happens when the successor path fails and no feasible successor is available, so the router queries neighbors to resolve the destination.[1][2] Active describes a destination's routing computation, not an EIGRP neighbor session state.[1]
| Term | Meaning | Practical interpretation |
|---|---|---|
| Passive | No active diffusing computation for this destination | Normally stable; not an error[1] |
| Active | Computation is waiting on routing replies | Can be a normal part of convergence[1] |
| Stuck in Active | Required progress/replies did not arrive within the permitted timing | Investigate the dependency chain and transport health[1][2] |
A reply saying that a destination is unreachable is still a valid answer: the computation needs completed replies, not necessarily a working alternative path.[1][2]
Query and Reply flow: a simple example
Consider this fictional dependency chain, not a captured lab result:
A ---- B ---- C
A loses its successor for 192.0.2.0/24, with no feasible successor.
A sends a Query to B.
B depends on A for that destination and has no feasible successor.
B goes Active and queries C.
A waits for B; B waits for C.
This illustrates how a missing downstream reply can delay a healthy upstream neighbor: the router named in the first error is not necessarily the original failure point.[2] A router that has no topology entry for the queried destination can immediately answer unreachable; it does not blindly relay every unknown-prefix query throughout the network.[2]
For troubleshooting, ask two separate questions: why did the route disappear, and why did the query fail to complete? Cisco's worked example demonstrates that these can be separate faults.[2]
Is the SIA timer always three minutes?
The older Cisco troubleshooting document describes approximately three minutes, but it is explicitly based on IOS 12.0 behavior.[2] RFC 7868 describes SIA-Query/SIA-Reply progress checking, with the first SIA-Query at half the active interval—90 seconds in its default implementation example.[1] A neighbor still computing can send an SIA-Reply with its Active flag set; this indicates progress, not completion of the original Query.[1] The RFC describes bounded extensions and a limit of three busy SIA-Replies in Cisco's implementation, rather than unlimited waiting.[1]
Do not promise that every platform will reset a session at exactly the same wall-clock time. Check the deployed release, configured timers, and actual Query/SIA-Query/SIA-Reply exchange before making a timing claim.
Troubleshooting: follow the outstanding reply
Start with a timestamped snapshot before clearing any neighbors. The following are illustrative Cisco IOS/IOS XE IPv4 verification commands, not output from an executed router lab; adapt syntax for your release, VRF, and EIGRP configuration mode.
show ip eigrp topology active
show ip eigrp neighbors
show ip eigrp neighbors detail
show ip eigrp traffic
show logging
show interfaces
show processes cpu
Cisco recommends using show ip eigrp topology active to identify the outstanding reply, then inspecting that neighbor and continuing downstream until the blocking point is found.[2]
In the documented topology output, a lowercase r or a Remaining Replies section identifies a neighbor still owing a reply.[2]
Use SSH or your approved management channel to inspect that router; do not adopt the legacy document's Telnet workflow.
| Check | Evidence to collect | Why it matters |
|---|---|---|
| Active destination | Exact prefix, elapsed time, outstanding neighbor | Establishes the query dependency[2] |
| Next router | Whether it is itself waiting on another router | Separates a downstream wait from a local failure[2] |
| Link health | Increasing errors, drops, resets, congestion | Queries or replies may be delayed or lost[2] |
| Router resources | CPU, memory and buffer pressure at the event time | A busy device may fail to process protocol traffic promptly[2] |
| Original route loss | Interface events and configuration changes | Fixes the trigger as well as the stalled computation[2] |
A successful ping alone is not enough evidence to close the incident: investigate routing-message delivery and processing, not just occasional reachability. Avoid a broad neighbor clear as your first diagnostic action; preserve the evidence that identifies the waiting chain.
Preventing SIA in a hub-and-spoke network
Use EIGRP stub on genuinely nontransit spokes
An EIGRP stub advertises its stub status to neighbors; a neighbor that recognizes this status does not query the stub for routes.[3] This is especially useful for branches that should never carry transit traffic between distribution routers.[3] A stub can be dual-homed: having two upstream neighbors does not automatically make it a transit router.[3]
Illustrative addition to an existing classic-mode EIGRP process on a nontransit spoke:
router eigrp 100
eigrp stub connected summary
The connected and summary keywords select those advertisement categories; the bare eigrp stub command also defaults to connected and summary advertisement.[3]
The command does not create a summary or supply a default route from the hub; those are separate design/configuration decisions.[3]
Verify the spoke's stub status from the hub with show ip eigrp neighbors detail.[3]
Before applying this change, inventory the routes the branch must advertise, especially redistributed/static routes, and confirm that no required backup path relies on transit through that branch. Do not apply ordinary stub settings indiscriminately to the core or to a required transit router.[3]
Summarize at deliberate boundaries
Aggregation limits the visibility of detailed reachability and can constrain the scope of a diffusing computation.[1] For example, a router that only knows a covering summary and has no exact topology entry for a queried component prefix can answer that component query unreachable rather than extend a search for it.[2] However, summarizing routes sent toward a spoke is not equivalent to making that spoke an EIGRP stub; Cisco explicitly documents cases in which the hub can still query that spoke.[3]
Treat summarization as a design change: test the loss of a component prefix, the withdrawal of the summary, and failover in both directions. Do not add an aggregate solely to suppress a log message without checking forwarding behavior.
Repair the underlying fault
Congested/degraded links and insufficient router resources can prevent timely replies, while flapping interfaces can repeatedly trigger computations.[2] Reducing query scope helps contain the failure domain; it is not a repair for packet loss or an overloaded control plane. Raising or disabling a timeout should not be the first response to an unexplained SIA event.
Common interview pitfalls
- “Active means the route is healthy.” It means DUAL is computing; Passive is normally the stable state.[1]
- “No alternative route means SIA.” An unreachable Reply can complete the computation; missing replies are the issue.[1][2]
- “An SIA-Reply is the final routing answer.” A busy SIA-Reply can confirm ongoing processing without completing the original Query.[1]
- “Every unknown route is queried onward.” A router with no topology entry can immediately reply unreachable.[2]
- “Stub means one uplink.” Nontransit dual-homed spokes are supported.[3]
- “Summarization and stub are interchangeable.” They affect query scope differently; summarization toward a spoke does not automatically suppress queries to it.[3]
A concise interview answer
“EIGRP Stuck in Active is a failure to complete the reply process for an Active destination within the allowed timing.[1] I would identify the exact active prefix and outstanding neighbor, trace the reply dependency downstream, and check packet loss, congestion and router resources before changing timers.[2] SIA-Query and SIA-Reply help distinguish a neighbor that is still computing from one that is not responding.[1] For prevention, I would use stub routing on nontransit spokes and deliberate summarization to reduce query scope, while correcting the original link or resource problem.”[1][2][3]
Suggested lab and summary
In an isolated lab, start with a hub, a nontransit spoke and an upstream router. Record neighbors and topology before withdrawing a test route, then capture the Query/Reply exchange. Repeat with the spoke configured as a stub and verify what changes at the hub. This is a proposed exercise, not a claim of measured results.
The key distinction is Active is a computation; SIA is a failure to finish its required reply process in time.[1] For interview preparation, practice drawing the waiting chain and explaining why the first router named in a log may only be waiting on a downstream problem.[2]
Related reading
Preparing for a network engineering interview? Explain the Query/Reply flow aloud, then write down the first command you would use to locate the missing reply.
Post a Comment