The Promise on Paper
The Border Gateway Protocol (BGP) has a fundamental rule for its internal configuration (iBGP): every router must have a direct connection to every other router within the same Autonomous System (AS). This 'full mesh' requirement doesn't scale well; the number
of connections explodes as you add more routers. BGP confederations solve this by dividing a single large AS into multiple smaller, private 'sub-ASes'. From the outside world, it all looks like one single, unified AS. Inside, however, the sub-ASes are linked using what looks like external BGP (eBGP). This clever trick gets around the full-mesh rule, allowing the network to scale while maintaining a consistent external policy. On paper, it's an elegant way to manage a massive network.
The Complexity Tax
The first stumbling block is the sheer operational overhead. Instead of simplifying the network, a confederation introduces a new layer of abstraction with its own rules. Each sub-AS still needs its own internal full mesh or its own set of route reflectors. Configuration becomes more complex because you're not just managing iBGP and eBGP; you're managing special 'confederation-eBGP' sessions between sub-ASes that behave like iBGP in some ways (like how they pass attributes) but like eBGP in others. This hybrid nature is a common source of confusion and misconfiguration that can lead to routing loops or policy conflicts. You are essentially trading one big, complex problem for several smaller, interconnected, and equally complex ones.
The Attribute Black Hole
One of the most infamous ways confederations trip up engineers is in how they handle BGP attributes used for traffic engineering. The Multi-Exit Discriminator (MED), an attribute used to signal a preferred entry point into an AS, is a prime example. By default, MED values are not compared between different sub-ASes within a confederation. This can completely break traffic engineering that relies on MED to influence routing decisions. While there are commands to change this behavior, it's an easy detail to miss and can lead to suboptimal or unpredictable traffic flow. Local Preference and Next-Hop attributes also follow special rules across confederation boundaries that differ from standard iBGP, adding more potential for error.
Migration and Visibility Nightmares
You can't just flip a switch to enable a confederation on a live network. The migration process is highly disruptive, requiring configuration changes on every single router within the AS. This is a high-risk, meticulously planned project. Furthermore, troubleshooting becomes more difficult. From outside the confederation, the internal path through the various sub-ASes is invisible; the AS_PATH is scrubbed of the private sub-AS numbers before it's advertised externally. While this is by design, it means that diagnosing routing issues can require logging into routers across multiple sub-ASes to piece together the full picture, complicating what might otherwise be a straightforward task.
The Rise of a Better Alternative
Perhaps the biggest reason confederations are a pitfall is that a simpler, more popular solution exists: route reflectors. Route reflectors solve the same iBGP scaling problem by allowing a designated router to 'reflect' routes to clients, eliminating the need for a full mesh without partitioning the AS. This approach requires far less configuration—you only need to configure the reflectors, while the 'client' routers remain largely unchanged. For the vast majority of networks, route reflectors provide the same scaling benefits with significantly less complexity and fewer 'gotchas'. As a result, confederations have become a niche solution, primarily used by massive service providers who require the rigid administrative separation between network domains that sub-ASes provide.
