Stub V summarization

I've spent a few days creating various scenarios and analysing the debug eigrp packet query reply update messages because i wanted to understand the concept of stub routers better. Now please correct me if i'm wrong but when you use the eigrp stub command on a router which isn't connected to anything downstream all this does is prevent other routers from sending him queries? They don't send him queries but he can query them for any lost routes. I did find that even in a small network of 5 routers, 2 main office routers connected together, 2 daisy chained off one and a single router of the 2nd main office router, a lot happens when a router goes down.
Summarization manual or using "auto summary" is much better? it did seem to be although i found the best way to reduce the number of queries sent out is to use both summarization and have stub routers on the last routers in the network. Is this an acceptable way of doing it?
Stubbing on its own seems a bit of a waste of time. Seems over-rated. As all thats achieved is preventing those cul de sac routers from receiving queries but they still send them out and other routers higher up still receive them and will send queries up stream (provided the directly connected router isn't a stub) and have to process it.

But with summarization if there's 4 routes being summarized and 3 fail only a couple of queries go out. When and if the 4th one fails, lots of queries go out because I assume this is due to updates propagating the network and this results in lots of queries.

am i talking sense? or is it bollocks

Find more posts tagged with

Comments

fsanyee

Then non stub router should send only a default route to the stub router. The stub router recieve only a default route, and no need for queries.

mattau

I think the original poster was asking what happens when a network that the "Stub" knows about goes down. Does it query the Hub, and if so it seems pretty pointless doing the whole stub thing when effective summarization is more beneficial to prevent queries being sent throughout the entire network in both directions.

Based on your lab testing MrXpert id like to know the benefit of a stub also. (bar the hub not querying stub spoke routers) I mean yeah like you said sure its good for the queries that go to the spoke given it wont query the spoke but seems like you still need to do summarization on the way back otherwise the Hub will just query all of its neighbors and it could get out of control.

I guess just like anything with eigrp, best practice would be to summarize whatever the stub is sending to the hub (if it has any networks that is.) at least then the query is stopped at the hub router.

MrXpert

mattau wrote: »

I think the original poster was asking what happens when a network that the "Stub" knows about goes down. Does it query the Hub, and if so it seems pretty pointless doing the whole stub thing when effective summarization is more beneficial to prevent queries being sent throughout the entire network in both directions.

Based on your lab testing MrXpert id like to know the benefit of a stub also. (bar the hub not querying stub spoke routers) I mean yeah like you said sure its good for the queries that go to the spoke given it wont query the spoke but seems like you still need to do summarization on the way back otherwise the Hub will just query all of its neighbors and it could get out of control.

I guess just like anything with eigrp, best practice would be to summarize whatever the stub is sending to the hub (if it has any networks that is.) at least then the query is stopped at the hub router.

Spot on thats exactly what I was on about. I did more tests today, creating various scenarios. With and without stubbing and then with a combination of summarization and without. In the end after the reams of debugs I ran, i still agree that summarization is a lot more useful and helpful when combined with stubs. It just isnt made clear on any documentation or vids i've watched which prompted me to post this. Learnt a lot from running those debugs though.Phew.

mattau

I also did a lab last night, I had 20 routers in it and 1 network on the stub router that goes down without summarization causes an out of control query circus. I'd certainly agree summarization is more beneficial but at the same time the stub is still a good idea because if you have spokes with low bandwidth linkes to various sites any query that is stopped from being sent out is still a benefit vs the summarization where the query messages are still sent over the link only to get returned with a "destination unreachable" reply. Ill definately be mindful to use both in combination with each other

wave

The stub benefits in EIGRP aren't as wonderful as they are in OSPF

But the fact that hubs don't query stubs is powerful in itself.

You guys mentioned summarization 'on the way back'. Remember that there are also options when using the stub command in EIGRP: receive-only, connected, static, summary, redistributed. In some cases you may not even need to announce the networks you have connected to the stub router.

I guess it depends how big your network is on the end of the router you would make a stub. Ideally you would only send a default route to the stub router and depending on the size of the network you could use a lower-end model (saving $$).

Edit: and just as mattau mentions, if you have sites with lower bw links you will reduce traffic by using EIGRP an stub

wave

This reason alone makes an EIGRP stub worth while (see image)

Page 171 of the FLG

eigrpstub.jpg