Understanding EIGRP Queries

Despite claims that EIGRP is a "hybrid" routing protocol, it is in fact a distance-vector routing protocol (Cisco has more recently ceded to using the term "advanced distance vector" in place of "hybrid"). A prime example of this behavior can be observed by examining EIGRP's route querying process. Queries are used to ask neighbors whether they have a path to a route which was recently lost. This is in contrast to a link-state routing protocol, wherein every router already has a complete picture (SPF tree) of its link-state area.

EIGRP's query process is simple in concept, yet can appear complicated when observed in operation on a live network. To better understand the query process, we'll examine what happens when the primary Internet uplink is lost in the topology below.

Under normal conditions, R1 has the primary uplink toward the Internet and redistributes a static default route (0.0.0.0/0) into EIGRP. R2 has a back-up Internet uplink, which is redistributed into EIGRP with a much higher (less favorable) metric than that of R1's as it should only be used when the uplink through R1 is down. Because the metric for this route is so high, it does not qualify as a feasible successor on any neighbor. Also, note that R5 has been configured as a stub router as it has only one path to the rest of the network.

While I've attempted to break the process down into logical steps or phases, the reader should be aware that queries and replies and handled independently on each router as they are received, without regard to the state of neighbors. Additionally, although it seems very drawn-out here, the entire process takes less than second to fully converge as tested.

This packet capture contains all EIGRP traffic sent across all five EIGRP links during convergence. Readers are encouraged to follow along in the capture as they read.

Step 1

R1's uplink to the Internet fails, and it loses its route for 0.0.0.0/0. R1 sends a query to each of its neighbors asking for a route to 0.0.0.0/0. R3 and R4 each send an acknowledgment to confirm that they received the query.

Because the queries were received from the successor for the route (indicating that the route is no longer valid) and there is no feasible successor, R3 and R4 both discard their route for 0.0.0.0/0 through R1.

Step 2

R3 and R4 both relay the queries to all of their neighbors. R3 queries R2 and R4 (but not R5, because R5 is a stub router). R4 queries R3.

Note that the exchange of queries between R3 and R4, although redundant, is necessary as no single router understands the overall topology beyond its own connected neighbors (a limitation inherent to distance-vector routing).

Notice that a query is also made from R3 to R1 at this point (packet #24). This appears to be the result of R3 processing the query from R4 slightly quicker than the query from R1, for whatever reason. This query is extraneous and unnecessary, but included here for the benefit of people following along with the provided packet capture. R4 does not relay to R1 the query it receives from R3.

Step 3

Next, we can see all the routers reply to the queries they received. R3 informs R4 it has no route for 0.0.0.0/0, and R4 informs R3 it has no route either. R1 replies to R3 that it (obviously) has no route as well. R2, however, does have a route to 0.0.0.0/0, it's uplink to the Internet. This reply is visible in packet #28 of the capture.

The only two outstanding queries (those which have not yet been answered) at this point are the two original queries from R1 to R3 and R4.

Step 4

R3 has a learned of a new path to 0.0.0.0/0 from the reply sent by R2. First, it sends a poison reverse update to R2 for this route. Second, it answers the original query from R1 with the new path to 0.0.0.0/0. Finally, it sends a normal update to all of its neighbors (other than R2) informing them of the new default route via R2.

Step 5

After having learned of the new route via R3, R4 also sends a reply and update to R1. At this point, all queries have been answered.

R1 and R4 both send a poison reverse for 0.0.0.0/0 to R3 in response to the updates.

Now, just as we thought the network was about to settle down, we see a new query from R5, the stub router. The query is for the new 0.0.0.0/0 route which R5 just learned from R3. (Remember that stub routers should not receive queries, but they are free to send them.)

I could not find any documentation concerning this phenomenon, although it appears to serve in place of a normal poison reverse update (since stub routers generally may not send updates). If anyone can shed some light on this, I'd be happy to hear it.

Step 6

To wrap things up, R1 sends an update (_not_ a poison reverse) to R4 indicating that it to now has a path to 0.0.0.0/0. R3 responds to R5's query with a reply indicating the route to 0.0.0.0/0 is as previously advertised.

As you can see in the packet capture, the elapsed time from the first query to the final acknowledgment is only about 850ms (and that's in a lab using emulated routers).