What is stuck in active, what causes it, and how do you fix it for good?
Show the answer
Say this first
A route is stuck in active when the router has sent queries and a neighbor has not replied within the active timer, 3 minutes by default. Modern IOS sends that neighbor an SIA-Query halfway through; a neighbor that answers with an SIA-Reply is kept, a neighbor that stays silent is reset, and every route through it is lost. The usual causes are queries travelling too far and a lossy or overloaded path. The lasting fix is to bound queries with stub routers and summarization and repair the bad link, not to raise the timer.
Go deeper
The timeline with default settings
- 0 s: route goes active, queries sent.
- 90 s (half the active timer): SIA-Query sent to each neighbor that has not replied.
- SIA-Reply received: the neighbor is alive and still working on it, so the router keeps waiting.
- No SIA-Reply: the neighbor is reset:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.14.4 (GigabitEthernet0/0/2) is down: stuck in activeFinding the real culprit
The router that logs the reset is usually not the problem. Follow the chain:
show ip eigrp topology activeon the router that logged it. Note the neighbor markedrunder "Remaining replies".- Log in to that neighbor and run the same command. If it is also active and waiting on someone else, move again.
- The end of the chain is the router that cannot answer: a congested or lossy link, a one-way link, a
high CPU, or a neighbor that keeps retransmitting (
Q Cntabove 0 inshow ip eigrp neighbors).
The real fixes
- Stub routers on branches and access: the hub never queries them.
- Summarization at distribution and hubs: routers that only hold the summary answer queries for specifics immediately.
- Route filtering so routers do not hold prefixes they do not need.
- Fix the path: errors, drops, wrong
bandwidthvalues that throttle EIGRP pacing.
They will ask next
Why not just raise the active timer?
It hides the design problem and makes convergence slower when a reply is truly lost. With SIA-Query and SIA-Reply, a neighbor that is busy but alive is no longer reset anyway, so the timer is rarely the thing to change.
How did stuck in active behave before SIA-Query existed?
The router simply waited the full active timer and then reset the neighbor that had not replied, even if that neighbor was healthy and was itself waiting on someone further away. Healthy adjacencies near the querier were torn down for a problem somewhere else.
Traps
- Blaming the neighbor that was reset. Usually it was waiting on someone further down the chain.