cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1502
Views
5
Helpful
13
Replies

EIGRP Query Range - Summarisation

kfarrington
Level 3
Level 3

Hello all :)

So, the way summarisation bounds the EIGRP query domain is as follows.

Just image this simple topology

siteArtr1-----------siteArtr2----------siteArtr3-----------siteBrtr1---------siteBrtr2---------siteBrtr3

Ie, if you run a 10.0.0.0 network in siteA and 11.0.0.0 in siteB with auto-summary disabled and no manual summarisation (for simplicity, all networks subnetted to /16s), then each router in the network in site A and Site B would have a topology table entry for each individual /16 in net10 and net11. Query would go everywhere.

If network 10.1.0.0 in siteA went down, and auto or manual summarisation was enabled, the query would only get to the summary border router (lets say siteBrtr1 that has 10 and 11 networks on) and query its first neighbor in SiteB (siteBrtr2) and as this router would not have a topology entry for the /16 (10.1.0.0) and only the /8 (10.0.0.0) for net10 thus that router would not query its neigbors in site2.

So, Can I make the following statement on how this works.

"A query only gets sent by a router to its neighbors (apart from the successor) if that router has an exact entry for the prefix/length in its topology table? "

Is that statement correct? This is important as ACLs and other stuff, could affect the query range, if you have routers in the path to the destination that blocks this prefix, that could also limit the query range for a network.

Many thx indeed,

Ken

1 Accepted Solution

Accepted Solutions

mheusinger
Level 10
Level 10

Hello,

your statement is correct. The underlying reason is that a query in fact also is informing about a network being unreachable.

If an EIGRP router gets an unreachable statement about a network it never had, "it is not bothered". In this case nothing is removed from the routing table, so no need to ask neighbors about reachability.

If the network existed, however, then there is a real change in the routing table and the EIGRP router needs to evaluate, if a substitute exists. In the case of a feasible successor, the answer is yes and can be given locally from the topology database. If no fesible successor exists the neighbors need to be queried.

Hope this helps!

Regards, Martin

View solution in original post

13 Replies 13

mheusinger
Level 10
Level 10

Hello,

your statement is correct. The underlying reason is that a query in fact also is informing about a network being unreachable.

If an EIGRP router gets an unreachable statement about a network it never had, "it is not bothered". In this case nothing is removed from the routing table, so no need to ask neighbors about reachability.

If the network existed, however, then there is a real change in the routing table and the EIGRP router needs to evaluate, if a substitute exists. In the case of a feasible successor, the answer is yes and can be given locally from the topology database. If no fesible successor exists the neighbors need to be queried.

Hope this helps!

Regards, Martin

Many thx. Great stuff.

I'll back up this part: A router which doesn't know anything about the network received in a query will respond with an unreachable reply--you can't get there from here. This is why queries are stopped by summaries and router filters.

The reason for queries I won't back up, though. :-) In reality, a query is just that--queries are used to find paths that are normally weeded out through split horizon, or to verify the state of a path--loop or loop free--that we don't know about right now.

If a path is to be removed, it is removed through an update with infinite metric, or a poision. In other words, when a router goes passive on a route with the result that there is no path at all, it sends out a poison to remove itself as a path towards the now passive destination. There are some cases where we know, for certain, we don't need to send out this following update, and we "squash" it, hence you see the log message "poison squash."

I hope that explanation makes sense....

:-)

Russ

Hey fella, just causing more trouble here :) and Martin has been a great help.

OK, You say :-

"A router which doesn't know anything about the network received in a query will respond with an unreachable reply"

I assume this is imediateley - query range stops

if the topology table (not routing - can you confirm that) does have an entry, it queries and then eventually does the same thing if no valid path via another means:

after all query responses received it will respond with an unreachable reply Correct?

----now------

Covering all bases on this (and this is silly): if you had a router with a route (not an eigrp route) for the subnet 10.1.0.0 and say it was not redist into eigrp, but in the routing table, would this cuase an EIGRP query to be sent, I assume not.

ie, router only had 10.0.0.0 from siteA in EIGRP, but had a rip route for the subnet 10.1.0.0 in siteA via another path that was not redist into EIGRP,

thus the router topo just had the eigrp summary. router receved eigrp query for 10.1.0.0 that went down, and that could cause an eigrp query to be sent to its neighbors as it has an entry in the RT via RIP.

This is just a silly by-product that was in my head? Am am sure that would not happen

Thx

Ken

"Martin has been a great help."

Yes--I'm not trying to discount anyone (I rarely answer here, because Martin and others do such a great job of answering everything!), just pointing out that EIGRP doesn't remove a route to destination based on a query, it does so based on an update.... IE, if I receive a query for 10.1.1.0/24, and I find I have no path to 10.1.1.0/24 other than through the neighbor which queried me, then I will generally wait on a following poison update to remove the route, I won't remove it based on the query itself. In general, queries do cause routes to be marked active, but not to be removed from the local table table. There are exceptions, there are always exceptions.... :-)

To answer the followon questions: It's the topo table, not the routing table. EIGRP doesn't pay any attention to the routing table when processing queries. So, if you have a route to 10.1.1.0/24 in the local routing table, but not in the local topology table, and you receive a query for 10.1.1.0/24, you'll send a poison (infinity) reply.

EIGRP doesn't do much with the routing table, per se--other than installing routes into it, using it for split horizon determinations, and accepting redistributed routes from it.

HTH....

:-)

Russ

Hi Russ,

Sorry mate, I was not implying that :)

I told Martin I need a beer yesterday, I did have one (or five when Arsenal lost to PSV):)

Thx all guys for the help, as usual, its invaluable :)

Kind regards,

Ken

If you're at Networkers US, I'll buy you one!

:-)

Russ

top man - thx fella, likewise :)

Hi,

Thank you Russ for being more precise than my first post. Tried to keep it simplple, but reading it again, I mixed the terms "topology" and "routing" table, which might make the posting misleading.

As you said, for EIGRP the world exists in the topology database. The routing table is "just used" to inject reachability information.

One more question: can it happen that an EIGRP router receives a query from the successor before an update regarding a certain network being unreachable?

If YES: what is the action taken by the receiving router?

Regards, Martin

Is it possible to get a query before getting a poison update from a successor? Yes.... The case we don't often think about is metric increases, specifically in the case where the metric increases past the point where the new RD is more than the old FD, which means you must recalculate the entire mess, and you've no idea if the old possibly looped paths run through the path with the increased metric. Gee, I hope that made sense, I need a white board, I think to explain this well. :-)

So, there are cases where you get a query before you get an update.

If you receive a query for a network from a successor, you will mark the route active, and query your neighbors.... When you receive all of the replies, you will reply to your neighbor.

At this point, you would think that EIGRP would pull the route from the table--but in reality, you just mark the route passive, with an infinite metric. You won't remove the route, in theory, until you receive a poison update from your successor.

Now.... In reality, we will, as an optimization, often remove the route on going passive, rather than waiting on the poison update. The original DUAL algorithm doesn't allow for this, and there are cases where we don't optimize, so....

Did I waffle enough??? :-)

Theory--we don't ever remove a route on going passive after a query. Reality--sometimes we do, sometimes we don't.

:-)

Russ

OK Russ,

Well I remembered the EIGRP router behaviour of removing a route after a query (just could not remember the details).

Your explanation makes sense to me. So my conclusion of all your statements: a small unix script constantly changing interface bandwidth statements would keep EIGRP routers busy (and drive netops and users crazy).

By the way, as you ask: You would be a great instructor leading people into total confusion and then sorting things out like a magician ;-)

(And they lived happily ever after ...)

Cheers, Martin

Martin,

I am not sure what the following was about:

"One more question: can it happen that an EIGRP router receives a query from the successor before an update regarding a certain network being unreachable? "

or as Russ put it:

"Is it possible to get a query before getting a poison update from a successor? "

Sorry fella, now I need to understand this :) PS. at least Chelsea did not win - haha!

So from the following conversation,

EIGRP Normal workings

in my example network topology (what a design) (lets say no summarisation for simplicity, so query goes everywhere)

prefix on siteArtr1 goes down

siteArtr1 has no FS so sends query to siteArtr2

siteArtr2 has no FS so sends query to siteArtr3

and so ... until network boundary reached.

All start replying back to the queries.

once siteArtr2 receives the reply (from siteArtr3) to its query it sent to siteArtr3 with a destination unreachable metric, THEN the prefix goes passive (from the active state) BUT NOT removing anything from the RT. It is only when siteArtr2 then sends a reply to siteArtr1s query and then receives an update-poison from siteArtr1 (its successor) this update ensures the removal of the prefix from the RT. Hope that is correct?

So, lets start from here

so siteArtr1 (the successor) has no FS, so sends a query to siteArtr2, - the question "Is it possible to get a query before getting a poison update from a successor"

Is that not normal behaviour, ie, siteArtr2 will get a query from siteArtr1 (the successor) before siteArtr1 sends a poison-update to siteArtr2?

Im a tad confused. And bearing in mind I have just done this in a straight line - im sure in a redundant network, this may happen, maybe a little explanation?

Could you elaborate a little for me please?

Thx

Ken

"once siteArtr2 receives the reply (from siteArtr3) to its query it sent to siteArtr3 with a destination unreachable metric, THEN the prefix goes passive (from the active state) BUT NOT removing anything from the RT. It is only when siteArtr2 then sends a reply to siteArtr1s query and then receives an update-poison from siteArtr1 (its successor) this update ensures the removal of the prefix from the RT. Hope that is correct?"

Correct... In theory. :-) In this specific case, I'm fairly certain we would squash the poisons, so you wouldn't see them. I would guess that we squash the poisons in the vast majority of the cases--but not at all....

In the original design of DUAL, you never touch your routing table based on the query. You might mark a topo table entry active based on a query, but you would never remove it. You only touch your routing table when you receive an update.

:-)

Russ

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco