EIGRP Query - Query

danb83

Quick question about EIGRP Query messages.

If an EIGRP router loses its best path to a network, and it doesn't have a Feasible Successor to that network, it sends out a Query message to see if its neighbors have another path to that network.

My question then, is how could a neighbor have a path to network, and not have already told its neighbor router. Would that route not already be in the Topology table, even if it didn't qualify as a Feasible Successor?

cheers

DPG

It's basically EIGRP making one last check for a valid route before removing it from the topology table.

Fitzi

The only reason I can think of is potentially in a large network where a less specific route (or even a floating static route) might be present on a router many hops away from the router which is about to send the query. In this case it might be taking a long time for the less specific/floating static to be propagated which in that time a query message has been sent.

This assumes that there is some filtering or route tracking involved because it is my understanding that the topology table contains ALL learned routes from ALL routers and if this is the case the less specific route would (should?) already be learned by the router about to send the query (unless it was filtered somewhere on the path or contingent on a tracking object for injection etc).

Also remember that once the query is sent, the router will wait (sometimes infinitely) for all the receiving routers to reply and if there is no reply received the router becomes stuck in active.

networker050184

EIGRP does not keep a synchronized database across all routers like OSPF does (in an area anyway). It only knows what it's directly connected neighbors tell it. It doesn't know what it's neighbors neighbor knows. Hence the "routing by rumor" nickname. So there are scenarios, however unlikely in normal operation, where a router upstream may have a route to a prefix still.

ParDigital

Correct me if im wrong, but dont eigrp routers report only successors and feasible successors? In light of that, I believe the query process is to find routes which did not initially qualify as feasible successors.
The reason that the new route, which was found due to queries, now qualifies as a successor where it didnt before is because of poison reverse injection. The previous undesirable route has a better metric than the failed, poisoned route, so it is then inserted in to the routing table.
I could be off on some details here, but I believe this to be the gist of it.

albersj

EIGRP routers advertise what is in their routing table -- i.e. successors, but not necessarily feasible successor (FS). FS will only be in routing table if variance is configured (to allow un-equal cost load balancing).

I'm not 100% sure on this, but in ref to question -- "how could a neighbor have a path to network, and not have already told its neighbor router." RTR-A advertises Net-X to its neighbor. The neighbor may have another route to Net-X (not via A) in topology table, BUT it won't put it in routing table because the best route is through RTR-A (i.e. nei won't advertise it to A). When RTR-A loses Net-X, the neighbor loses its best route to Net-X and moves the FS to be the successor in its routing table..

dppagc

successor - Route with best distance to the destination

Feasible successor - Routes that meet the condition advertised dist < feasible distance that are installed in the routing table.

Routes in which AD >= FD are not installed because there is a POSSIBILITY of routing loops.

If successor and feasible successor goes down, these routes are queried to see if there are possible routes to the destination. Obviously these are not the best routes.

james43026

ParDigital wrote: »

Correct me if im wrong, but dont eigrp routers report only successors and feasible successors? In light of that, I believe the query process is to find routes which did not initially qualify as feasible successors.
The reason that the new route, which was found due to queries, now qualifies as a successor where it didnt before is because of poison reverse injection. The previous undesirable route has a better metric than the failed, poisoned route, so it is then inserted in to the routing table.
I could be off on some details here, but I believe this to be the gist of it.

You pretty much summed it up. The poison reverse part, is slightly off. A poison reverse only happens, when there is a topology change (the interface being used to reach a network changes for a router). Or a query is sent out, and a reply (reachable) is sent back to the querying router. Poison reverses are also used during EIGRP startup as a way of acknowledging route updates, and preventing routing loops.

danb83

Fitzi wrote: »

...because it is my understanding that the topology table contains ALL learned routes from ALL routers and if this is the case the less specific route would (should?) already be learned by the router about to send the query

This is also my understanding. So even if a router receives a route that does not become the Successor or FS, it can still be viewed using "show ip eigrp topology all-links".

So I was wondering then how a Query could return a valid route, as the router should in theory already know about all possible routes?