CCNP ROUTE: 6. EIGRP Going Active state - Query/Reply messages

When EIGRP removes a successor route and no FS route exists, the router begins a process by which the router discovers if any loop-free alternative routes each reach that prefix.
This process is called going active on a route.
Routes for which the router has a successor route, and no failure has yet occurred, remain in a passive state.
Routes for which the successor route fails, with no feasible successor routes, move to an active state.

The router sends EIGRP Query messages to every neighbor except the neighbor in the failed route.
The Query asks a neighbor whether that neighbor has a loop-free route for the listed prefix/length.
The neighbor considers itself to have a loop-free route if that neighbor is passive for that prefix/length. If so, the neighbor 1) sends an EIGRP Reply message, telling the
original router that it does indeed have a loop-free route and 2) does not forward the Query.
If the neighbor itself is active on this route, that neighbor 1) floods EIGRP Query messages to its neighbors and 2) does not immediately send an EIGRP Reply back to the original router–instead waiting on replies to its own set of Query messages.

In the figure, we will shut down R7's interface to R6, so R6 would search for an alternate route using Query/Reply messages with its neighbors, R4 and R5.
R6 has no feasible successor for the network to R7:

R6#show ip eigrp topology
...
P 172.16.0.8/30, 1 successors, FD is 2169856
        via Connected, Serial0/1

R7(config)#interface serial 0/0
R7(config-if)#shutdown

R6#debug eigrp packets query reply ack
R5#debug eigrp packets query reply ack
R4#debug eigrp packets query reply ack

R6#
*Mar  1 00:17:57.891: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: holding time expired
*Mar  1 00:18:14.575: EIGRP: Enqueueing QUERY on FastEthernet0/1 iidbQ un/rely 0/1 serno 13-13
*Mar  1 00:18:14.579: EIGRP: Enqueueing QUERY on FastEthernet0/1 nbr 172.16.0.6 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 13-13
*Mar  1 00:18:14.583: EIGRP: Sending QUERY on FastEthernet0/1
*Mar  1 00:18:14.587:   AS 1, Flags 0x0, Seq 22/0 idbQ 0/0 iidbQ un/rely 0/0 serno 13-13
*Mar  1 00:18:14.591: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 13-13
*Mar  1 00:18:14.595: EIGRP: Enqueueing QUERY on Serial0/0 nbr 172.16.0.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 13-13
*Mar  1 00:18:14.603: EIGRP: Sending QUERY on Serial0/0 nbr 172.16.0.2
*Mar  1 00:18:14.603:   AS 1, Flags 0x0, Seq 23/17 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 13-13
*Mar  1 00:18:14.647: EIGRP: Received ACK on FastEthernet0/1 nbr 172.16.0.6
*Mar  1 00:18:14.647:   AS 1, Flags 0x0, Seq 0/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Mar  1 00:18:14.655: EIGRP: Received ACK on Serial0/0 nbr 172.16.0.2
*Mar  1 00:18:14.655:   AS 1, Flags 0x0, Seq 0/23 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Mar  1 00:18:14.659: EIGRP: Received REPLY on Serial0/0 nbr 172.16.0.2
*Mar  1 00:18:14.663:   AS 1, Flags 0x0, Seq 18/23 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar  1 00:18:16.243: EIGRP: Received REPLY on FastEthernet0/1 nbr 172.16.0.6
*Mar  1 00:18:16.247:   AS 1, Flags 0x0, Seq 20/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

Until all Reply messages are received from the neighbors, the route is marked as Active (A), the Query is marked as sent (Q) and the R6 waits for Reply messages (r) from its two neighbors:
R6#show ip eigrp topology
...
A 172.16.0.8/30, 1 successors, FD is Inaccessible, Q
    2 replies, active never, query-origin: Local origin
      Remaining replies:
         via 172.16.0.2, r, Serial0/0
         via 172.16.0.6, r, FastEthernet0/1

Having no feasible successor for 172.16.0.8/30, R6 sends Query messages to its neighbors asking for a loop-free route to this network.

None of the neighbors has any route to 172.16.0.8/30, so they both send Query messages further (in this case - to each other), waiting for a Reply to their own Queries before replying to R6.
We can see this on R5, which further sends Query messages to R4.

R5 receives the Query from R6 on Fa0/0, asking for a backup to 172.16.0.8/30:
R5#
*Mar  1 00:18:15.931: EIGRP: Received QUERY on FastEthernet0/0 nbr 172.16.0.5
*Mar  1 00:18:15.931:   AS 1, Flags 0x0, Seq 22/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar  1 00:18:15.931: EIGRP: Enqueueing ACK on FastEthernet0/0 nbr 172.16.0.5
*Mar  1 00:18:15.931:   Ack seq 22 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Mar  1 00:18:15.935: EIGRP: Sending ACK on FastEthernet0/0 nbr 172.16.0.5
*Mar  1 00:18:15.939:   AS 1, Flags 0x0, Seq 0/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0

R5 does not immediately send a Reply to R6, instead it asks his neighbor, R4, about that network, using Serial0/1 to R4:
*Mar  1 00:18:15.943: EIGRP: Enqueueing QUERY on Serial0/1 iidbQ un/rely 0/1 serno 15-15
*Mar  1 00:18:15.947: EIGRP: Enqueueing QUERY on Serial0/1 nbr 172.16.0.13 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 15-15
*Mar  1 00:18:15.955: EIGRP: Sending QUERY on Serial0/1 nbr 172.16.0.13
*Mar  1 00:18:15.955:   AS 1, Flags 0x0, Seq 17/16 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 15-15

R5 receives a Reply from R4, in which R4 says it has no routes to 172.16.0.8/30:
*Mar  1 00:18:16.159: EIGRP: Received REPLY on Serial0/1 nbr 172.16.0.13
*Mar  1 00:18:16.159:   AS 1, Flags 0x0, Seq 22/19 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar  1 00:18:16.159: EIGRP: Enqueueing ACK on Serial0/1 nbr 172.16.0.13
*Mar  1 00:18:16.159:   Ack seq 22 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Mar  1 00:18:16.171: EIGRP: Sending ACK on Serial0/1 nbr 172.16.0.13

Having an answer to all Query messages sent (in this case only to R4), R5 replies to R6 saying it has no route to 172.16.0.8/30:
*Mar  1 00:18:16.179: EIGRP: Enqueueing REPLY on FastEthernet0/0 nbr 172.16.0.5 iidbQ un/rely 0/1 peerQ un/rely 0/1 serno 17-17
*Mar  1 00:18:17.527: EIGRP: Sending REPLY on FastEthernet0/0 nbr 172.16.0.5
*Mar  1 00:18:17.531:   AS 1, Flags 0x0, Seq 20/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 17-17
*Mar  1 00:18:17.587: EIGRP: Received ACK on FastEthernet0/0 nbr 172.16.0.5

Same process runs on R4. All Query/Reply packets between the three routers are acknowledged with an ACK packet. Reliable Transport Protocol (RTP) is used.

The IOS sets a time limit in which the router expects replies to all the queries it has sent (by default 3 mins). Routes for which a router does not receive a Reply within the defined timer are called Stuck-in-Active (SIA) routes.
Beginning with IOS version 12.2, the router sends a SIA-Query message to each neighbor who did not yet replied to the Query, after half of the configured timer expired (90 seconds).
If the neighbor sends back a SIA-Reply, this means that he is still waiting for replies to his own Query messages, so the neighborship is kept.
If the neighbor does not respond to the SIA-Query, then the neighborship fails.