What is a practical need for iBGP Route Reflectors or Confederations?

[vv0bbLeS]

Hello all,

I'm familiar with Route Reflectors (RR) and Confederations (CF) and the problem they solve (avoiding the need for full-mesh in iBGP), but I'm trying to think of a practical example where I would have enough iBGP routers that I would need to actually implement RR's or CF's? Wouldn't a better design be to implement BGP at the edges of the network, run an IGP in the middle (like EIGRP), and then simply redistribute routes between BGP and the IGP?

[Kasun Bandara · Accepted solution]

Hi @vv0bbLeS , i guess below resources may explain clearly why we need those technologies, where to use and how to use.

BGP Confederation Explained

BGP Route Reflector

BGP Confederation vs Route Reflector - Rogers CCIE Blog

[Giuseppe Larosa · Accepted solution]

Hello @vv0bbLeS ,

the use of iBGP,   i MP BGP and BGP route reflectors is common on ISPs and big enterprises.

BGP confederations in Tier1 ISPs

Hope to help

Giuseppe

[MHM Cisco World · Accepted solution]

Let summary 

Why I need ibgp? I can redistribute prefix from ebgp edge router into IGP, when then I use ibgp

Answer:-

1- for network one edge router ebgp redistribute into IGP no need ibgp

2-for network two edge router ebgp here we need to run ibgp between two edge routers because we now can make each edge router have two path ebgp and ibgp and select prefer path according to weight/LP... Etc. This can not use if we use redistribute, if we redistribute then only AD is factor use to prefer path

3- I am Service provider and I use vpnv4, here İ need to use ibgp between two sites use ebgp, but why? Because

##I don't want costumer prefix inject into my RIB and Bgp is only protocol use for vpnv4, İ can not use IGP for VPNv4

4-I have DC and I use vxlan, here i use bgp since it only protocol can handle vxlan, you can use ebgp or ibgp.

Now from above we know that we need ibgp in many cases why RR?

İbgp need full mesh, this in real network sometime impossible so we use RR in such all ibgp Need to only connect to RR and RR will re-adverise prefix between ibgp

MHM

[M02@rt37 · Accepted solution]

Hello @vv0bbLeS 

A key driver is the overhead of maintaining a full-mesh iBGP configuration, where every router must peer with every other router. For example, in a network with 100 iBGP routers, a full mesh would require 4,950 peering sessions. This not only creates significant operational complexity but also increases the processing and memory burden on routers. Using RRs or CFs eliminates the need for a full mesh by centralizing route distribution, drastically reducing the number of peerings and simplifying configuration and maintenance. This approach is common in service provider networks or large enterprises with extensive WANs.

Redistributing routes between BGP and an IGP, as you suggest, is practical for smaller or less complex networks but presents limitations in larger deployments. IGPs like OSPF or EIGRP are not designed to handle the large volume of routes typical of BGP, such as those in internet-facing or MPLS networks. Overloading the IGP with these routes can lead to instability, slower convergence times, and potential outages. By keeping BGP routes within the BGP domain and using RRs or CFs to manage scalability, the IGP is reserved for internal network communication, maintaining optimal performance and stability.

Another consideration is policy control. BGP provides advanced tools for routing policies, such as prefix filtering, route maps, and communities, which are crucial for managing external routes. Redistributing BGP routes into an IGP diminishes this control, making it harder to enforce policies and leading to potential misrouting. Implementing RRs or CFs ensures that iBGP peerings remain manageable while preserving the flexibility and control that BGP offers, especially in networks where precise route manipulation and traffic engineering are critical.

[Joseph W. Doherty · Accepted solution]

". . . but I'm trying to think of a practical example where I would have enough iBGP routers that I would need to actually implement RR's or CF's?"

Actually, there's no specific number.  That issue is similar to asking, based on number of routers, when should you switch to a dynamic routing protocol vs. manual static routing.

"Wouldn't a better design be to implement BGP at the edges of the network, run an IGP in the middle (like EIGRP), and then simply redistribute routes between BGP and the IGP?"

"Better"?  Possibly, but often not.

First common issue, if BGP is passing about full Internet tables, most interior routing devices don't have the physical capacity to support.  Second, IGPs, themselves, often don't well deal with Internet sized route tables 

The other issue, common anytime you redistribute between routing protocols, they don't support all the same information, so information may be lost during redistribution.

BTW, I have seen BGP used internally, to tie together different internal routing domains, such as with OSPF, for both an international and very large Enterprise, there was a BGP Enterprise core.  Each region had its own OSPF domain, which might also had its own OSPF area zero with sub region, non-zero, OSPF areas.

For that topology, there were no RRs or CFs, although both eBGP and iBGP, probably used, much as you're thinking they might/could/should be.

[vv0bbLeS]

Wow thank you all so much for the responses, I understand the practical need much better now! Thanks again!