suggested upper limit for EIGRP hub and spoke setup

[Paul Morgan]

Is there any suggested upper limit to a single EIGRP hub-and-spoke design (i.e. with a single central router)?

Router is a 2900 ISR

I'm vaguely aware of a similar design limitation with OSPF areas where no single area should contain more than 40 - 80 routers. Could be heresay...

[Jon Marshall]

Paul

I'm not sure there is a suggested upper limit because it all depends on the CPU/memory of the routers. Certainly EIGRP is not as processor intensive as OSPF.

However the key with EIGRP in your scenrio is to use the EIGRP stub feature. Without it whenever EIGRP needed to make a query that query would have to go to every single spoke router and this could lead to SIAs if the link to a particular spoke or set of spokes was heavily loaded. If you use EIGRP stub then this in effect tells the central hub router not to send queries to any of the spokes which greatly increases the scalability of the network.

Apologies if i am telling you something you already knew.

Jon

[Paul Morgan]

Cheers Jon. An excellent suggestion. I have started seeing more SIA errors as the number of endpoints has gone up. I will roll out EIGRP stub routing across the network and hopefully we will see some improvement.

Many thanks.

If anyone does know of any upper limits to the original question I'd still be interested to know.

[Jon Marshall]

Paul

Still don't know upper limits but just wanted to say that EIGRP stub should only be applied to spokes that do not have any other networks hanging off them ie. they really are just spoke networks and a spoke is not used as a transit network to get to further networks behind the spoke if you see what i mean.

Jon

[Paul Morgan]

thanks Jon - that bit I did know

[dslice]

Totally agree with stub suggestion and you should also summarize from the hub to the spokes if possible. How many routes are you currently sending to the spokes?

Sent from Cisco Technical Support iPad App

[Paul Morgan]

We'll be approaching 40 sites early next year and we inject 4 routes into EIGRP per site

[dslice]

From your description, it sounds like your talking about routes coming from the sites to the hub.  How many are sent from the hub to each site?  4 X 40 (routes from each site sent to all others) or more?

[Paul Morgan]

Well as it happens we have two central routers with each site connected via gre tunnels. Each site then has two lans.

So each spoke site roughly has the following:

Router eigrp 1000

network 192.168.10.0

network 192.168.20.0

network 172.16.01.0

network 172.16.02.0

So currently with no adjoining sites it is sitting at around 120+ routes. I could summarise the contiguous lans but its hardly worth it. My concern wasnt really whether EIGRP could handle the routes but whether it had some upper limit to the hub-and-spoke design. Im sure it can handle thousands of routes, just not all hanging off one router.

[dslice · Accepted solution]

The point of my question and comment about summarization was that the number of peers you can support in a hub and spoke topology and the number of routes sent to each peer are tightly linked.  At initial startup or in reaction to major trauma on the network, the hub(s) will be attempting to bring up the peers by sending all of it's routes to each peer.  The more routes to send, the more work to bring each peer up, and the more peers to bring up the more total work for the hub to do.  Thus if a spoke doesn't require all of the routes (can receive a default or summarized subset of routes) the work required by the hub at startup is far less.

As an example, in the lab we were able to bring up over 1000 peers in a hub and spoke environment using summarization and stubs.  I don't remember the hardware used on the hubs (probably a 7200 of some sort), so that number will not be true for any router type, but it gives you an indication of how much EIGRP can scale if you use stub and summarization.

[Paul Morgan]

yeah sorry Donald - I didnt clear that up very well. Originally, with just plain-old EIGRP we were passing around 120 routes to each spoke and this would keep climbing with each new site. But I pushed out stub routing to all the applicable sites last night and after a few bunny-hops in the routing, everything has stabilised and looks a lot neater.

With regards to summarization: is it worth doing a wide range summarization from hub to spoke like 192.168.0.0 0.0.255.255?

Many thanks for all the comments.

[dslice]

Probably, (though the summary is 192.168.0.0 255.255.0.0, but I'm sure you know that).   This means that the hubs will only send a single prefix to the spokes, making startup simple.  One possible side-effect of this strategy is that you could possibly have suboptimal routing, depending on your actual topology.  For example, if both hubs send 192.168.0.0/16 to the spokes, but 192.168.1.0/24 is closer to hub1 and 192.168.2.0/24 is closer to hub2, the spokes will lose this level of knowledge and could send traffic destined to 192.168.1.0 to hub2 and vice-versa.  If both hubs are at the same site, this is probalby not significant, but if hub1 is LA and hub2 is NY,  it probably is significant.

Like most things in life, the decision has trade-offs you'll need to figure into your actual situation and judge accordingly. 

[Paul Morgan]

I'd have probably put it in the wrong way round and messed everything up.

All the gre tunnels are sourced on Gi0/1.

Could I get away with

int gi0/1

ip summary-add eigrp 1000 192.168.0.0 255.255.0.0

or would I need

int tun1

ip summary-add eigrp 1000 192.168.0.0 255.255.0.0

int tun2

ip summary-add eigrp 1000 192.168.0.0 255.255.0.0

etc

[dslice]

I'm guessing EIGRP doesn't know anything about G0/1, but instead is running across the tunnels.  You can get some really interesting recursive routing problems if you're running EIGRP on both the tunnels and the underlying links the tunnels are built on unless you're really careful.

If that's true (EIGRP only sees neighbors across the tunnel interfaces), that's where the summary address commands would need to be applied.