How BGP Confederations Work: Scaling iBGP with Sub-AS Partitioning

A BGP confederation is a mechanism for partitioning a single autonomous system into multiple smaller internal sub-ASes that use eBGP procedures between them, while appearing as one unified AS to the outside world. Confederations solve the iBGP full-mesh scalability problem -- as the number of routers in an AS grows, the number of required iBGP sessions grows quadratically, and confederations break that growth curve by organizing routers into manageable groups that peer with each other using a modified form of eBGP.

Defined in RFC 5065 (originally RFC 1965, then RFC 3065), BGP confederations introduce their own AS path segment types -- CONFED_SEQUENCE and CONFED_SET -- and a distinct set of rules for how routes are propagated within and between sub-ASes. Confederations are one of two widely deployed solutions to the iBGP scaling problem, the other being route reflectors. Understanding when to use each, and how confederations interact with BGP's path attributes, is critical for anyone designing or operating large-scale networks.

The iBGP Full-Mesh Problem

Within an autonomous system, iBGP has a fundamental rule: a router that learns a route via iBGP must not re-advertise that route to another iBGP peer. This rule exists to prevent routing loops -- since iBGP does not modify the AS path (all routers share the same AS number), the normal AS path loop-detection mechanism cannot catch internal loops. The consequence of this rule is that every iBGP router must peer with every other iBGP router in a full mesh, so that every router can learn every external route directly.

For a network with n iBGP routers, the number of required sessions is:

sessions = n * (n - 1) / 2

This grows quadratically:

• 10 routers = 45 sessions
• 50 routers = 1,225 sessions
• 100 routers = 4,950 sessions
• 500 routers = 124,750 sessions

At scale, the full mesh becomes unmanageable. Each session consumes memory for the TCP connection, the BGP neighbor state machine, and a copy of the full routing table received from that peer. Every route update must be replicated across all sessions. The CPU, memory, and convergence costs grow to the point where adding a single new router means establishing sessions with every existing router in the AS.

The full mesh on the left requires 15 iBGP sessions for just 6 routers. The confederation on the right divides them into three sub-ASes of 2 routers each. Each sub-AS needs only 1 iBGP session internally, plus a few inter-sub-AS eBGP sessions to connect the groups -- dramatically fewer total sessions. As the network grows to hundreds of routers, this reduction becomes the difference between a manageable and an unmanageable control plane.

How Confederations Work

A BGP confederation takes a single public AS number and subdivides it into multiple Member-ASes (also called sub-ASes). Each sub-AS operates internally as a normal autonomous system with its own iBGP mesh (or its own route reflectors). Between sub-ASes, routers run a modified form of eBGP that preserves many iBGP properties -- specifically, attributes like LOCAL_PREF and MED are preserved across sub-AS boundaries, unlike true eBGP where they would be reset or removed.

The key principles:

• Within a sub-AS -- Routers run standard iBGP. The normal iBGP full-mesh requirement applies, but only within the sub-AS, not across the entire confederation. A sub-AS of 10 routers needs only 45 iBGP sessions instead of the thousands that would be needed for a full-mesh of the entire AS.
• Between sub-ASes -- Border routers run confederation eBGP (sometimes called "confed-eBGP"). This uses eBGP mechanics (TTL, next-hop behavior) but preserves iBGP-like attribute handling. Routes exchanged between sub-ASes carry confederation-specific AS path segments.
• To the outside world -- All confederation members appear as a single AS. When a border router advertises routes externally via true eBGP, it strips the confederation AS path segments and replaces them with the confederation's public AS number. External peers see a normal AS path with no indication that the network uses confederations internally.

Confederation AS Path Attributes

Confederations introduce two special AS path segment types, distinct from the standard AS_SEQUENCE and AS_SET:

AS_CONFED_SEQUENCE (type 3)

An AS_CONFED_SEQUENCE is an ordered list of sub-AS numbers that a route has traversed within the confederation. It is analogous to AS_SEQUENCE but is used exclusively for confederation member-AS numbers. When a route crosses from one sub-AS to another, the sending sub-AS prepends its member-AS number to the AS_CONFED_SEQUENCE.

For example, consider a route originating from an external AS 64496 that enters the confederation through sub-AS 65001, passes through sub-AS 65002, and reaches a router in sub-AS 65003. Inside the confederation, the AS path would look like:

(65001 65002) 64496

The parentheses denote the CONFED_SEQUENCE. When this route is advertised externally by sub-AS 65003, the confederation path segments are stripped entirely:

64500 64496

The external peer sees only the confederation's public AS number (64500) and the origin AS (64496). The internal sub-AS topology is invisible.

AS_CONFED_SET (type 4)

An AS_CONFED_SET is the confederation equivalent of AS_SET. It is an unordered set of member-AS numbers, used when routes from multiple sub-ASes are aggregated within the confederation. Like AS_SET, AS_CONFED_SET is rarely used in practice and carries the same complications for route validation. The sub-AS numbers in a CONFED_SET are stripped along with CONFED_SEQUENCE when routes leave the confederation.

Path Length Calculation

A critical detail: confederation AS path segments do not count toward the AS path length used in BGP best-path selection. RFC 5065 specifies that only AS_SEQUENCE and AS_SET segments contribute to the path length. This means a route that traverses five sub-ASes within a confederation has the same effective path length as a route that enters the confederation directly. This prevents the internal confederation topology from distorting external routing decisions.

However, confederation path segments are used for loop detection within the confederation. If a router receives a route with its own member-AS number in the CONFED_SEQUENCE, it rejects the route, just as a standard BGP router rejects routes containing its own AS number in the AS_SEQUENCE.

Configuration and Member-AS Assignment

Setting up a BGP confederation requires configuring each router with:

• Confederation identifier -- The public AS number that the entire confederation presents to the outside world. This is the number visible in the global routing table.
• Member-AS number -- The sub-AS number assigned to this router's group. These are typically drawn from the private AS range (64512-65534 for 16-bit, or 4200000000-4294967294 for 32-bit) to avoid conflicts with publicly routable ASNs.
• Confederation peers -- A list of all member-AS numbers in the confederation, so the router knows which AS numbers are internal to the confederation versus external.

A typical configuration on a Cisco IOS router might look like:

router bgp 65001
  bgp confederation identifier 64500
  bgp confederation peers 65002 65003
  neighbor 10.0.12.2 remote-as 65002
  neighbor 10.0.1.2 remote-as 65001

In this example, the router belongs to sub-AS 65001 and knows that 65002 and 65003 are also confederation members. The session to 10.0.12.2 (in sub-AS 65002) will use confederation eBGP procedures, while the session to 10.0.1.2 (also in sub-AS 65001) uses standard iBGP. External eBGP sessions to non-confederation ASes specify the confederation identifier (64500) as the local AS.

Sub-AS Design Considerations

How to partition routers into sub-ASes is a design decision that affects both operational complexity and routing efficiency. Common strategies include:

• Geographic grouping -- Assign one sub-AS per region (e.g., sub-AS 65001 for North America, 65002 for Europe, 65003 for Asia). This aligns with typical network topologies where routers within a region are densely connected and inter-region links are relatively sparse.
• Functional grouping -- Assign sub-ASes based on network function: core routers in one sub-AS, edge/aggregation routers in another. This can simplify policy but may not reduce session counts as effectively if functional groups are large.
• POP-level grouping -- Each Point of Presence (POP) or data center gets its own sub-AS. This creates many small sub-ASes with very simple internal iBGP meshes (often just 2-4 routers each).

The optimal partition depends on the network's physical topology. The goal is to minimize the number of inter-sub-AS links while keeping each sub-AS small enough that its internal iBGP mesh is manageable.

Attribute Handling Across Sub-AS Boundaries

One of the defining characteristics of confederation eBGP is how it handles BGP attributes. Unlike true eBGP, confederation eBGP sessions preserve several attributes that would normally be reset at AS boundaries:

• LOCAL_PREF -- Preserved across sub-AS boundaries. This is essential because LOCAL_PREF is the primary tool for expressing routing policy within an AS. If it were reset at sub-AS boundaries, operators would lose the ability to set network-wide path preferences. A route with LOCAL_PREF 200 set in sub-AS 65001 arrives in sub-AS 65002 with LOCAL_PREF 200 intact.
• MED (Multi-Exit Discriminator) -- Preserved across sub-AS boundaries. In true eBGP, MED is only compared between routes from the same neighboring AS. Within a confederation, MED comparison rules can span sub-ASes, allowing consistent exit-point selection across the entire network.
• NEXT_HOP -- Follows eBGP rules by default: the next-hop is set to the address of the confederation eBGP peer. However, operators commonly configure next-hop-self on confederation eBGP sessions to ensure reachability, since the next-hop must be reachable via the IGP within each sub-AS.
• COMMUNITY and EXTENDED COMMUNITY -- Preserved across sub-AS boundaries. BGP communities propagate through the confederation just as they would within a normal iBGP mesh.

This attribute preservation is what makes confederations transparent to routing policy. Operators can apply LOCAL_PREF and community-based policies as if the network were a single AS with a normal iBGP mesh, even though the underlying transport uses eBGP mechanics between sub-ASes.

Confederations vs. Route Reflectors

Confederations and route reflectors are both solutions to the iBGP full-mesh problem, but they take fundamentally different approaches. Route reflectors relax the iBGP re-advertisement rule by designating certain routers as "reflectors" that can forward iBGP-learned routes to other iBGP peers. Confederations, by contrast, replace a subset of iBGP sessions with confederation eBGP sessions.

When Confederations Win

• Clear administrative boundaries -- When the network is already logically divided into regions or organizational units with distinct operations teams, confederations formalize those boundaries. Each sub-AS can be managed somewhat independently, with its own IGP domain, its own internal iBGP mesh, and its own operational procedures.
• Best-path consistency -- Route reflectors can cause suboptimal routing because clients only see the reflector's best path, not all available paths. Confederations do not have this problem: confederation eBGP peers exchange routes like normal eBGP peers, and each sub-AS makes its own independent best-path decision based on the full set of available routes from its confederation eBGP peers.
• MED handling -- In route reflector designs, MED comparison between routes from different exit points can be inconsistent because clients may not see all alternatives. Confederations preserve MED across sub-AS boundaries and allow each sub-AS to make MED comparisons with full visibility.
• Mergers and acquisitions -- When two networks merge under a single AS number, confederations provide a natural way to integrate them. Each legacy network becomes a sub-AS, preserving its existing iBGP structure, while confederation eBGP links connect them at border points.

When Route Reflectors Win

• Simplicity of deployment -- Route reflectors can be deployed incrementally. You designate one or more routers as reflectors, configure their clients, and you are done. No router needs to change its AS number. No new AS path types appear. The migration path from a full mesh to route reflectors is straightforward and can be done one cluster at a time.
• Operational familiarity -- Most network engineers encounter route reflectors far more often than confederations. Troubleshooting route-reflector issues relies on standard iBGP concepts (ORIGINATOR_ID, CLUSTER_LIST) that are well-documented and widely understood. Confederation troubleshooting requires understanding CONFED_SEQUENCE behavior, confederation eBGP next-hop rules, and the interaction between sub-AS numbering and routing policy -- a smaller knowledge base in the industry.
• Vendor support and tooling -- While all major vendors support confederations, route reflectors receive more attention in vendor documentation, lab guides, and certification curricula. Monitoring tools and network management platforms are generally better at visualizing route-reflector topologies than confederation topologies.
• Virtual route reflectors -- Modern deployments often use virtual route reflectors running on commodity servers (e.g., using BIRD, OpenBGPD, or GoBGP). These software-based reflectors can handle millions of routes and scale horizontally without requiring expensive router hardware. This has further reduced the operational case for confederations.

The Hybrid Approach

Confederations and route reflectors are not mutually exclusive. A confederation can use route reflectors within each sub-AS. This hybrid design combines both scaling mechanisms: the sub-AS provides a coarse partition of the network, and route reflectors within each sub-AS eliminate the full mesh at the finer level. For very large networks with hundreds or thousands of routers, this two-tier hierarchy can be the most practical approach.

Interaction with Local Preference and Best-Path Selection

Because confederation eBGP preserves LOCAL_PREF, operators can set routing policy at the confederation level just as they would in a non-confederation AS. A route entering through sub-AS 65001 can be tagged with LOCAL_PREF 200, and that preference will be honored by routers in sub-AS 65002 and 65003 when they compare it against alternative paths.

The BGP best-path algorithm within a confederation follows these steps, in order:

1. Highest LOCAL_PREF -- Unchanged from standard BGP. Applies across the entire confederation.
2. Shortest AS_PATH -- Only AS_SEQUENCE and AS_SET segments count. CONFED_SEQUENCE and CONFED_SET are excluded from the length calculation. A route that traverses three sub-ASes has the same effective path length as one that stays within a single sub-AS.
3. Origin type -- IGP < EGP < INCOMPLETE. Unchanged.
4. Lowest MED -- Compared between routes from the same neighboring AS. MED is preserved across sub-AS boundaries, so MED comparisons work correctly for routes that enter the confederation at different sub-ASes but originate from the same external AS.
5. eBGP over confederation eBGP over iBGP -- If multiple paths remain, routes learned via true eBGP (from external ASes) are preferred over routes learned via confederation eBGP (from other sub-ASes), which are in turn preferred over routes learned via iBGP (from within the same sub-AS).
6. Lowest IGP metric to NEXT_HOP -- Standard hot-potato routing. Because confederation eBGP changes the next-hop (by default), the IGP metric calculation is scoped to the router's own sub-AS and any confederation eBGP next-hops that are reachable.

Step 5 is unique to confederations. It creates a preference hierarchy: external routes are most preferred, then routes from other sub-ASes, then routes from within the local sub-AS. This generally produces sensible behavior -- a route learned directly from an external peer is preferred over the same route relayed through another sub-AS.

RFC 5065: The Specification

RFC 5065 ("Autonomous System Confederations for BGP") is the current specification for BGP confederations. It superseded RFC 3065 (2001), which in turn superseded the original RFC 1965 (1996). The key provisions of RFC 5065 include:

• Confederation identifier -- A mandatory configuration parameter: the public AS number of the confederation as a whole.
• Member-AS -- Each router is configured with its sub-AS number and the list of all member-AS numbers in the confederation.
• AS_CONFED_SEQUENCE and AS_CONFED_SET -- Defined as AS path segment types 3 and 4, respectively. These segments are used to record the sequence of sub-ASes a route has traversed within the confederation.
• Stripping on external advertisement -- When a route is advertised to a true eBGP peer (a non-member AS), all CONFED_SEQUENCE and CONFED_SET segments must be removed from the AS path, and the confederation identifier must be prepended as a normal AS_SEQUENCE entry.
• Loop detection -- A router must reject a route if its own member-AS number appears in any CONFED_SEQUENCE or CONFED_SET segment.
• Path length -- CONFED_SEQUENCE and CONFED_SET segments are explicitly excluded from the path length calculation used in best-path selection.

RFC 5065 also notes that the confederation mechanism does not change the BGP decision process itself -- it only changes how AS path segments are constructed and interpreted for routes traveling within the confederation. All other BGP attribute handling, including community processing, origin validation, and next-hop resolution, follows the standard specifications.

Operational Deployment Patterns

While route reflectors have become the dominant solution for iBGP scaling, confederations remain deployed in several specific contexts:

Large Tier-1 and Tier-2 ISPs

Some of the largest ISPs in the world use confederations, particularly those with networks that span multiple continents and have distinct regional operations teams. The confederation boundary aligns with organizational boundaries, giving each regional team autonomy over their sub-AS while maintaining a unified global AS identity. Historical examples include networks that chose confederations in the late 1990s and early 2000s -- before route reflectors were as mature -- and have maintained that architecture since.

Multi-AS Mergers

When two networks with different AS numbers merge, confederations offer a migration path that does not require immediately re-numbering all routers. Each original AS becomes a sub-AS under a new confederation identifier (or one absorbs the other). Routes continue to flow during the transition, and the external view remains a single AS. Over time, the network may migrate to a flat route-reflector design, but the confederation provides an immediate integration mechanism.

MPLS VPN Deployments

In networks running MPLS VPN services, the interaction between BGP confederations and VPNv4/VPNv6 address families requires careful design. MP-BGP sessions between sub-ASes must carry the VPN address families, and the next-hop handling for VPN routes (which typically uses the loopback address of the PE router) must account for the confederation eBGP next-hop change behavior. Some operators prefer confederations in MPLS environments precisely because the next-hop change at sub-AS boundaries provides a natural point for inter-region traffic engineering.

Migration Away from Confederations

A notable trend in the industry is migration away from confederations toward route reflectors. The motivations are typically operational simplicity, better tooling support, and the availability of software-based route reflectors. Migrating from confederations to route reflectors is a complex undertaking: it requires re-numbering routers back to the original AS number, removing confederation configurations, establishing route-reflector clusters, and coordinating the cutover to avoid routing disruptions. This migration is usually done incrementally, one sub-AS at a time, with careful monitoring at each step.

Common Pitfalls and Troubleshooting

Operators working with confederations encounter several recurring issues:

• NEXT_HOP reachability -- Because confederation eBGP changes the next-hop by default, the IGP within each sub-AS must be able to resolve next-hops for confederation eBGP peers. If the IGP domains of different sub-ASes do not overlap (which they usually should not, by design), routers in one sub-AS cannot resolve next-hops that point to routers in another sub-AS unless next-hop-self is configured on the confederation eBGP border routers. Failing to set next-hop-self is one of the most common confederation misconfigurations.
• Incomplete confederation peer lists -- Every router must know all member-AS numbers. If a new sub-AS is added but some routers are not updated with the new member-AS number, those routers will treat routes from the new sub-AS as external eBGP routes -- stripping attributes, changing next-hop handling, and applying external route policies. This can cause subtle routing asymmetries that are difficult to diagnose.
• AS path confusion -- When examining routes inside a confederation, the AS path contains a mix of CONFED_SEQUENCE segments and normal AS_SEQUENCE segments. Operators must understand which segments count toward path length and which are used only for loop prevention. Router CLI output formats these differently (typically parentheses for confederation segments), but scripts and monitoring tools may not handle them correctly.
• Private AS leakage -- If confederation border routers are misconfigured, they may fail to strip CONFED_SEQUENCE segments when advertising routes externally. This leaks private sub-AS numbers into the global routing table, which can confuse external networks and cause route filtering. Always verify that external advertisements contain only the confederation identifier in the AS path.
• IGP segmentation -- Each sub-AS typically runs its own IGP domain (OSPF area, IS-IS level). The boundaries between IGP domains and sub-AS boundaries should be aligned. Misalignment -- where an IGP domain spans sub-AS boundaries or a sub-AS spans IGP domains -- creates next-hop resolution problems and complicates troubleshooting.

Confederations in the Global Routing Table

From the perspective of the global BGP routing table (the Default-Free Zone), confederations are invisible. You cannot determine whether a network uses confederations by looking at its routes externally -- the AS path shows only the confederation's public AS number, just as it would for a non-confederation network. The CONFED_SEQUENCE and CONFED_SET segments are stripped before routes leave the confederation.

This transparency is by design: confederations are an internal scaling mechanism that should not affect external routing decisions. The confederation identifier appears in the DFZ as a regular AS number, and external peers form standard eBGP sessions with the confederation's border routers without any special configuration or awareness.

However, if you have access to a route collector that peers with a router inside a confederation (which some research networks do), you can observe the CONFED_SEQUENCE segments and gain insight into the network's internal sub-AS topology. This is one reason some operators consider confederation internal topology to be sensitive information.

Explore BGP Routing

Understanding confederations is part of understanding how large networks scale their internal routing. Use the god.ad BGP Looking Glass to explore real BGP routing data -- examine AS paths, investigate how major autonomous systems interconnect, and see the global routing table from multiple vantage points:

• AS3356 -- Lumen (Level 3): a major Tier 1 transit provider with a large, globally distributed network
• AS1299 -- Arelion (formerly Telia Carrier): another Tier 1 network with extensive global reach
• AS6939 -- Hurricane Electric: one of the most connected networks by peer count
• AS174 -- Cogent: a major Tier 1 transit provider
• 8.8.8.8 -- Trace the AS path to Google's DNS and see how routes traverse multiple autonomous systems