Reason for limits on EIGRP route table (as opposed to BGP)

[vv0bbLeS]

Hello all,

I am new to networking and currently working on my CCNP. In my studies I have heard several times that it would not be wise to redistribute BGP routes into an IGP process like EIGRP, because if BGP happened to have a large number of routes then it could crash the IGP processes like EIGRP or OSPF.

My question is about the reason for this limitation in IGP protocols like EIGRP (or OSPF) as opposed to BGP. Would it just be that IOS (or NX-OS or whatever) assigns more memory and hardware resources to BGP in the OS code, such that BGP is able to handle more routes, whereas IGP protocols are not assigned as much in terms of hardware resources for handling routes?

[Richard Burts · Accepted solution]

The issue with redistributing BGP into an IGP does not have anything to do with memory or other hardware resources. And doing that redistribution is not likely to crash the IGP process. It is true that BGP was designed for scalability much more so than the IGPs. The algorithms used and the route selection processes are quite different in BGP than in the IGPs and this contributes to the scalability. The IGPs try to find the best path to a destination by comparing attributes of the various possible paths. BGP does not concern itself about attributes of the path but focuses on identifying the AS and neighbor to whom to forward the traffic. The calculations performed by the BGP process run efficiently when the number of routes to be processed is large. But with the IGP as the number of routes becomes very large the calculation performed is much more complex and becomes less efficient as the number of routes becomes very large. Another factor to consider is that with an IGP if there is a change some attribute of the path selected to reach some destination it generally will trigger a convergence event and force the running of the route selection algorithm. If you have redistributed BGP into the IGP resulting in a large number of routes that will have a large number of paths to evaluate and will have path changes more often and so will need to run the route selection process more often than is the case with BGP. These are some of the reasons that BGP is more scalable than the IGPs and that the general wisdom is to not redistribute BGP into an IGP.

Note that running any routing protocol with a very large number of routes (especially the number of routes in the Internet routing table) does require a significant amount of memory. There are quite a few routers you could use that do not have sufficient amount of memory for that large number of routes. But that is true no matter whether you are running an IGP or are running BGP.

[Joseph W. Doherty · Accepted solution]

As Rick has well described, BGP was designed to handle large route tables, like the Internet's, while IGPs have not been. Routing protocols are like are tools, they have design purposes, and even in cases where you can, or cannot, work around them (e.g. of former, hammer a screw, of latter, screw a nail), optimal usage is best accomplished with tools designed for that purpose.

For example, BGP sends a copy of its routes during its initial setup with a new peer and then it sends updates. OSPF, besides doing something similar, also transmits a new copy (on Cisco, and by standard) every 30 minutes. OSPF, even within the much smaller (vs. Internet) IGP networks, can be a bit problematic doing this (so much so, Cisco has features that meet the standards, yet their implementation, perhaps, wasn't expected or defined by the standards). If a typical "large" OSPF network can be stressed already, consider the impact of circulating Internet size route tables, not only on the hardware resources of a router (again as mentioned by Rick), but also perhaps on the lower bandwidths of many private WAN networks especially in years past when these standards were defined. (BTW, the last point is often overlooked, over time limitations "then" no longer exist, so what may have made much sense "then", no longer applies, but we're still using "whatever" as the standard.)

[vv0bbLeS]

Richard/Joseph,

Thanks so much for your replies! They were very informative and helpful. This is probably an oversimplification, but from what I understand, would one of the "main" efficiencies of BGP be that:

• BGP compares any "new" routes that come in to the single "best path" route that it already knows, as opposed to say an IGP protocol that compares any "new" routes to all other routes that it has learned?

[Joseph W. Doherty]

As an "oversimplification", likely that's true (although, BTW, also realize [at least Cisco's implementation] BGP can have more than one route to the same destination in its route table).

[vv0bbLeS]

OK great! That helps clear it up a bit. And yes good point on the possibility in BGP of multiple paths. Thanks again!