EIGRP Query Process and Stuck-in-Active (SIA) Explained

Stuck-in-active is the most infamous failure mode EIGRP has. A single lost route in one corner of a large network triggers a chain of queries, and if any router in that chain fails to answer for three minutes, adjacencies start getting torn down in places that had nothing to do with the original failure. Understanding the query process is how you design networks where that cannot happen. This deep dive builds directly on the DUAL concepts in the EIGRP complete guide, with real query and reply packets captured from a CML lab.

What Happens When a Route Dies

When EIGRP loses a route, the outcome depends entirely on the topology table. If a feasible successor exists, DUAL promotes it in milliseconds and the route never leaves Passive state. Nobody else in the network is consulted. This is EIGRP at its best.

If there is no feasible successor, the router has no pre-validated loop-free alternative, so it must ask. The route goes Active, and the router sends a query packet for that exact prefix to every neighbor. Each neighbor does one of three things:

• Replies immediately if it has no knowledge of the prefix, or its own valid path that does not depend on the querying router.
• Propagates the query to its own neighbors if the lost route was its successor too, then waits for their answers before replying.
• Replies with unreachable if it only knew the route through the asker.

The querying router cannot finish the computation until every single neighbor has replied. One slow or wedged router anywhere in the query domain holds the prefix hostage. That is the structural weakness the SIA machinery exists to manage.

Watching a Query Live

In the lab, R3 loses a connected network (we shut its Loopback10, which carries 10.1.0.0/24). With debug eigrp packets query reply running on R1, the whole conversation is visible:

R1# debug eigrp packets query reply
    (QUERY, REPLY)
EIGRP Packet debugging is on

*Jul 11 05:24:26.613: EIGRP: Received QUERY on Et0/2 - paklen 44 nbr 10.0.13.2
*Jul 11 05:24:26.623: EIGRP: Enqueueing REPLY on Et0/2 - paklen 0 nbr 10.0.13.2
  tid 0 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 72-72
*Jul 11 05:24:26.626: EIGRP: Sending REPLY on Et0/2 - paklen 44 nbr 10.0.13.2 tid 0

R1 received the query and answered in 13 milliseconds. Why so fast? Because at the time of this capture, R3 was summarizing 10.1.0.0/22 toward R1. R1 never knew the /24 existed, so it had nothing to recompute and replied instantly. We will come back to that, because it is the single most useful fact in this article.

The active state itself is usually too fast to catch in a healthy lab:

R1# show ip eigrp topology active
EIGRP-IPv4 VR(PINGLABZ) Topology Table for AS(100)/ID(1.1.1.1)

Empty. Convergence already finished. In a healthy network, Active states live for milliseconds. show ip eigrp traffic keeps score over time, including the counters you hope stay at zero:

R1# show ip eigrp traffic
EIGRP-IPv4 VR(PINGLABZ) Address-Family Traffic Statistics for AS(100)
  Hellos sent/received: 309/196
  Updates sent/received: 44/48
  Queries sent/received: 8/8
  Replies sent/received: 11/8
  SIA-Queries sent/received: 0/0
  SIA-Replies sent/received: 0/0

What Stuck-in-Active Actually Means

Every router that goes Active for a prefix starts the active timer, 3 minutes by default. You can read it straight out of show ip protocols:

R1# show ip protocols | include Active Timer
      Active Timer: 3 min

If any neighbor still has not replied when the timer expires, the router declares the route stuck-in-active, logs %DUAL-3-SIA, and resets the adjacency with the silent neighbor. That reset is the brutal part: every route through that neighbor is flushed and relearned, which can cascade into more queries, which can SIA somewhere else. One flapping prefix at a branch can ripple across a continent-wide EIGRP domain. Classic causes of unanswered queries: an overloaded control plane, a congested or lossy WAN link dropping the reply, unidirectional links, or simply a query domain so large that the reply chain is dozens of routers deep.

SIA-Query and SIA-Reply: The Modern Safety Valve

Because tearing down an adjacency over one slow prefix is such a disproportionate response, modern IOS splits the active timer in half. At 90 seconds, the waiting router sends an SIA-Query, essentially "are you alive and still working on this?". A healthy-but-busy neighbor answers with an SIA-Reply, which proves the neighbor is up and keeps the adjacency alive while the real reply is still in flight. A router can extend this up to three times. Only a neighbor that fails to answer even the SIA-Query gets reset. The counters for both packet types are visible in the show ip eigrp traffic output above; in a healthy network they should read 0/0.

You can also tune or disable the timer, in either syntax:

R3(config)# router eigrp 100
R3(config-router)# timers active-time 1

R2(config)# router eigrp PINGLABZ
R2(config-router)# address-family ipv4 unicast autonomous-system 100
R2(config-router-af)# topology base
R2(config-router-af-topology)# timers active-time 1

R2# show ip protocols | include Active Timer
      Active Timer: 1 min

Shortening the timer makes SIA detection faster but punishes slow WAN paths; timers active-time disabled waits forever, which just trades a visible failure for an invisible one. Most networks should leave it at 3 minutes and fix the design instead.

Designing Query Boundaries (the Real Fix)

You do not solve SIA by tuning timers. You solve it by making the query domain small. Two tools do almost all of the work:

This is also a fair framing for protocol selection: OSPF floods LSAs but never holds a route hostage waiting for neighbors, so its failure domain is bounded by area design instead (see EIGRP vs OSPF and the OSPF guide). EIGRP scales beautifully, but only when someone deliberately draws the query boundaries.

Anatomy of a Query Storm

To feel why this matters at scale, walk a realistic cascade. A retail network: one hub, 400 spokes, no summarization, no stubs. A branch loses its LAN prefix when a switch reboots. The branch router has no feasible successor for that /24 (it was connected), so it marks the route Active and queries the hub. The hub's successor for that prefix was the branch itself, so the hub cannot answer from its own table: it propagates the query to its other 399 neighbors. Each spoke looks up the prefix, finds its successor is the hub, and must in turn consider its own alternatives before replying. Four hundred queries fan out; four hundred replies must come back before the hub can answer the original branch.

Now add one spoke with a saturated WAN circuit. Its reply sits in a queue behind bulk traffic. At 90 seconds the hub sends it an SIA-Query; if even that exchange cannot complete, at 180 seconds the hub resets that adjacency, flushing every route through it, generating queries for those prefixes, each with its own three-minute clock. This is how a single switch reboot in one branch becomes a multi-site event. The fix is unglamorous and structural: summarize each branch to one block at the hub, mark every spoke as stub, and the original query dies at the first hop. The same event in that design touches exactly two routers.

This scenario is also the strongest argument for keeping feasible successors plentiful: a lost route with a feasible successor generates no query at all. Metric design (consistent delay values, covered in the K values guide) is quietly an SIA-prevention tool.

Monitoring and Baselines

SIA prevention is measurable before the first incident. Three habits:

• Baseline query counters. show ip eigrp traffic on your hubs, sampled weekly. Queries per week should be a small, boring number; a rising trend means a flapping prefix or an eroding design margin. SIA-Query counters above zero deserve a ticket even if nothing failed.
• Read the event log after any incident. show ip eigrp events keeps a rolling in-memory history of DUAL decisions (route state changes, metric updates, query origins) with millisecond timestamps. It answers "what exactly happened at 03:12" long after the debugs you did not have running would have.
• Log and alert on the strings that matter: %DUAL-3-SIA, retry limit exceeded, and any NBRCHANGE burst on hub routers. An SIA event that resolves itself is still a warning shot.

Troubleshooting a Live SIA Event

When %DUAL-3-SIA or %DUAL-5-NBRCHANGE ... retry limit exceeded shows up, work the chain:

• show ip eigrp topology active on the router that logged it. Neighbors still owing a reply are flagged r. That tells you which direction to walk.
• Hop to that neighbor and run the same command. Keep following the r flags until you find the router that is not answering; the problem lives there or on the link to it.
• On the culprit, check CPU, memory, and the interface queues. A router too busy to answer queries is usually too busy for other things you can measure.
• Look at the prefix itself. A route that flaps every few minutes multiplies query load; find and fix the flapping interface. If routes are disappearing for non-obvious reasons, cross-check with troubleshooting EIGRP missing routes.

Key Takeaways

• Queries only happen when a route with no feasible successor dies. Networks rich in feasible successors barely query at all, which is another reason metric design matters.
• A route is stuck-in-active when any neighbor fails to reply within the active timer (3 minutes by default), and the penalty is an adjacency reset that can cascade.
• SIA-Query and SIA-Reply at the half-timer mark protect healthy-but-slow neighbors from that reset. Watch their counters in show ip eigrp traffic.
• Summarization and stub routing are the real defenses, because they stop queries from propagating in the first place. Timers are a tourniquet, not a cure.
• During an event, show ip eigrp topology active and the r flag let you walk the query chain straight to the router that owes a reply.

The query process is EIGRP's personality: brilliant when the topology gives it options, fragile when a flat design lets one question travel too far. Design the boundaries and it stays brilliant. The rest of the protocol's machinery is mapped out in the EIGRP complete guide.