BGP Confederation represents one of two primary architectural solutions designed to address the inherent scalability limitations of iBGP full-mesh requirements in large autonomous systems. While Route Reflectors provide a hierarchical approach to solving the iBGP scaling problem, confederations take a fundamentally different path by subdividing a single autonomous system into multiple sub-autonomous systems that maintain special peering relationships. Understanding confederation architecture requires deep knowledge of how BGP attributes are modified during advertisement between confederation peers, how the confederation identifier mechanism preserves the appearance of a single AS to external neighbors, and how this impacts path selection, routing policies, and overall network design.
The fundamental challenge that confederations address stems from the iBGP synchronization requirement and loop prevention mechanism. In standard iBGP operation, routes learned from one iBGP peer cannot be advertised to another iBGP peer because iBGP does not modify the AS_PATH attribute. This behavior prevents routing loops but necessitates a full mesh of iBGP sessions where every router must peer with every other router in the autonomous system. The scaling implications are severe, as the number of required iBGP sessions grows quadratically according to the formula n(n-1)/2, where n represents the number of BGP speakers. An AS with 100 BGP routers requires 4,950 iBGP sessions, and 200 routers would need 19,900 sessions. Beyond the session overhead, each router must process routing updates from every other iBGP peer, creating significant CPU and memory demands that become increasingly problematic as networks scale.
Confederation architecture solves this problem by partitioning the original autonomous system into smaller sub-autonomous systems, technically referred to as member autonomous systems or confederation sub-AS numbers. These sub-AS numbers are drawn from the private AS number range. Each sub-AS operates internally with a full mesh of iBGP sessions or may itself use Route Reflectors for further scaling, but the critical distinction is that sessions between different sub-AS numbers are treated as a special type of BGP peering called confederation-eBGP or confederation-external BGP sessions. These special sessions allow routes to be advertised between sub-AS groups while maintaining modified attribute handling that preserves the confederation's unified appearance to the outside world.
The confederation identifier serves as the public-facing AS number that all routers within the confederation advertise to true external BGP peers. When a confederation router establishes an eBGP session with a router outside the confederation, it uses the confederation identifier in all BGP OPEN messages and route advertisements rather than its sub-AS number. This creates the illusion that the entire confederation is a single cohesive autonomous system from the perspective of external peers. The confederation identifier must be configured on every router participating in the confederation, and it represents what was typically the organization's original AS number before confederation deployment.
BGP Attribute Handling in Confederation Architecture
The sophisticated attribute manipulation that occurs in confederation peering distinguishes this architecture from both standard iBGP and eBGP behavior. When routes traverse confederation boundaries between sub-AS groups, BGP must modify attributes in ways that maintain proper loop prevention while preserving routing policy decisions made within the confederation. Understanding these modifications is essential for CCIE-level comprehension and for predicting routing behavior in complex confederation topologies.
The AS_PATH attribute receives special treatment through the introduction of AS_CONFED_SEQUENCE and AS_CONFED_SET path segments, defined in RFC 5065. When a route is advertised from one sub-AS to another sub-AS within the confederation, the advertising router prepends its sub-AS number to the AS_PATH, but this prepending occurs in a special confederation sequence rather than the standard AS_PATH sequence. The AS_CONFED_SEQUENCE appears in parentheses in show command outputs, visually distinguishing confederation path segments from regular AS path segments. For example, if a route originates in sub-AS 65001 and traverses through sub-AS 65002 before reaching sub-AS 65003, a router in 65003 would see an AS_PATH containing (65002 65001) followed by any pre-existing AS path from before the route entered the confederation. This confederation sequence is completely removed when the route is advertised to true external peers, ensuring that external networks see only the confederation identifier in the AS_PATH.
The AS_CONFED_SET serves an analogous purpose to the standard AS_SET, representing an unordered collection of sub-AS numbers encountered when route aggregation occurs within the confederation. If multiple routes with different AS_CONFED_SEQUENCE values are aggregated, the resulting summary route contains an AS_CONFED_SET listing all unique sub-AS numbers from the component routes. Like the AS_CONFED_SEQUENCE, the AS_CONFED_SET is stripped when routes exit the confederation boundary to external peers.
Loop prevention in confederations operates through multiple mechanisms working in concert. Within a single sub-AS, standard iBGP loop prevention applies where routes learned from iBGP peers are not re-advertised to other iBGP peers. Between sub-AS groups, the AS_CONFED_SEQUENCE provides loop prevention similar to standard eBGP behavior. When a router receives a route advertisement containing its own sub-AS number in the AS_CONFED_SEQUENCE, it rejects the route as a potential loop. This allows confederations to support arbitrary topologies between sub-AS groups without requiring a full mesh of confederation-eBGP sessions, though design considerations typically favor hierarchical or hub-and-spoke arrangements.
The NEXT_HOP attribute behavior in confederations follows modified rules compared to standard iBGP. In traditional iBGP, the NEXT_HOP attribute is not modified when routes are advertised between iBGP peers, requiring all routers to have reachability to the original next-hop address, typically achieved through IGP redistribution. In confederation architecture, when routes cross confederation boundaries via confederation-eBGP sessions, routers have the option to modify the NEXT_HOP attribute to self, similar to eBGP behavior. However, Cisco IOS defaults to preserving the original NEXT_HOP when advertising routes to confederation peers unless explicitly configured with the "#next-hop-self" command on the confederation peer session. This default preservation behavior can be advantageous in maintaining optimal routing paths but requires careful IGP design to ensure all sub-AS routers have reachability to next-hop addresses that may reside in different sub-AS groups.
The MED attribute, which normally has significance only between autonomous systems with direct connections, receives extended significance within confederation boundaries. By default, MED values are compared across confederation sub-AS boundaries during best path selection, unlike standard inter-AS scenarios where MED comparison is typically restricted to routes from the same neighboring AS. This extended MED comparison allows traffic engineering policies to influence routing decisions across the entire confederation rather than being limited to individual sub-AS groups. The "bgp always-compare-med" command, which enables global MED comparison in non-confederation scenarios, becomes particularly relevant in confederation deployments where MED-based traffic engineering may span multiple sub-AS boundaries.
The LOCAL_PREF attribute maintains its significance within confederation boundaries, behaving similarly to standard iBGP operation. LOCAL_PREF values are preserved when routes are advertised via confederation-eBGP sessions, allowing routing policies set through LOCAL_PREF manipulation to influence path selection across the entire confederation. This represents a key distinction from true eBGP sessions where LOCAL_PREF is not carried across AS boundaries. The preservation of LOCAL_PREF across confederation boundaries enables consistent implementation of traffic engineering policies throughout the confederation without requiring complex MED-based strategies.
The ATOMIC_AGGREGATE and AGGREGATOR attributes function within confederations much like standard BGP operation, but with nuanced handling of aggregator AS number representation. When a route is aggregated within a confederation sub-AS and advertised to confederation peers, the AGGREGATOR attribute contains the sub-AS number and router ID of the aggregating router. However, when this aggregated route is subsequently advertised to true external peers, the sub-AS number in the AGGREGATOR attribute is replaced with the confederation identifier, maintaining the unified AS appearance to external networks.
Configuration & Implementation
Configuring BGP confederation in Cisco IOS involves several interconnected configuration elements that must be consistently applied across all routers within the confederation. The two fundamental configuration requirements are defining the confederation identifier, which represents the public-facing AS number advertised to external peers, and specifying the set of sub-AS numbers that comprise the confederation membership. These parameters are configured within the BGP router configuration mode using the "#bgp confederation identifier" and "#bgp confederation peers" commands respectively.
Consider a confederation scenario where an organization's public AS number is 65000, and this large autonomous system has been subdivided into three sub-AS groups: 65001, 65002, and 65003. Each router is assigned membership in one of these sub-AS numbers through the standard "#router bgp" command, but all routers must additionally configure the confederation identifier and peer list. A router in sub-AS 65001 would include the following confederation-specific configuration:
Router1(config)# router bgp 65001
Router1(config-router)# bgp confederation identifier 65000
Router1(config-router)# bgp confederation peers 65002 65003
The confederation identifier specification informs the router that when it establishes BGP sessions with external peers, it should advertise AS 65000 in the BGP OPEN message and in the AS_PATH of advertised routes rather than its sub-AS number 65001. The confederation peers statement identifies the other sub-AS numbers within the confederation, enabling the router to recognize sessions with routers in AS 65002 or 65003 as confederation-eBGP sessions rather than true external eBGP sessions. This distinction triggers the modified attribute handling behavior characteristic of confederation operation.
The actual establishment of BGP sessions follows standard neighbor configuration syntax, but the session type (iBGP, confederation-eBGP, or true eBGP) is automatically determined based on the neighbor's AS number relative to the local router's configuration. A router in sub-AS 65001 establishing a session with another router also in 65001 creates an iBGP session using standard iBGP behavior. A session with a router in 65002 or 65003 becomes a confederation-eBGP session because those AS numbers appear in the confederation peers list. A session with any AS number not matching the local sub-AS and not listed in the confederation peers statement becomes a true external eBGP session.
Here is a comprehensive configuration example for a router serving as a confederation border router with multiple session types:
Router1(config)# router bgp 65001
Router1(config-router)# bgp confederation identifier 65000
Router1(config-router)# bgp confederation peers 65002 65003
Router1(config-router)# bgp log-neighbor-changes
Router1(config-router)# neighbor 10.1.1.2 remote-as 65001
Router1(config-router)# neighbor 10.1.1.2 description iBGP-PEER-WITHIN-SUBAS-65001
Router1(config-router)# neighbor 10.1.1.2 update-source Loopback0
Router1(config-router)# neighbor 10.2.1.1 remote-as 65002
Router1(config-router)# neighbor 10.2.1.1 description CONFED-EBGP-TO-SUBAS-65002
Router1(config-router)# neighbor 10.2.1.1 ebgp-multihop 2
Router1(config-router)# neighbor 10.2.1.1 update-source Loopback0
Router1(config-router)# neighbor 203.0.113.1 remote-as 64500
Router1(config-router)# neighbor 203.0.113.1 description EXTERNAL-EBGP-TO-AS-64500
Router1(config-router)# address-family ipv4 unicast
Router1(config-router-af)# neighbor 10.1.1.2 activate
Router1(config-router-af)# neighbor 10.2.1.1 activate
Router1(config-router-af)# neighbor 203.0.113.1 activate
Router1(config-router-af)# neighbor 203.0.113.1 send-community both
In this configuration, the router establishes three distinct types of BGP sessions. The session with 10.1.1.2 operates as standard iBGP because both routers belong to sub-AS 65001, requiring update-source configuration to support non-directly-connected peering. The session with 10.2.1.1 functions as confederation-eBGP because AS 65002 is listed in the confederation peers statement, automatically receiving the special attribute handling appropriate for confederation boundaries. The session with 203.0.113.1 represents true external eBGP to AS 64500, which is neither the local sub-AS nor a confederation peer, triggering standard external BGP behavior including advertisement of the confederation identifier 65000 rather than the sub-AS number.
The "#ebgp-multihop" configuration on the confederation-eBGP session may seem counterintuitive since confederation sessions receive special treatment, but it remains necessary for non-directly-connected confederation peers. While confederation-eBGP sessions implement modified attribute handling, they still operate at the BGP protocol level as eBGP sessions with different AS numbers, requiring appropriate TTL handling for multihop scenarios. The update-source configuration similarly applies to both iBGP and confederation-eBGP sessions when using loopback-based peering for stability and flexibility in IGP topology changes.
IOS XR configuration syntax follows a more hierarchical structure while implementing identical confederation functionality. The confederation identifier and peers specification occur within the BGP instance configuration, and neighbor definitions explicitly reference their session types:
RP/0/RSP0/CPU0:Router1(config)#router bgp 65001
RP/0/RSP0/CPU0:Router1(config-bgp)#bgp confederation identifier 65000
RP/0/RSP0/CPU0:Router1(config-bgp)#bgp confederation peers
RP/0/RSP0/CPU0:Router1(config-bgp-confed-peers)#65002
RP/0/RSP0/CPU0:Router1(config-bgp-confed-peers)#65003
RP/0/RSP0/CPU0:Router1(config-bgp)#neighbor 10.1.1.2
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#remote-as 65001
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#description iBGP-PEER-WITHIN-SUBAS-65001
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#update-source Loopback0
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#address-family ipv4 unicast
RP/0/RSP0/CPU0:Router1(config-bgp)#neighbor 10.2.1.1
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#remote-as 65002
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#description CONFED-EBGP-TO-SUBAS-65002
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#ebgp-multihop 2
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#update-source Loopback0
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#address-family ipv4 unicast
RP/0/RSP0/CPU0:Router1(config-bgp)#neighbor 203.0.113.1
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#remote-as 64500
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#description EXTERNAL-EBGP-TO-AS-64500
RP/0/RSP0/CPU0:Router1(config-bgp-nbr)#address-family ipv4 unicast
RP/0/RSP0/CPU0:Router1(config-bgp-nbr-af)#send-community-ebgp
RP/0/RSP0/CPU0:Router1(config-bgp-nbr-af)#send-extended-community-ebgp
RP/0/RSP0/CPU0:Router1(config-bgp-nbr-af)#commit
The IOS XR confederation peers configuration utilizes a separate sub-mode where each peer sub-AS is entered individually, providing clear organizational structure for confederations containing numerous sub-AS groups. The neighbor configuration explicitly activates address families under each neighbor context rather than using a separate address-family section, representing IOS XR's more granular configuration hierarchy.
Verification & Operational Commands
Understanding confederation operation requires comprehensive familiarity with verification commands that reveal session types, attribute modifications, and routing table states. The fundamental command for examining BGP neighbor relationships is "#show ip bgp summary" in IOS or "#show bgp summary" in IOS XR, which provides an overview of all configured BGP sessions including their current state, message counters, and table version information:
Router1# 7show ip bgp summary
BGP router identifier 10.1.1.1, local AS number 65001
BGP table version is 47, main routing table version 47
15 network entries using 3720 bytes of memory
28 path entries using 3808 bytes of memory
8/6 BGP path/bestpath attribute entries using 2112 bytes of memory
4 BGP AS-PATH entries using 128 bytes of memory
2 BGP confederation AS-PATH entries using 64 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 9832 total bytes of memory
BGP activity 23/8 prefixes, 45/17 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.2 4 65001 1842 1856 47 0 0 1d04h 8
10.2.1.1 4 (65002) 1456 1432 47 0 0 23h47m 12
203.0.113.1 4 64500 987 992 47 0 0 16h23m 5
Member discussion: