Another option for not requiring a full iBGP mesh between routers is to break the routers into sub-autonomous systems. This is referred to as confederating the autonomous systems. Let’s jump right into an example of this so you can see what I’m talking about…
Here we have 4 autonomous systems. Router1, 2, 3, and 4 are part of AS400. In addition, routers 1 and 2 are part of a sub-AS 200. Likewise routers 3 and 3 are part of the sub-AS 300. The configuration is pretty straight forward. Let’s take a look at what we configured…
You can disregard the ‘path-mtu-discovery’ commands, those are defaults on some of the lab gear I’m using. Looking at router2 will give us the best idea of how this is configured…
Router2 has a eBGP peer, an iBGP sub-AS peer, and a eBGP peer to another sub-AS. The first peer is the normal eBGP peer to router5. The second is the iBGP peer to router1. The third is the eBGP peering to router3. All of these configurations look like normal BGP peerings. The only real difference in the BGP configuration is the ‘bgp confederation identifier’ and the ‘bgp confederation peers’ commands.
These two commands are required in order for any of the BGP confederation to work. For instance, router5 thinks it’s peering with AS 400. However, router2’s BGP configuration is in AS 200. The BGP confederation ID tells router2 to peer externally to non-confederated BGP peers using the AS of 400. The BGP confederation peers command tells the router which autonomous systems belong to the confederation. In this case, that’s only AS 300. These autonomous systems will peer with the BGP speaker using it’s confederation AS.
So now that we have the basis of the BGP confederation configuration let’s take a look at the BGP tables on all of the routers…
We can see that router5 is originating the 192.168.5.0/24 prefix. Let’s take a look at router2 to see how it sees the prefix…
Router2 is directly connected eBGP to router5. We can see that the next hop is router5’s directly connected interface and the AS-PATH shows AS 100 which is the AS that router5 is in. Looking at router1 we’ll see the same thing since it’s iBGP peered to router2…
Now if we look at router3 we’ll see something interesting…
Note that the AS-PATH list shows the last AS as being ‘(200)’. Let’s look at the diagram again to see how that makes sense…
It looks like AS200 is the sub-autonomous system that routers 2 and 1 are in. If we look at router4, we see the same BGP table…
Any time you see a AS with parenthesis around it in the AS path you know two things. One, the router you are looking at is part of a sub-AS. Two, the router you are learning that prefix from is part of a sub-AS. Let’s originate a prefix from router4 and see what happens…
Looking at router2’s BGP table we see that it knows that the prefix is coming from a sub-AS…
However, when we look at router5, we see that it thinks the prefix is coming from the larger AS (400)…
So the concept makes sense, but I struggle to see a valid use case for doing this. BGP confederations seem to add unnecessary complexity to routing designs and they really don’t buy you anything over what a route reflector can do. However, there are some corner use cases where they could be used. Notice how router5 above doesn’t see any of the sub-AS numbers in it’s AS PATH attribute for the 192.168.4.0 /24 prefix. Technically, this means I could reuse AS numbers in the sub autonomous systems that were already in use outside of the parent AS. AKA, router5 could be peered to router6 in AS 300…
When we look at router6’s BGP table we notice that it has the prefix being advertised from router4…
Router6 has no idea that the prefix actually originated from AS 300 since AS 300 is a sub-AS of AS 400.
So confederations have some use cases but I don’t really see the win over using something like route reflectors.
Pingback: BGP confederations – skminhaj