Eigrp query never ends? (sia)

kpjungle

Hi,

I had too much time on my hands, and started thinking about EIGRP queries, and how it handles a broken link.

I have attached a scenario which I dont understand how can converge with my current understanding.



Assume all links have the same costs.

Basically, when R1 detects a broken link, it will query its neighbors to see if they have a route. This involves sending a query to R2 and R3 as indicated by the black (and very poorly sketched lines ). These routers (both R2 and R3), figures that they just lost their path to 10.10.10.0/24, and then they Query their neighbors (except the interface which it received the original query on, because of split horizon), that means before they (R2 and R3) reply to R1, they extend the query to R4.

How will it proceed from here, ie. take the query R4 received from R2, since R4, does have a second path (different what Query actually comes first) (through R3), will it answer that immediately? and what then happens when the query from R3 reaches R4, will it then have to extend it back to R2?...

I did this in a lab a while back, and it converges without SIA, so somehow it works. I was thinking that if a router received a query for a route it itself was waiting for would somehow cancel outstanding queries, but that doesnt quite compute.

At a loss

Thanks!

mikearama

It may be different if there's unequal costs, and therefore, no feasible successor, but in the scenerio you describe, I believe there won't be the situation you mentioned... that of a router receiving a query for a route it was waiting for itself on another interface.

Using R2 as the example, it's successor route is the link to R1, and it's feasible successor is the path through R4. So when it gets the news from R1 that the path to 10.10.10.10 is down, the fs is immediately installed as successor. So no query is sent.

Sure, less than a second later, it learns that the route from R4 is also down, and now it has no path at all, so it goes into Active. It got the news from R4, so it sends it's only query out to R1, which replies negatively, and the route is lost from the routing table.

Identical from R3's perspective.

I think.

Edit: The test would be to change the cost of a couple links so there's no fs... then see what happens.

kpjungle

mikearama wrote:

It may be different if there's unequal costs, and therefore, no feasible successor, but in the scenerio you describe, I believe there won't be the situation you mentioned... that of a router receiving a query for a route it was waiting for itself on another interface.

Using R2 as the example, it's successor route is the link to R1, and it's feasible successor is the path through R4. So when it gets the news from R1 that the path to 10.10.10.10 is down, the fs is immediately installed as successor. So no query is sent.

Sure, less than a second later, it learns that the route from R4 is also down, and now it has no path at all, so it goes into Active. It got the news from R4, so it sends it's only query out to R1, which replies negatively, and the route is lost from the routing table.

Identical from R3's perspective.

I think.

Edit: The test would be to change the cost of a couple links so there's no fs... then see what happens.

Well, from R2, it has no FS if the links are all the same. The feasibility criteria states, that in order to be a feasible successor, the AD (advertised distance), must be less than the current FD (feasible distance).. If we assume all links have a cost of 1. The FD to the "broken" link for R2 would be 1, wheres the route the other way, as reported by 1, would be 2 (ad). So it couldnt have the FS.. As far as i can tell at least...

Edit: Forgot to mention. Even if (R2) it did have a FS, when less than a second later it would receive a query, it would, as you say query R1, but as far as i know, R1 cant answer that question until It itself receives word on the query it sent to R3.. There must be some tie breaker somewhere.

Plazma

mikearama wrote:

It may be different if there's unequal costs, and therefore, no feasible successor, but in the scenerio you describe, I believe there won't be the situation you mentioned... that of a router receiving a query for a route it was waiting for itself on another interface.

Using R2 as the example, it's successor route is the link to R1, and it's feasible successor is the path through R4. So when it gets the news from R1 that the path to 10.10.10.10 is down, the fs is immediately installed as successor. So no query is sent.

Sure, less than a second later, it learns that the route from R4 is also down, and now it has no path at all, so it goes into Active. It got the news from R4, so it sends it's only query out to R1, which replies negatively, and the route is lost from the routing table.

Identical from R3's perspective.

I think.

Edit: The test would be to change the cost of a couple links so there's no fs... then see what happens.

Couldn't have explained it better myself.. really I couldn't have

mamono

The explanations are great, good read.

I just want to point out that using a loopback as a downed connection can be misleading. If a loopback were to fail, that is a serious sign that the router has gone bad because of problems with the logical bus of the router.

CCNA Exam Training: Loopback Interfaces
http://www.thebryantadvantage.com/CCNACiscoExamFreeTutorialLoopbackInterface.htm

Chris Bryant wrote:

If the loopback interface on a router is down, that means the router is unavailable as a whole.

APA

kpjungle wrote:

Well, from R2, it has no FS if the links are all the same. The feasibility criteria states, that in order to be a feasible successor, the AD (advertised distance), must be less than the current FD (feasible distance).. If we assume all links have a cost of 1. The FD to the "broken" link for R2 would be 1, wheres the route the other way, as reported by 1, would be 2 (ad). So it couldnt have the FS.. As far as i can tell at least...

Edit: Forgot to mention. Even if (R2) it did have a FS, when less than a second later it would receive a query, it would, as you say query R1, but as far as i know, R1 cant answer that question until It itself receives word on the query it sent to R3.. There must be some tie breaker somewhere.

From what I can see... R4 would be advertising it's routes to R2 so the AD would be 1 as the AD is the distance between R2 and R4 then the FD would be 3 because from R4 it goes through R3 then to R1 (2)

So the AD is still less then or equal to the current FD which means it would be a feasible successor and hence why the topology is converging without SIA...

Hope this makes sense

I'm going to lab it up tonight....

or if you still have it labbed up..... before you drop the lo0 interface on R1 - use the following commands on R2 and R3

sh ip eigrp topology 10.10.10.0

This will show you the topology table and whether there is a FS route available... which there should be, otherwise it shouldn't be converging so quickly or at all for that matter...

kpjungle

A.P.A wrote:

kpjungle wrote:

Well, from R2, it has no FS if the links are all the same. The feasibility criteria states, that in order to be a feasible successor, the AD (advertised distance), must be less than the current FD (feasible distance).. If we assume all links have a cost of 1. The FD to the "broken" link for R2 would be 1, wheres the route the other way, as reported by 1, would be 2 (ad). So it couldnt have the FS.. As far as i can tell at least...

Edit: Forgot to mention. Even if (R2) it did have a FS, when less than a second later it would receive a query, it would, as you say query R1, but as far as i know, R1 cant answer that question until It itself receives word on the query it sent to R3.. There must be some tie breaker somewhere.

From what I can see... R4 would be advertising it's routes to R2 so the AD would be 1 as the AD is the distance between R2 and R4 then the FD would be 3 because from R4 it goes through R3 then to R1 (2)

So the AD is still less then or equal to the current FD which means it would be a feasible successor and hence why the topology is converging without SIA...

Hope this makes sense

I'm going to lab it up tonight....

or if you still have it labbed up..... before you drop the lo0 interface on R1 - use the following commands on R2 and R3

sh ip eigrp topology 10.10.10.0

This will show you the topology table and whether there is a FS route available... which there should be, otherwise it shouldn't be converging so quickly or at all for that matter...

I know its not ideal to use loopbacks, and i wish i could test it out on something where i could yank a cable, but i dont have 4 routers physically available to me

Anyways, I wish it was true and that R2 had a FS, but no dice. Just labbed it up, and it doesnt:

R2:
P 10.10.10.0/24, 1 successors, FD is 2297856
via 192.168.12.1 (2297856/128256), Serial0/0
P 192.168.34.0/24, 1 successors, FD is 2681856
via 192.168.24.4 (2681856/2169856), Serial0/1
P 192.168.12.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0
P 192.168.13.0/24, 1 successors, FD is 2681856
via 192.168.12.1 (2681856/2169856), Serial0/0
P 192.168.24.0/24, 1 successors, FD is 2169856
via Connected, Serial0/1

If we assume all the links have a cost of 1, R4 would report a distance of 2(not counting the loopback itself) to R2, R2 already has a link with a cost of 1.

Thanks for giving it a shot

APA

I'm going to lab this up tonight as I can create this toplogy easily...

I had another think about it and I'm sure it converges due to the fact that R4 knows it learnt the routes off R2 and R3.... so it also removes all routes to 10.10.10.0/24 from it's routing table and responds negatively to any queries sent...

I'll lab it up and debug EIGRP packets\events and provide an output

kpjungle

A.P.A wrote:

I'm going to lab this up tonight as I can create this toplogy easily...

I had another think about it and I'm sure it converges due to the fact that R4 knows it learnt the routes off R2 and R3.... so it also removes all routes to 10.10.10.0/24 from it's routing table and responds negatively to any queries sent...

I'll lab it up and debug EIGRP packets\events and provide an output

Cool, cause the debugs im seeing is so instantaneously that its hard to see how things actually fits together. I just dont have any material that states when an outstanding query is cancelled (due to receiving a negative reply for example). It doesnt say in any the material I have come across. Maybe in the Tcp/Ip routing volumes, but i dont have those