If you mention BGP confederations in a group of network engineers, you’ll get a split reaction. Some people will immediately recognize what they are and nod knowingly. Others will tilt their head slightly like a dog that heard a strange sound. Both reactions are completely reasonable.
Confederations solve the same problem as route reflectors, which is iBGP full mesh scalability. They solve it differently, and that different approach has legitimate use cases and real trade-offs. Neither the obvious answer nor some bizarre legacy relic. Just a different tool with a different set of trade-offs.
The Problem They Solve
You already know this one. iBGP full mesh doesn’t scale. The n(n-1)/2 math means session count grows as the square of router count. For large autonomous systems with hundreds of BGP-speaking routers, full mesh is completely impractical.
Route reflectors solve this by designating specific routers to re-advertise iBGP routes. Confederations solve it by dividing the AS into smaller sub-autonomous systems.
How Confederations Work
A BGP confederation takes a single public AS and splits it into multiple sub-ASes internally. From the outside world, the confederation looks like a single AS. Your public ASN is the one that appears in AS_PATHs on the internet. The internal sub-AS structure is invisible to the rest of the world.
Inside the confederation, the sub-ASes run modified eBGP sessions with each other. This is the key point. Because these sessions are treated as eBGP, routes can be re-advertised between routers in different sub-ASes without violating the iBGP split horizon rule. The full mesh requirement applies only within each individual sub-AS.
Within a sub-AS that has, say, 10 routers, you need a full mesh of 45 sessions for those 10 routers. But across the confederation boundary to other sub-ASes, you use eBGP-like sessions and can freely redistribute routes.
The AS_PATH Behavior
Here’s where confederations get interesting from an attribute perspective.
When a route crosses a confederation boundary, BGP adds the sub-AS number to the AS_PATH. But it adds it using the CONFED_SEQUENCE and CONFED_SET attributes, which are distinct from regular AS_PATH segments.
External BGP peers, the ones who see your public ASN from the internet, never see your internal sub-AS numbers. Before a route reaches an external peer, BGP strips the confederation sub-AS entries from the AS_PATH. What’s left is the standard path that external networks see, with only your public ASN and the paths of the ASes beyond you.
Internally, the sub-AS numbers in the path serve the same loop prevention function as regular AS_PATH. If a router in sub-AS 65001 sees its own sub-AS number in an incoming update’s CONFED_SEQUENCE, it discards the update.
The Configuration
First, decide on your confederation structure. You’ll have a public confederation identifier (your real ASN) and private sub-AS numbers for the internal divisions.
On all routers within the confederation, configure the public confederation identifier and the list of sub-ASes that are part of the confederation, below is an example configuration for a device in AS 65100:
router bgp 65100
bgp confederation identifier 100
bgp confederation peers 65101 65102
In this example, 100 is the public AS that the rest of the internet sees. 65100, 65101, and 65102 are the internal sub-ASes. Each router’s local AS is the sub-AS it belongs to (65100, 65101, or 65102). The bgp confederation identifier command tells BGP what the public-facing AS number is. The bgp confederation peers command tells this router which ASes are also confederation members so it can treat sessions to them differently.
Sessions between confederation sub-ASes look like eBGP in terms of setup, different AS numbers on each side, default TTL of 1, but they’re treated as confederation sessions with special rules about next-hop behavior and attribute handling. If confederation peers aren’t directly connected, you’ll need ebgp-multihop just as you would for any eBGP session across multiple hops
Within each sub-AS, routers need iBGP full mesh or their own route reflector structure.
When Confederations Actually Make Sense
Route reflectors are simpler to deploy and simpler to understand. For most networks, they’re the right answer to the full mesh scaling problem.
Confederations start making sense when you have a large AS where different parts of the AS are operated by different teams with different policies, and you want clean administrative separation between them. The sub-AS boundaries give you a natural point to apply policy between internal network domains.
Some carriers use confederations to separate their network into regional sub-domains. Each region runs its own iBGP topology internally, and the regions interconnect via confederation eBGP sessions. This gives regional teams autonomy over their internal routing while the whole thing still appears as one AS to the rest of the internet.
Confederations also interact differently with BGP attributes in some edge cases, particularly around MED comparison across confederation boundaries. This can be either a feature or a complication depending on your traffic engineering requirements.
The Honest Trade-off
Confederations are harder to design, harder to configure, harder to document, and harder to explain to the next engineer. If you deploy confederations and that engineer has never seen them before, you’ve created a knowledge gap that will hurt you on the first incident that touches the iBGP topology.
Route reflectors are conceptually simpler. The split horizon rule, the CLUSTER_LIST loop prevention, the client/non-client distinction. All of that is well-documented and well-understood by anyone who’s seriously studied BGP.
Confederations require understanding a second layer of AS semantics on top of everything else. The sub-AS structure, the confederation-specific attribute handling, the stripping of internal AS numbers for external advertisements. It’s not impossible, but it’s more to learn and more surface area for mistakes.
For most enterprise and data center environments, route reflectors are the answer. Confederations are worth understanding because they’re part of the BGP toolkit and you may encounter them in carrier networks, but they shouldn’t be your default approach without a specific reason.
Verification
Check the confederation configuration:
show bgp summary
show bgp neighbors x.x.x.x
Look for Confederation Member in the neighbor output to confirm the session is recognized as a confederation peer.
There are two ways a route will show up in confederations
- Confed-Internal
- This means that the route is learned from your confederation
R1#show ip bgp 10.2.0.0/24
BGP routing table entry for 10.2.0.0/24, version 10
Paths: (1 available, best #1, table default)
Flag: 0x100
Advertised to update-groups:
1
Refresh Epoch 1
Local
2.2.2.2 (metric 1) from 2.2.2.2 (2.2.2.2)
Origin IGP, localpref 100, valid, confed-internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 13 2026 21:20:29 UTC- Confed-external
- This route was learned via an external confederation peer
R1#show ip bgp 10.5.0.0/24
BGP routing table entry for 10.5.0.0/24, version 5
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
(65002 65003)
172.16.13.2 from 172.16.13.2 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 13 2026 21:17:48 UTCTo see the CONFED_SEQUENCE in an AS_PATH:
show bgp ipv4 unicast 172.20.0.0/16
R1#show ip bgp ipv4 unicast 172.20.0.0/16
BGP routing table entry for 172.20.0.0/16, version 6
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
(65002 65003) 200
172.16.13.2 from 172.16.13.2 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 13 2026 21:18:18 UTC
Internal sub-AS numbers appear in parentheses in the AS_PATH field: (65002 65003) 200. The parenthesized portion is the confederation path. When this route reaches an external peer, BGP strips that parenthesized portion and external peers see only: 100.