EIGRP Path Computation

[UncleJP]

I stumbled upon this practice question while studying for the ENCOR exam: 

How does an EIGRP router indicate that a path computation is required for a specific route?

a. EIGRP sends out an EIGRP update packet with the topology change notification flag set.
b. EIGRP sends out an EIGRP update packet with a metric value of zero.
c. EIGRP sends out an EIGRP query with the delay set to infinity.
d. EIGRP sends a route withdrawal, notifying other neighbors to remove the route from the topology table.

Answer: C

I cannot find information anywhere about this answer (perhaps I am not asking the right questions). When EIGRP sends out a query with the delay set to infinity, would it be the same as waiting to see how long it takes for it to come back to the router? Any and all feedback and input would be greatly appreciated. 

[Martin L · Accepted solution]

When there is no feasible successor in table EIGRP will send Queries to all its neighbors. Then he waits for replies.
I think "infinity" as metric is used and that is a characteristic of distance-vector protocol like RIP and EIGRP. Those protocols will use infinity (aka unreachable) to let us know that network has been lost. EIGRP will send Query with metric of "infinity"
not sure why the delay field is used.  I have seen in debugs and packet captures "infinity" showed up in messages to inform us about network/route/prefix loss and withdraw.  Perhaps only delay field (as variable field) is flexible or large enough to indicate metric of infinity, aka 4 billion.  

[Giuseppe Larosa · Accepted solution]

Hello @UncleJP ,

EIGRP uses DUAL Diffusive Update Algorithm.

if the route for a prefix is lost and no back up route exists that satisfy the feasibility condition FC ( no feasible successor exists) the local node goes active for the prefix.

The local router will send out all interfaces a Query message with infiniite metric asking the neighbors to participate in finding an alternatate path if one exists.

The local node starts a stuck in active timer of 3 minutes waiting to receive answers to its own Query message for the prefix.

This is peculiar of EiGRP finding a new path becomes a collective job distributed among all the EIGRP neighbors of the original node that sent the Query.

Each of the network device receiving the query will answer to the Query if they have an alternate path not going via the query sender, if not having an alternate path they will go active for the same prefix and each of them will send its own Query to its own EIGRP neighbors.

To limit the scope of EiGRP query the network designer can use:

route filters so that it is possible to answer back with infinite metric telling the specific prefix is lost

summary routes (aggregation of routes possible at interface level with EiGRP) again if a component route is missing this device is allowed to answer back with reply with infinite metric stopping the query propagation

in bug and spoke topologies all the spoke routers should be configured as EiGRP stub routers. EIGRP stub routers cannot have other eiGRP routers downstream so actually the hub router(s) should not send Query to them. In any case if a Query is received by an EiGRP stub router it answers back with a Reply with infinite metric.

Controlling and limiting the query scope is very important to build a scalable internetwork when using the EIGRP routing protocol.

Hope to help

Giuseppe

[UncleJP · Accepted solution]

***Note

If anyone has this same question, I suggest that you read @Giuseppe Larosa 's post first, then @Martin L 's post 2nd. They fit together well. 

Thanks to both of you for the helpful responses.