Why specifically can't EIGRP handle a lot of routes

[vv0bbLeS]

Hello all,

I've always heard that EIGRP can't handle a lot of routes (like you don't want to blindly redistribute BGP into EIGRP as it could crash the EIGRP process), but I've never heard specifically why that is the case? Is it maybe because of:

1. How EIGRP calculates the metrics on routes (too much load on the CPU)
2. Perhaps EIGRP is only allocated so much storage on the router/L3 switch, and it can't physically store a large number of routes?
3. Maybe some other reason I'm not thinking of?

I'm leaning toward #1, because BGP is able to handle a large number of routes and it doesn't calculate a metric so much as it looks at attributes of routes, which seems much more scalable when you're talking about hundreds of thousands of routes. But not 100% sure, and Google wasn't any help, so turning to the community for ideas/answers!

[Giuseppe Larosa]

Hello @vv0bbLeS ,

>> I've always heard that EIGRP can't handle a lot of routes (like you don't want to blindly redistribute BGP into EIGRP as it could crash the EIGRP process

>> when you're talking about hundreds of thousands of routes.

This is the point EIGRP as and IGP is thought to support few thousands of routes up to  tens of thousands.

For each prefix all the metric components are stored separately not the result of the computation of the composite metric.

EIGRP composite metric uses multiple parameters by  default delay and bandwidth but it is a still a scalar number ( single integer value)

BGP attributes builds a multi dimensional vector or Path Vector.

I have never performed tests on scalability of EIGRP. For OSPF OSPF databases with 50,000 external routes have been reported as used in production by some ISPs that had not moved Service routes to MP BGP.

There was no issue with the control plane. There were some issues with the data plane in programming the TCAM entries FIB or LFIB on some platforms.

The main challange for EIGRP scalability is how to limit Query range this can be achieved by: route summarization at interface level and or route filtering.

There is the need to avoid SIA = Stuck in Active scenarios. The DUAL algorythm is very specific because route convergence is the result of collective efforts between EIGRP routers. The computation when a route goes active is distributed the router that has originated the Query waits to receive a Reply from all its EIGRP neighbors. The question is that the neighbors can go active for the same prefix and start their own Query to other routers and so on.

Hope to help

Giuseppe

[MHM Cisco World]

Not eigrp only but ospf also 

Full table routing when redistribute from bgp into any igp you can face this issue. 

MHM

[Richard Burts]

The OP presents an alarmist assertion: redistribution of BGP into EIGRP causes CRASH of EIGRP. (emphasis mine) I have not tested this but I doubt that it results in crash. Poor performance - I would expect that. But a crash would surprise me.

Perhaps it might help to think of this issue in terms of routing protocols as tools. A tool is designed to achieve a result in some environment. Our "interior" protocols (think especially EIGRP and OSPF) are designed to operate on a (somewhat limited) number of routes and to calculate and maintain information about the path toward destinations. Our "exterior" protocol is BGP which is designed to operate on a very large number of routes and does not care so much about the physical path toward the destination but focuses on providing loop free forwarding toward the destination. So when we begin to implement a network we need to choose a routing protocol tool. Which tool should we choose? What are the implications if we choose  a less appropriate tool?

[David Ruess]

When topics like that are presented its usually in reference to the entire internet routing table as it mainly uses BGP for distribution of routes. If you were to redistribute the millions of routes from the BGP Internet routing table then yes, it would absolutely crash ANY other routing protocol and device if it couldn't handle the amount of memory needed to process it all. While it's possible to do there are plenty of safeguards in place to help mitigate that. For instance, if you connect to 1 ISP likely they will advertise a default route to you and nothing else since all you need to get to the internet is to go through them. In that case the 1 default route you get from BGP can be redistributed into your EIGRP (or any other routing protocol) domain.

IN addition to this most IGPs process and send routes right away whereas BGP takes its time to go through its best path selection and install routes. It even has timers built in to advertise routes periodically and not instantly.

Hope that helps.

-David

[vv0bbLeS]

Thank you all for your responses!

@Giuseppe Larosa that is interesting about the ISP using OSPF for 50k+ routes, and how the control plane was fine but some platforms experienced storage limitations on the TCAM chips (makes sense with that many routes if you had a lower-tier device).

@Richard Burts haha yes I had heard that alarmist assertion on an INE training course, where the instructor mentioned you have to be careful when redistributing BGP into an IGP like EIGRP as if there are LOTS of routes it could "crash" (his words) the process (e.g. crash the EIGRP process).

That got me curious as to "why" that would be? Understanding of course that the protocols are intended for different things (routing inside an AS vs inter-AS routing) and we always need to pick the right tool for the job. But taking the classic example as given by @David Ruess of how BGP can of course handle the entire internet routing table, but an IGP like EIGRP likely could not - "why" is that the case technically speaking, i.e. what is the technical reason why EIGRP couldn't handle say 1M+ routes? Perhaps it depends on the router hardware (storage/memory), or is it a limitation of the EIGRP code itself maybe, or perhaps a combination of those things or something else entirely?

And as @Richard Burts mentioned I have also not tested this EIGRP/OSPF "crash" myself. @MHM Cisco World have you ever seen this actually happen by chance?

[MHM Cisco World]

Yes twice here in community' 

And internal router not need full router defualt route is enough for any internal router only edge router need full

MHM

[David Ruess · Accepted solution]

Maybe I can clarify just a bit. While the processing power of the device can definitely play a role in how many routes a device can handle think of this scenario type:

EIGRP has to run its DUAL (loop free calculation) on every route it receives. Thats 1M+ processes (1 for each route). 

BGP doesnt even accept the route if its a loop (from its own AS for eBGP, iBGP doesnt send routes to eachother unless explicitly told) so it doesn't even need to process it. BGP is way more deliberate, as in you need to tell it to do this or that or advertise to this neighbor. It can also as I mentioned earlier bundle updates to neighbors after a timed interval. This allows BGP to transmit large volumes of routes to its neighbors in a more compact and efficient way. Its just the way the protocol was designed.

Also, not the IGP defaults. EIGRP only uses 50% of its interface BW for routing updates, if I'm sending 1M+ routes I'm definitely exceeding that BW. 

Again this still boils down to processing power of the device. A 3850 is not supporting a BGP table on its best day. So equipment type absolutely plays a factor as well.

I also want to hit one more point. A BGP routing table can also crash a device. All routing protocols are subject to their limitations so while IGPs are lower as that's what they were designed to handle. They were built for speed on internal networks. 

BGP is slower but built for mega routing tables and the internet. Some companies even run BGP internally on their network since their routing tables are so big, its not just for the internet.

-David