Route reflectors are the most common solution for scaling iBGP, but they're not the only one. BGP confederations take a different approach: instead of designating special routers that can break the split-horizon rule, confederations divide the AS into smaller sub-autonomous systems. Within each sub-AS, you run iBGP (with a full mesh or route reflectors). Between sub-ASes, you run a modified form of eBGP that preserves iBGP-like behavior for the attributes that matter.
How Confederations Work
A confederation makes a single AS appear as one AS to the outside world while internally being divided into multiple sub-ASes. External peers see only the confederation's real ASN — sub-AS numbers are stripped from the AS-path before routes are advertised to true eBGP peers.
Between sub-ASes, BGP sessions are "confederation eBGP" — they behave like eBGP (next-hop changes, TTL is 1 by default, AS-path is modified) but with key differences:
- Sub-AS numbers are prepended to a special confederation segment in the AS-path (displayed in parentheses)
- LOCAL_PREF is preserved across confederation eBGP sessions (unlike true eBGP)
- MED is preserved across confederation eBGP sessions
- Confederation AS-path segments don't count toward AS-path length in best path selection (step 4)
Configuration
Let's say we split AS 65001 into two sub-ASes: sub-AS 65501 (containing R1-HQ) and sub-AS 65502 (containing R2-HQ).
On R1-HQ (sub-AS 65501):
R1-HQ(config)# router bgp 65501
R1-HQ(config-router)# bgp confederation identifier 65001
R1-HQ(config-router)# bgp confederation peers 65502
R1-HQ(config-router)# neighbor 2.2.2.2 remote-as 65502
R1-HQ(config-router)# neighbor 2.2.2.2 update-source Loopback0
R1-HQ(config-router)# neighbor 172.16.0.2 remote-as 65010On R2-HQ (sub-AS 65502):
R2-HQ(config)# router bgp 65502
R2-HQ(config-router)# bgp confederation identifier 65001
R2-HQ(config-router)# bgp confederation peers 65501
R2-HQ(config-router)# neighbor 1.1.1.1 remote-as 65501
R2-HQ(config-router)# neighbor 1.1.1.1 update-source Loopback0Key commands:
router bgp 65501— the local sub-AS numberbgp confederation identifier 65001— the real AS number seen by the outside worldbgp confederation peers 65502— lists other sub-ASes in the confederationneighbor 2.2.2.2 remote-as 65502— since 65502 is listed as a confederation peer, this creates a confederation eBGP session (not a true eBGP session)
External peers (ISP-A-PE1) still see AS 65001:
ISP-A-PE1# show ip bgp 10.1.0.0/16
...
65001
172.16.0.1 from 172.16.0.1 (1.1.1.1)
Origin IGP, valid, external, bestThe sub-AS numbers (65501, 65502) are completely invisible to external peers.
AS-Path with Confederations
Internally, the confederation sub-AS numbers appear in parentheses:
R2-HQ# show ip bgp 100.64.0.0/18
...
(65501) 65010
1.1.1.1 from 1.1.1.1 (1.1.1.1)
Origin IGP, localpref 100, valid, confed-external, bestThe (65501) is the confederation segment — it shows the route passed through sub-AS 65501. The real AS-path (65010) follows. For best path selection step 4 (shortest AS-path), only the real AS-path length counts — confederation segments are ignored.
Route Reflectors vs Confederations
| Aspect | Route Reflectors | Confederations |
|---|---|---|
| Complexity | Simple — one command per client | Moderate — sub-AS design, renumbering |
| Migration | Easy — add RR config, clients unchanged | Hard — every router changes its local AS |
| Path selection impact | RR may choose suboptimal path for clients | Each sub-AS makes local decisions; more natural |
| Scalability | Hierarchical RRs scale very large | Each sub-AS still needs internal full mesh or RRs |
| Common usage | Enterprise and SP — dominant approach | Some large SPs with natural regional divisions |
In practice, route reflectors win almost every time due to simpler migration and operation. Confederations are mainly seen in very large service providers where the network has natural regional divisions that map cleanly to sub-ASes, or in networks acquired through mergers where each entity already had its own AS.
Verification
R1-HQ# show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 65501
BGP confederation identifier: 65001
BGP confederation peers: 65502
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.0.2 4 65010 286 274 18 0 0 04:42:18 4
2.2.2.2 4 65502 156 162 18 0 0 02:33:41 2R1-HQ# show ip bgp neighbors 2.2.2.2 | include confed
Neighbor under common administration
Member of confederation AS 65001Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| External peer sees sub-AS numbers in AS-path | bgp confederation identifier not set, or set to wrong ASN | Verify bgp confederation identifier matches the real public ASN on all routers. |
| Confederation eBGP peer stuck in OpenSent | Remote sub-AS not listed in bgp confederation peers | Add the peer's sub-AS to bgp confederation peers on both sides. |
| Routes between sub-ASes losing to longer external paths | Confederation AS-path segments being counted in path length | Verify IOS XE version — confederation segments should not count. Check show ip bgp [prefix] for actual path length comparison. |
Key Takeaways
- Confederations divide one AS into sub-ASes, using modified eBGP between them to eliminate the full mesh requirement.
- Sub-AS numbers are invisible to external peers — only the confederation identifier (real ASN) appears in the AS-path.
- LOCAL_PREF and MED are preserved across confederation eBGP boundaries, unlike true eBGP.
- Route reflectors are simpler to deploy and migrate to — choose confederations only when the network has a natural sub-AS structure.
- Confederation AS-path segments don't count toward best path AS-path length comparison.
