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

Stuck-in-active is the most infamous failure mode EIGRP has. One lost route in a far corner of the 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 builds on the DUAL concepts in the EIGRP complete guide, with real query and reply packets from a CML lab.

What almost nobody shows you is a route actually sitting in Active with a reply outstanding, because it is awkward to reproduce: break the link and EIGRP tears the adjacency down instead, and a dead neighbor counts as an answer. That capture is below, on IOS XE 17.18.2 in CML, with the reason modern IOS XE usually resets the neighbor before it prints %DUAL-3-SIA.

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.

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

• Replies immediately if it has no knowledge of the prefix, or has its own valid path that does not depend on the querying router.
• Propagates the query if the lost route was its successor too, then waits for those 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, so 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. Put plainly, stuck-in-active is what happens when there is no feasible successor and somebody does not answer, so if you are solid on how DUAL decides a backup path is loop-free, you already know why some failures generate zero queries and others a flood.

The Lab This Was Captured On

The Active and SIA captures come from a three-router chain in CML: R1 - R2 - R3, all iol-xe nodes on IOS XE 17.18.2, EIGRP AS 100, no auto-summary. R1 originates 192.168.100.0/24 on Loopback1. R2 sits in the middle, Et0/0 toward R1 on 10.0.12.0/30 and Et0/1 toward R3 on 10.0.23.0/30, with the active timer set to one minute (timers active-time 1, the minimum) so the lifecycle fits in one console session. Healthy state first:

R3# show ip route eigrp
D     192.168.100.0/24 [90/435200] via 10.0.23.2, 00:00:35, Ethernet0/0

R2# show ip eigrp topology 192.168.100.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(2.2.2.2) for 192.168.100.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
  Descriptor Blocks:
  10.0.12.1 (Ethernet0/0), from 10.0.12.1, Send flag is 0x0
      Composite metric is (409600/128256), route is Internal

Note the shape of that entry: one successor, no second descriptor block, so no feasible successor. That is the precondition for a query.

Watching a Query Live

In an earlier lab, R3 loses a connected network (we shut its Loopback10, which carries 10.1.0.0/24). With debug eigrp packets query reply 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? At the time of this capture R3 was summarizing 10.1.0.0/22 toward R1, so R1 never knew the /24 existed, had nothing to recompute, and replied instantly. We come back to that, because it is the single most useful fact in this article.

The active state itself is 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 a neighbor still has not replied when the timer expires, the router declares the route stuck-in-active, logs %DUAL-3-SIA, and resets that adjacency. That reset is the brutal part: every route through that neighbor is flushed and relearned, which cascades 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 an unanswered query: an overloaded control plane, a congested or lossy WAN link dropping the reply, a unidirectional link, or a query domain so large the reply chain is dozens of routers deep.

Catching a Route in Active State

To hold a route in Active long enough to photograph it you must starve the reply while keeping the adjacency alive, and that distinction is the whole trick. In the lab, an ACL on R2's Et0/1 permits R3's multicast EIGRP (224.0.0.10, so hellos and queries still flow) but denies R3's unicast EIGRP, which is what replies, acks and SIA-replies ride on. R2's uplink is then shut, so R2 must query R3. R3 answers; R2 never hears it.

R2# show ip eigrp topology active           (active 00:00:09)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
A 192.168.100.0/24, 0 successors, FD is 409600, Q
    1 replies, active 00:00:09, query-origin: Local origin
        via 10.0.12.1 (Infinity/Infinity), Ethernet0/0
      Remaining replies:
         via 10.0.23.1, r, Ethernet0/1      <== 'r' = still waiting on R3's REPLY

State A with 0 successors is a router that cannot compute a path on its own. query-origin: Local origin says R2 started this query rather than relaying somebody else's, the old successor reports (Infinity/Infinity), and under Remaining replies exactly one neighbor is listed. That r flag is the most important character in EIGRP troubleshooting: it names the router that owes you an answer.

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

Because tearing down an adjacency over one slow prefix is so disproportionate, modern IOS splits the active timer in half. At the halfway mark the waiting router sends an SIA-Query: "are you alive and still working on this?". A healthy-but-busy neighbor answers with an SIA-Reply, keeping the adjacency alive while the real reply is still in flight, up to three times. Only a neighbor that fails to answer even that gets reset. With the active timer at one minute, it engages about thirty seconds in:

R2# show ip eigrp topology active           (active 00:00:39)
A 192.168.100.0/24, 0 successors, FD is 409600, Qq
    1 replies, active 00:00:39, query-origin: Local origin, retries(1)
        via 10.0.12.1 (Infinity/Infinity), Ethernet0/0
        via 10.0.23.1 (Infinity/Infinity), rs, q, Ethernet0/1, serno 11   <== 'rs' = reply + SIA status

Three things changed and all three are diagnostic. The neighbor flags went from r to rs, so an SIA-Query is now outstanding on top of the original query. The route flags went from Q to Qq. And retries(1) appeared. Seeing rs in production means an adjacency roughly one timer away from reset, with about half the active timer left to find out why that neighbor is silent.

The timer is tunable 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, trading a visible failure for an invisible one. One minute is the floor. Most networks should leave it at 3 minutes and fix the design instead.

Why You May Never See %DUAL-3-SIA

Here is the finding that contradicts most of what is written on this topic. In the lab above, with the reply permanently blocked and the active timer at its minimum, R2 never logged %DUAL-3-SIA at all. It logged this:

*Jul 20 06:50:13: %DUAL-5-NBRCHANGE: Neighbor 10.0.12.1 (Ethernet0/0) is down: interface down
*Jul 20 06:50:59: %DUAL-5-NBRCHANGE: Neighbor 10.0.23.1 (Ethernet0/1) is down: retry limit exceeded
*Jul 20 06:51:00: %DUAL-5-NBRCHANGE: Neighbor 10.0.23.1 (Ethernet0/1) is up: new adjacency

Two independent clocks are racing. The active timer runs 60 seconds here before SIA can be declared. Separately, EIGRP's reliable transport gives up after 16 unacknowledged retransmissions, which on this link landed at roughly 46 seconds. The retry limit won, the adjacency was reset, that reset resolved the Active route as an implicit reply, and the classic %DUAL-3-SIA-1 ... Cleaning up message never got a chance to print.

So do not treat the absence of %DUAL-3-SIA as proof you have no query-scope problem. On current IOS XE an unanswered query often surfaces as a retry limit exceeded reset instead: same root cause, same damage, different log string. Alert on both. Getting the literal SIA-3 message needs the active timer to win, which takes a longer reply chain, an RTO inflated by real WAN latency, or a longer active-time.

Designing Query Boundaries (the Real Fix)

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

Both belong on the spokes and at the summarization boundary, not on the router that logged the error:

router eigrp 100
 eigrp stub connected summary

interface Ethernet0/1
 ip summary-address eigrp 100 10.1.0.0 255.255.252.0

If your sites ride an MPLS L3VPN and are dual-homed to two PEs, the same conversation extends to tagging routes with the site they came from so a PE refuses to hand a site its own routes back. It is also fair framing for protocol selection: OSPF floods LSAs but never holds a route hostage waiting on neighbors, so its failure domain is bounded by area design (see EIGRP vs OSPF and the OSPF guide). EIGRP scales beautifully, but only when someone draws the query boundaries deliberately.

Anatomy of a Query Storm

Scale it up. A retail network: one hub, 400 spokes, no summarization, no stubs. A branch loses a connected LAN prefix when a switch reboots, so there is no feasible successor and it queries the hub. The hub's successor for that prefix was the branch itself, so it cannot answer from its own table and propagates the query to its other 399 neighbors. Four hundred replies must come back before the hub can answer the branch.

Now add one spoke with a saturated circuit whose reply sits behind bulk traffic. Halfway through the active timer the hub sends it an SIA-Query and its topology output starts showing the rs flags captured earlier. If that exchange cannot complete either, the hub resets the adjacency, flushing every route through it and generating queries for those prefixes, each with its own clock. That is how one switch reboot becomes a multi-site event. Summarize each branch to a single block at the hub, mark every spoke as stub, and the same event touches two routers. It is also the argument for keeping feasible successors plentiful, since a lost route with one generates no query at all, which makes metric design (consistent delay values, covered in the K values guide) 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, 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 broke.
• Read the event log after any incident. show ip eigrp events keeps a rolling in-memory history of DUAL decisions with millisecond timestamps, and answers "what happened at 03:12" long after the debugs you did not have running would have.
• Alert on the strings that matter: %DUAL-3-SIA, retry limit exceeded, and any NBRCHANGE burst on a hub. 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, and rs once an SIA-Query has gone out to them.
• Hop to that neighbor and run the same command. Follow 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 interface queues. A router too busy to answer queries is usually too busy for other things you can measure.
• Check the path both ways. From the querying side, a reply that was sent but never arrived looks identical to one never sent, which is exactly what this article's lab demonstrates. An ACL, a unidirectional fault or a policer catching unicast control traffic all produce it.
• Look at the prefix, because a route flapping every few minutes multiplies query load. If routes vanish for non-obvious reasons, cross-check with troubleshooting EIGRP missing routes.

Gotchas from the Lab

Packet loss alone will not give you an SIA. This is the trap that eats an afternoon if you try to reproduce the failure. The first attempt used link conditioning to add heavy latency and loss to the R2-R3 link:

R2# ping 10.0.23.1 repeat 5 timeout 25
Sending 5, 100-byte ICMP Echos to 10.0.23.1, timeout is 25 seconds:
.!..!
Success rate is 40 percent (2/5), round-trip min/avg/max = 20003/20003/20004 ms

Twenty seconds of round-trip delay, 40 percent success, and still no stuck route. Instead:

R2# show logging | include DUAL|NBR
*Jul 20 05:53:19.775: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.23.1 (Ethernet0/1) is down: Interface PEER-TERMINATION received
*Jul 20 05:53:22.514: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.23.1 (Ethernet0/1) is up: new adjacency
*Jul 20 05:58:05.694: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.23.1 (Ethernet0/1) is down: holding time expired

Loss heavy enough to starve a reply also starves hellos, so the hold timer expires and the adjacency drops. A neighbor going down is treated as an implicit reply for every route it owed an answer on, which resolves the Active route immediately. Bad links therefore produce adjacency churn rather than SIA, and if that is what your logs look like, read why EIGRP neighbors keep dropping instead. The dangerous case is the opposite: a link healthy enough to carry hellos but unable to deliver the reply.

The flags outlive the log message. Given the retry-limit race above, show ip eigrp topology active and its r and s letters are the evidence worth capturing during an incident. Syslog tells you something reset; the flags tell you who was silent. On a healthy router the same command prints nothing but a header, so any persistent output is worth escalating.

Key Takeaways

• Queries only happen when a route with no feasible successor dies, so networks rich in feasible successors barely query at all.
• 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.
• In show ip eigrp topology active, r means that neighbor still owes a reply and rs means an SIA-Query is outstanding to it. Those letters are the diagnostic, captured live above on IOS XE 17.18.2.
• On modern IOS XE an unanswered query often resolves as %DUAL-5-NBRCHANGE ... retry limit exceeded before %DUAL-3-SIA can print. Alert on both strings.
• Packet loss usually produces neighbor flaps, not SIA, because a dead neighbor counts as an implicit reply.
• Summarization and stub routing are the real defenses, because they stop queries propagating at all. Timers are a tourniquet, not a cure.

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. Draw the boundaries and it stays brilliant. The rest of the protocol's machinery, from neighbor formation to metrics, is mapped out in our full EIGRP reference.