I'm going to give you just a brief overview of BGP confederations rather than describing them in detail. This will be useful background knowledge as there's still network operators today who are using BGP confederations, even though the route reflector is the BGP scaling technique of choice as far as iBGP goes. Now what a confederation is, is really taking the local Autonomous System (AS) and dividing it into several-sub Autonomous Systems. So we still have eBGP working between the local AS and the rest of the internet, but we now also have eBGP between these sub-Autonomous Systems. But that eBGP has some iBGP behaviours and of course iBGP information is also kept as well. For example, the "NEXT_HOP" is preserved across the sub-Autonomous Systems, local preferences and MEDs are preserved as well. We don't touch the IGP same as for route reflectors. BGP confederations are described in RFC5065. So confederations are visible to the outside world as a single AS. So the world doesn't see anything different. Each sub-AS uses a number from the private AS range. iBGP speakers in the sub-AS are fully meshed, or indeed we could use route reflectors within the sub-AS as some operators are doing. But the total number of neighbors is reduced by limiting the full mesh requirement to be only the peers within the sub-AS. Each sub-AS eBGP peers with each other. The diagram will explain it more simply, here we have AS 200, which is what the world sees, but it's actually made up of three sub-Autonomous Systems: AS 65530, 65531, and 65532. These three sub-ASes eBGP peer with each other, but retaining a lot of the iBGP features. And each sub-AS, 65532 and 65531, also has an eBGP session with the outside world. So in the Cisco IOS configuration example shown, we need to indicate to the router what our real world Autonomous System is and that's called the "bgp confederation identifier", and we need to list which Autonomous Systems are confederation AS members. So we need to list in this case 65530 and 65531. The router itself, router C, runs in AS 65532, it doesn't run in the globally visible AS. So as you might imagine, migrating from a full mesh iBGP set up to using BGP confederations is quite a considerable task. BGP on each and every router has to be moved out of AS 200, in this case, to one of the sub-AS Autonomous Systems. So it is a major effort and can be highly disruptive for the network when the operator makes this change. If we look at the route propagation decisions within our confederations, they're the same as with normal BGP. From peer in the same sub-AS it only goes to external peers, from external peers it goes to all neighbors. External peers refers to peers outside the configuration, as well as peers in a different sub-AS as well. And peers in a different sub-AS we preserve the "LOCAL_PREF", "MED", and "NEXT_HOP". Indeed this interesting eBGP behavior within a confederation is referred to by some operators as eiBGP, even though it isn't really defined. If you look at the BGP table, confederation ASes are displayed in the AS path usually with brackets or braces around the confederation autonomous system, and this identifies them separately from the global Autonomous Systems which may also appear in the AS path. Confederations could be useful for network operators who are absorbing other operators. For example if one ISP buys another one, we can simply add the purchased ISP's AS into the existing confederation. It's a very simple migration, rather than having to renumber the purchased ISP's routers into the new Autonomous System. And of course we can scale the sub-AS iBGP as I mentioned earlier by using route reflectors. And so like route reflectors, confederations do solve the iBGP mesh scaling problem, doesn't touch packet forwarding, and we could even apply some policies to route traffic between the different sub-ASes. However there are numerous downsides as well, and that's setting up the hierarchy of sub-Autonomous Systems and how they interconnect with each other. Path diversity could be an issue, and as already highlighted the really difficult migration, as we have to reconfigure BGP almost across the entire network all at the same time. So if you're choosing whether to use route reflectors or confederations, they actually compare quite well for most features. Internet connectivity can be made anywhere in the network, they support multi-level hierarchy, and both give good policy control. Scalability for route reflectors is arguably much higher than it is for confederations, and the migration complexity for confederations is much higher than it is for route reflectors. Route reflectors can be deployed, as I said earlier, disruption free, but better during the maintenance period on a network. Whereas confederation needs planning for a notable outage for the network, while BGP is configured on all the affected routers. And indeed, in my experience, most new network operators today are deploying route reflectors right from the start.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.