If you’ve ever been in a networking interview, a question that frequently comes up is “what’s your understanding of stuck in active?” – well here’s an explanation.
When EIGRP networks are fully converged they are in the passive state.
R1#show ip eigrp topology EIGRP-IPv4 VR(bottom) Topology Table for AS(100)/ID(10.1.1.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 99.99.99.0/24, 1 successors, FD is 1735257878 via 10.1.1.2 (1735257878/163840), Serial1/0
This is on a per destination basis. If for some reason the destination is no longer reachable then the status of the network transitions to active.
At this point the router queries its neighbour to determine if its neighbour still has a route to the destination. It must wait for a reply before it can complete its diffusing computation and determine a new best path.
If the neighbour has also lost its path to the destination, then it must also transition to an active state and wait for a response from its neighbour. Consequently the original neighbour becomes dependant on it’s neighbour and its neighbour’s neighbour.
If the neighbours fail to respond (perhaps due to a an overloaded router, congestion, or an excessively large network) then the router becomes stuck in an active state.
Fortunately EIGRP has a few ways to deal with this issue. When a query is first sent out an active timer is started. This has a default value of 3 minutes, but can be changed with the timers active-time command.
R1(config-router-af-topology)#timers active-time ? <1-65535> active state time limit in minutes disabled disable time limit for active state
For older versions of EIGRP if a reply is not received within the designated time, then the destination network is put into the stuck in active state and the neighbour adjacency is torn down. This is not ideal, as all networks learnt from the neighbour are flushed from the routing table.
For more recent versions of EIGRP, if the neighbour does not reply within half the active timer (i.e. 90 seconds) then the router will send the neighbour a SIA-Query asking if the neighbour is still working on the query. The neighbour should immediately reply with an SIA-Reply packet stating if it is still waiting for a reply from its neighbour. If it is then the active timer is reset, giving the neighbour more time.
This process can repeat three times, allowing three SIA-Query packets to be sent. If there is still no reply the neighbour adjacency is dropped.
Key point: This process can extend along the path to the router that is the source of the SIA problem. In this case there is a good chance the router will not respond to the SIA-Query packet for the same reason it is not responding with a regular reply to a query. If this is the case the active timer will not be reset and the adjacency will therefore be dropped on this router first.
Here is an example of Stuck In Active on a simple three router topology.
Router 3 loses it’s loopback 0 network 3.3.3.3/24 (it is shut down). At this point router 3 queries router 2 for an alternative path, and router 2 queries router 1 for an alternative. However we have applied an access-list on the inbound direction from router 1 to router 2 denying all EIGRP packets. Consequently router 2 does not get a reply to the query it sent router 1.
Extended IP access list no-eigrp 10 deny eigrp any any (237 matches) 20 permit ip any any
However if we apply the access-list inbound this will also stop the EIGRP hello messages and the adjacency will be torn down after 15 seconds. To force a SIA-Query to be sent the neighbour must have waited half the active timer i.e. 90 seconds. To keep the adjacency up for more than 15 seconds and at least 90 seconds we need to change the hold timers between router 1 and router 2 before applying the access list.
R1#show run | s eigrp
router eigrp sia
!
address-family ipv4 unicast autonomous-system 100
!
af-interface FastEthernet0/0
hold-time 600
exit-af-interface
<snip>
R1#show ip eigrp neighbors
EIGRP-IPv4 VR(sia) Address-Family Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 1.2.1.2 Fa0/0 599 00:05:54 180 1080 0 14
R2#show run | s eigrp
router eigrp sia
!
address-family ipv4 unicast autonomous-system 100
!
af-interface FastEthernet0/1
hold-time 600
exit-af-interface
<snip>
R2#show ip eigrp neighbors
EIGRP-IPv4 VR(sia) Address-Family Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 1.2.1.1 Fa0/1 597 00:07:27 1 4500 0 19
1 2.3.2.3 Fa0/0 12 01:15:31 84 504 0 5
If we now re-apply the access-list and shut down the loopback we can force a SIA-query to be generated by router 2 after 90 seconds
R2#show ip eigrp neighbors
EIGRP-IPv4 VR(sia) Address-Family Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 1.2.1.1 Fa0/1 482 00:17:20 1 5000 2 19
1 2.3.2.3 Fa0/0 14 01:25:24 79 474 0 8
R2#show ip eigrp topology
EIGRP-IPv4 VR(sia) Topology Table for AS(100)/ID(1.2.1.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 1.2.1.0/29, 1 successors, FD is 13107200
via Connected, FastEthernet0/1
A 3.3.3.0/24, 1 successors, FD is Infinity, Qqr
1 replies, active 00:01:47, query-origin: Successor Origin, retries(1)
Remaining replies:
via 1.2.1.1, r, FastEthernet0/1
SIA-Stuck: 1 peers
Peers:
via 1.2.1.1, s, FastEthernet0/1
P 2.3.2.0/29, 1 successors, FD is 13107200
via Connected, FastEthernet0/0
The Traceroute Blog 