Border Gateway Protocol (BGP) is the de facto routing protocol that is deployed on the Internet at large. BGP is ideal for the Internet because of its scalability. One of the many characteristics of this routing protocol that make it so scalable is what is known as BGP confederations.
In this article, we’ll discuss what BGP Confederations are, and why they are useful, and we’ll also see a simple implementation of this feature on Cisco devices.
What are BGP Confederations?
Before we investigate what confederations are, it will be helpful to briefly look at how BGP operates. For a more detailed description of BGP, take a look at this article about the Protocol of the Internet.
BGP Operation Overview
Remember, BGP separates a topology into Autonomous Systems (ASes) that are separately administered network entities composed of BGP-speaking routers.
The routers found within a particular AS create what are known as internal BGP (iBGP) peerings. Now it is often the case that these ASes become exceedingly large, containing hundreds and sometimes even thousands of routers.
At the same, iBGP peerings within an AS are required to be configured in a full-mesh peering arrangement, where every iBGP speaker must have an iBGP peering with every other iBGP speaker within the AS.
This quickly becomes administratively unfeasible for ASes as the number of iBGP routers increases. The specific formula for the number of peerings needed based on the number of routers “N” in an AS is: N(N-1)/2
Practically, this means that ASes are limited in size, and cannot reasonably grow beyond a couple of dozen iBGP routers. So, there should be a solution to limit the number of peerings between iBGP and mitigate the full mesh requirement.
There are two options for this:
- BGP Route Reflectors (we discussed this before)
- BGP Confederations (discussion in this article)
Here is a comparison article between the two BGP mechanisms.
The Need For More Hierarchy
BGP Confederations provide one solution to this problem by introducing a type of hierarchy within an AS. By subdividing an AS into multiple sub-ASes, you can create small groups of iBGP routers that comply with the full-mesh peering requirement.
At the same time they create BGP peerings with other sub-ASes in much the same way as eBGP peerings take place between ASes. Such an arrangement may look something like this:
In the above diagram, you can see AS 100 contains three sub-ASes, each of which has between three and five iBGP routers. Each sub-AS has the requirement that all BGP routers maintain a full-mesh peering, but this requirement is relaxed for inter-sub-AS BGP routers. You can also see a couple of eBGP peerings with other ASes.
The Case for BGP Confederations
So why is this arrangement useful? Without sub-ASes, these 12 routers require 12*(12-1)/2 = 66 peerings. With sub-ASes, we require:
- 5*(5-1)/2 = 10
- 4*(4-1)/2 = 6
- 3*(3-2)/2 = 3
A total of 19 peerings, plus three more for the inter-sub-AS peerings, for a total of 22. That is a substantial reduction in administrative overhead for the same number of routers.
An AS that contains sub-ASes is known as a confederation. BGP peerings between sub-ASes resemble eBGP peerings in their configuration but behave like iBGP peerings.
You can have any number of sub-ASes within a confederation, which means that scalability is easily achievable. If a sub-AS gets too large, simply separate it into two or more sub-ASes.
BGP Confederation – Configuration Example on Cisco
Let’s take a closer look at how confederations are configured within a BGP confederation of several Cisco routers. Let’s zoom in on a particular portion of our confederation as shown below:
Now note here that R1 has three different types of peerings:
- an eBGP peering with R2 in AS 300
- an intra-sub-AS iBGP peering with R3
- an inter-sub-AS iBGP peering with R4
We assume that IGPs are configured so that all iBGP routers are reachable within AS 100, and we also assume that all routers have been configured with a loopback interface that is being used as the source for the BGP peerings.
Let’s see what the configuration on R1 looks like for these three peerings:
R1(config)#router bgp 150
R1(config-router)#bgp confederation identifier 100
R1(config-router)#bgp confederation peers 170
R1(config-router)#neighbor 2.2.2.2 remote-as 300
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
R1(config-router)#neighbor 3.3.3.3 remote-as 150
R1(config-router)#neighbor 3.3.3.3 update-source loopback 0
R1(config-router)#neighbor 4.4.4.4 remote-as 170
R1(config-router)#neighbor 4.4.4.4 update-source loopback 0
R1(config-router)#neighbor 4.4.4.4 ebgp-multihop 2
The following sections further explain the above configuration.
Setting up the sub-AS
Let’s take a look at the initial configuration of the BGP confederation:
R1(config)#router bgp 150
R1(config-router)#bgp confederation identifier 100
R1(config-router)#bgp confederation peers 170
Here we begin by creating our BGP process in R1. This is done by using AS number 150. That’s the AS number of the sub-AS to which R1 belongs.
Next, we set the confederation identifier, which is the AS number of the confederation, which in our case is 100.
Finally, using the bgp confederation peers command, we indicate all of the sub-ASes with which this router will peer, other than its own sub-AS. We can list several ASes in the same command. Here we have only one neighboring sub-AS.
eBGP peering configuration
The following commands configure the eBGP peering with R2. This is just a conventional eBGP peering:
R1(config-router)#neighbor 2.2.2.2 remote-as 300
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
The first command indicates the remote AS number as 300.
The second command indicates that the local loopback 0 interface is the source of the BGP peering. All BGP messages will be exchanged using this interface. The same command is used for all three peering types, so it won’t be further explained below.
Finally, because we are using loopbacks, these are not directly connected interfaces, thus we need the ebgp-mulihop keyword to ensure that the peering is established. (see the links at the end of the article for more information).
Intra-sub-AS iBGP peering
The following commands configure the intra-sub-AS iBGP peering with R3 which is in sub-AS 150 (the same as R1):
R1(config-router)#neighbor 3.3.3.3 remote-as 150
R1(config-router)#neighbor 3.3.3.3 update-source loopback 0
The first command indicates that we are peering with an iBGP peer within our own sub-AS. We know this because our initial BGP command that started the BGP process indicates this same AS number. So, this peering is the one that resembles an iBGP peering the most.
Inter-sub-AS iBGP peering
The following commands configure the intra-sub-AS iBGP peering with R4 which is in sub-AS 170:
R1(config-router)#neighbor 4.4.4.4 remote-as 170
R1(config-router)#neighbor 4.4.4.4 update-source loopback 0
R1(config-router)#neighbor 4.4.4.4 ebgp-multihop 2
The first command establishes the fact that we are peering with a different sub-AS of 170. This is a different sub-AS than our own. R1 knows this is a sub-AS of the same confederation due to the bgp confederation peers 170 command we issued before.
Finally, we issue the ebgp-multihop command. Now even though this is not an eBGP peering, it has to be configured like eBGP simply because we are peering across different ASes, albeit they are sub-ASes. As such, the multihop feature must be enabled in the same way as it was for eBGP.
What Problems do Confederations Solve?
Obviously, the first thing that confederations solve is they resolve the requirement of the full mesh iBGP peering. By circumventing the full mesh iBGP peering requirement, it delivers a vastly more scalable routing solution within ASes.
However, that’s not all. Confederations are very useful to resolve other issues as well including:
- Policy Application: Confederations allow for a more granular application of policies. Policies can be applied between confederation sub-ASes, which can be useful in managing routing information and traffic flows.
- Simplified Troubleshooting: By breaking a larger AS into smaller parts, it can be easier to troubleshoot and isolate issues. This division can help narrow down the source of routing issues much faster.
- Flexibility: Confederations can be combined with other BGP scaling mechanisms, such as route reflectors, to provide additional flexibility and scalability.
- Transition Mechanism: Confederations can serve as a useful transition mechanism when merging two BGP networks or when changing from one AS number to another.
- Isolation: Changes or problems in one sub-AS can be isolated from others, reducing the risk of network-wide issues.
Additional Questions
For those that are familiar with iBGP and eBGP peerings, but have not worked with confederations, the following questions may arise:
Q: How do eBGP peers see a neighboring AS if it is a confederation? Specifically for our topology, how does R2 see its peering with R1?
A: Well, from the point of view of R2, it has a regular eBGP peering. It knows nothing about the internal sub-ASes found within AS 100, and never learns about any of those from BGP updates from R1.
Q: What AS numbers can you use within a confederation?
A: You can use both private and public AS numbers for the sub-ASes within the confederation. However, it’s common practice to use private AS numbers for the internal sub-ASes, because they’re not meant to be seen by neighboring ASes or the global Internet.
Conclusion
BGP confederations offer an effective scaling mechanism by partitioning a large AS into smaller, more manageable sub-ASes, thus reducing the complexity of internal BGP peerings.
By using this approach, networks can achieve enhanced scalability, granular policy application, and simplified troubleshooting, while maintaining a singular external BGP presentation to the global Internet.
Useful Links to Related Commands:
Related Posts
- Comparison of BGP Confederations vs Route Reflectors
- 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