When deploying excessively large Autonomous Systems or ASes in BGP, it is necessary to overcome the limitation introduced by the iBGP full mesh peerings required within the AS in question. There are two primary ways this can be achieved, using either BGP’s Route Reflector feature or BGP confederations.
In this article, we’ll examine these two options and share information about the advantages and disadvantages of each, ultimately giving you a guide as to which to use and in what circumstances.
BGP Design
Border Gateway Protocol (BGP) is the routing protocol that is used on the Internet at large. One of BGP’s fundamental design principles is that it separates the network into Autonomous Systems or ASes. Each AS is an independent entity administrated by a particular organization such as an ISP or a large enterprise.
iBGP Design
Within an AS, all BGP routers create internal BGP peerings or iBGP peerings with each other. An iBGP peering is defined as a BGP peering between two BGP routers in the same AS.
One of the requirements of iBGP is that for all BGP routers, there must be a full mesh iBGP peering between all iBGP routers within an AS.
For larger ASes, this can become both an administrative as well as a computational challenge as the number of peerings grows exponentially as the number of iBGP routers increase. The fact that peerings must be configured manually introduces even more overhead for all but the smallest ASes.
The Solution to the iBGP Full Mesh Problem
BGP itself provides a solution to this challenge by introducing two features:
We’ve talked about these features in detail in the past (see the links above).
In this article, we’ll examine and compare these two features of BGP specifically in the context of resolving the full mesh iBGP limitation.
We’ll compare them, describe their benefits and drawbacks, and determine under what circumstances each one should be used.
BGP Route Reflectors
An RR is an iBGP router that forwards updates from one iBGP peer to other iBGP peers.
Benefits of RRs
RRs are definitely easier to deploy and deliver a quick solution without the need to redesign the whole network or modify any existing AS numbers.
It is highly scalable because you can create multiple RR clusters within an AS. A cluster is the sum of an RR router and its clients.
This allows for additional levels of hierarchy to be introduced within the AS further extending scalability. RRs can also deliver robustness as you can create multiple backup RRs to take over in the event that an RR fails.
Drawbacks of RRs
The primary drawback of the use of RRs is the fact that RRs can alter the path information during reflection.
This could potentially lead to suboptimal routing. In addition, the deployment of RRs even with the use of clusters is typically limited to ASes on the order of several hundred iBGP routers.
BGP Confederations
BGP confederations involve breaking a single AS into multiple smaller, internal ASes. These smaller ASes, also referred to as sub-ASes, communicate using iBGP, while the original AS, which is called a confederation, uses eBGP to communicate with the outside world.
Benefits of Confederations
Confederations deliver several benefits to larger ASes including a very high level of control over route propagation and policies between the sub-ASes since each one can have its own distinct routing policies.
They can also reduce the impact of failures as they can be contained within each individual sub-AS. Some additional benefits include:
- Smaller more efficient routing tables
- Preservation of the external AS number so eBGP peering configurations remain unchanged
- More efficient use of AS numbers since sub-AS numbers are only locally significant
Drawbacks of Confederations
Confederations can introduce higher administrative and design complexities since you are managing multiple AS numbers internally.
They can also be more challenging when migrating from a classic iBGP setup to a confederation as it requires the renumbering and reconfiguration of internal BGP speakers with the addition of new AS numbers for sub-ASes and their peerings.
When to Use BGP Confederations or Route Reflectors
RRs should be used:
- In situations where you want a quick solution with minimal architectural changes.
- In networks where the architecture allows for a straightforward implementation of RRs without inducing suboptimal paths.
- If the number of iBGP routers in the AS is on the order of hundreds of routers.
Confederations should be used:
- In networks where there’s a need for fine-grained control over routing policies internally.
- If the network is so large or diverse that breaking it down into smaller domains (sub-ASes) makes logical sense and makes administration easier.
- If the number of iBGP routers in the AS is on the order of hundreds or even thousands of routers.
Comparison Table
The following table compares these two solutions and highlights their pros and cons:
Characteristic | Route Reflectors | Confederations |
Purpose | Overcome scalability limitation requiring full mesh iBGP peerings within an AS | Overcome scalability limitation requiring full mesh iBGP peerings within an AS |
Method of achievement | Designate RRs to forward updates from one iBGP peer to other iBGP peers. | Break up a large AS into smaller sub-ASes. |
Complexity | Medium (depending on design). | High, especially during transition. |
Configuration Changes | Moderate: Introduce RR and client configurations. | Extensive: Need to define sub-ASes and reconfigure peers. |
AS Number Usage | No change in AS numbers. | Internal use of new AS numbers (can use private AS range). |
Scalability | Suitable for networks in the order of hundreds of iBGP routers. | Can scale to larger networks, even thousands of iBGP routers. |
Policy Granularity | Medium: RRs control route reflection. | High: Each sub-AS can have distinct policies. |
Failure Impact | Could be high if RRs are not redundant. | Localized within a sub-AS. |
Visibility Outside AS | None: External peers see standard AS_PATH. | None: External peers see standard AS_PATH. |
Routing Table Size | Generally unchanged. | Can be smaller within each sub-AS. |
AS_PATH Length | Unchanged. | Increased internally due to sub-ASes, unchanged externally. |
Migration Challenge | Low to Medium. | High: Transitioning to confederation is complex. |
Potential for Loops | Minimal if correctly configured. | Present if not configured correctly. |
Operational Complexity | Moderate: Must monitor RRs, and understand the behavior of reflection. | High: Need to understand intra- and inter-sub-AS routing. |
Conclusion
The choice between route reflectors and confederations depends on the specific needs and current setup of the particular AS network in question.
While RRs provide a more straightforward more immediately deployable method of reducing iBGP mesh requirements, confederations offer a more detailed and modular approach delivering higher granularity and flexibility at the cost of increased complexity.
When making a decision on which to use, consider the following:
- The scale of your network.
- Future scalability requirements.
- Desired level of control over routing policies.
- Willingness to undergo significant architectural changes.
One solution is not exclusively better than the other, and what works best will be highly dependent on individual circumstances and requirements.
Related Posts
- What are BGP Confederations-Explanation and Discussion (With Cisco Example)
- What is BGP Route Reflector – Explanation and Discussion (with Cisco Example)
- What is a Wildcard Mask – All About Wildcard Masks Used in Networking
- Cisco Branch Virtual Office Solutions – Network Design
- Passing non-IP Traffic over IPSEC VPN using GRE over IPSEC