Scaling BGP – Part 3: BGP Confederations in Practice

July 2015   |   Reading Time: 13 minutes

Introduction

BGP Confederations provide a viable solution to scaling BGP within large Autonomous Systems (ASes). In this final post of our deep dive series, we turn to the practical considerations, deployment methodologies, and real-world use cases of BGP Confederations, extending the theory into operational reality.

Recap of BGP Scaling Challenges

As outlined in previous entries, large-scale BGP deployments face issues like excessive iBGP mesh complexity, route processing load, and control plane overhead. Confederations, like Route Reflectors (RRs), attempt to solve these by breaking up the iBGP domain while maintaining exterior BGP behavior.

BGP Confederation Structure in Practice

A BGP Confederation divides a single AS into multiple sub-ASes. These sub-ASes maintain full iBGP within themselves but use eBGP between each other—although configured with a private ASN and treated as part of the parent AS externally.

• AS_CONFED_SET and AS_CONFED_SEQ: Used to preserve path history between sub-ASes.
• Local policies: Each sub-AS can apply routing policies for better control.
• Reduced session load: Fewer iBGP sessions needed overall.

Deployment Methodologies

There is no one-size-fits-all model, but some common patterns include:

1. Regional Sub-AS Design

Split the AS geographically—e.g., Sub-AS 65001 (Europe), 65002 (Asia), 65003 (Americas). This isolates regional changes and failures, helping both with scalability and stability.

2. Functional Sub-AS Design

Divide the AS by function or business unit—for instance, separating backbone, access, and services domains within a large enterprise or ISP.

Configuration Examples

A minimal example to illustrate Confederation setup in Cisco IOS:

    router bgp 65000
     bgp confederation identifier 65000
     bgp confederation peers 65001 65002
     neighbor 192.0.2.1 remote-as 65001
     neighbor 192.0.2.2 remote-as 65002
  

Each sub-AS (e.g., 65001, 65002) will be configured similarly with its own peerings and policies, referencing 65000 as the confederation identifier.

Operational Considerations

• Visibility: Confederations reduce path visibility, which may affect troubleshooting.
• Loop Prevention: Sub-ASes must be carefully designed to prevent routing loops.
• Transition Complexity: Moving from flat iBGP to a confederation model requires careful migration planning.
• Support: Ensure hardware/software platforms support confederation capabilities fully.

Comparison with Route Reflectors

Both Route Reflectors and Confederations solve the iBGP full-mesh problem, but:

• RRs are easier to deploy incrementally, but introduce non-determinism in route selection.
• Confederations offer better policy control but increase AS-level complexity.

Case Study: Large-Scale Provider Backbone

One Tier-1 provider implemented a confederation model with five regional sub-ASes. Each region had internal RRs and operated independently. Policies across sub-AS boundaries enforced service-specific routing paths and helped contain failures within regional scopes.

When to Use Confederations

Confederations are ideal when:

• You need granular policy control across distinct network domains.
• The iBGP session scale is too large for RRs alone.
• Organizational boundaries or M&A activity requires AS segmentation.

Conclusion

BGP Confederations, while more complex than traditional RRs, offer compelling benefits in large-scale AS architectures. When designed and implemented carefully, they enable efficient routing domain segmentation, better policy enforcement, and enhanced control plane scalability.

Eduardo Wnorowski is a network infrastructure consultant and technologist.
With over 20 years of experience in IT and consulting, he helps organizations design scalable network infrastructures using BGP and related protocols.
Linkedin Profile

Scaling BGP – Part 1: The Case for BGP Scalability in Large-Scale Networks

March 2015   •   Reading time: 12 minutes

Why BGP Needs to Scale

As enterprises and service providers expand their networks to meet the demands of global users, the Border Gateway Protocol (BGP) faces new challenges. In its original form, BGP wasn't designed for the massive scale it now supports. From sprawling data centers to regional ISPs, the protocol's default mechanisms often strain under the complexity of large-scale topologies.

Today’s post examines the limitations of traditional BGP in modern networks and sets the stage for why scalable mechanisms such as Confederations and Route Reflectors (RRs) have become essential.

Recap: What is BGP?

BGP is a path vector protocol that governs inter-domain routing across the internet. It’s used to exchange routing information between autonomous systems (ASes), providing a framework for routing policy, reachability, and route selection based on attributes such as AS_PATH, MED, LOCAL_PREF, and more.

Although BGP is considered a protocol of last resort due to its manual tuning, it's the backbone of global routing. Within an AS, Interior BGP (iBGP) allows routers to share information internally, which becomes critical as networks grow in size and complexity.

The Problem with Full Mesh iBGP

By default, iBGP requires a full mesh of peerings among all BGP-speaking routers in the same AS. This ensures all routers receive complete routing information, but the scalability limits become apparent quickly.

• Each router must peer with every other router.
• This results in n(n-1)/2 sessions, where n is the number of routers.
• Administrative overhead increases exponentially.
• Router CPU and memory consumption rises with each additional peer.

In practice, full mesh becomes unmanageable once you surpass even 10–20 routers. This is where hierarchical design becomes necessary.

Case Study: ISP with 75 Core Routers

Imagine an ISP operating with 75 routers across regional cores, border routers, and peering points. A full mesh of 75 iBGP routers would require 2,775 BGP sessions. Maintaining this at scale is not only inefficient—it’s nearly impossible.

Beyond the session count, consider the propagation delays, route processing queues, and convergence complexity. In such environments, full mesh is not viable.

Requirements for Scalable BGP

To scale BGP within an AS, network architects need mechanisms that:

• Reduce the number of required peerings
• Maintain loop-free and complete route visibility
• Support policy control and traffic engineering
• Ensure fast convergence and fault isolation

Two main solutions have emerged to solve these challenges:

• Route Reflectors (RRs): A mechanism to centralize iBGP route distribution.
• Confederations: A way to split a single AS into smaller sub-ASes for iBGP scalability.

Preview: What’s Next in the Series

This post lays the groundwork for the upcoming two parts in this deep dive series:

1. Part 2: Design and Implementation of Route Reflectors
2. Part 3: Leveraging BGP Confederations for Hierarchical Control

Each of these scaling techniques comes with its own design considerations, pitfalls, and operational trade-offs. Understanding when and how to use them is critical to maintaining a scalable and robust network.

 

💡 Pro Tip: Start documenting iBGP peerings and dependencies before implementing Route Reflectors. Visibility is the first step to control. 

 

Eduardo Wnorowski is a network infrastructure consultant and Director.
With over 20 years of experience in IT and consulting, he designs routing architectures that scale with performance and policy control.
Connect on Linkedin

Scaling BGP in Enterprise and SP Environments: Route Reflectors, Confederations, and Policy Control

July 2012 - Reading time: 8 min

As networks grow larger and more interconnected, especially in Service Provider (SP) and multi-site enterprise environments, the scalability of BGP (Border Gateway Protocol) becomes critical. In traditional iBGP (Internal BGP) configurations, every BGP speaker must maintain a full mesh of connections with every other iBGP peer to ensure routing information is exchanged properly. However, this model quickly becomes unsustainable as the number of routers increases.

The Full Mesh Limitation

Standard iBGP requires that all BGP routers in an autonomous system (AS) be fully meshed. This is necessary to prevent routing loops, as BGP does not advertise iBGP-learned routes to other iBGP peers by default. Unfortunately, the number of required sessions grows quadratically (n*(n–1)/2), making full mesh management a burden in large environments.

Route Reflectors

One common solution is the use of Route Reflectors (RRs). A Route Reflector acts as a central point that reflects routes learned from one iBGP peer to other iBGP peers. This eliminates the need for a full mesh, reducing the number of sessions while maintaining loop-free operation with the use of cluster IDs and originator IDs.

In practice, networks often deploy multiple RRs for redundancy, with clients peering only with their local RRs. Non-client routers still peer with each other in select topologies for additional resiliency. Loop prevention is achieved by tagging reflected routes with the originator ID and cluster list to prevent re-advertisement back to the source.

BGP Confederations

Another powerful scaling technique is the use of BGP Confederations. A confederation breaks an AS into multiple sub-ASes. These sub-ASes peer with each other as though they were external BGP sessions (eBGP), while internally they run iBGP. To the outside world, the confederation appears as a single AS.

Confederations allow more flexible policy control and more granular administrative boundaries, especially in multi-division enterprises or SP core networks. They also reduce iBGP overhead by reducing the scope of required full mesh inside each sub-AS.

Design Considerations

When choosing between Route Reflectors and Confederations, it’s important to consider:

• Network size and complexity: RRs are easier to deploy and manage in most enterprise networks. Confederations are better suited to very large or politically segmented networks.
• Policy enforcement: Confederations allow more policy granularity between sub-ASes. RRs have less natural policy segmentation unless you combine them with BGP communities or route maps.
• Interoperability: RRs are widely supported and straightforward. Confederations require tight control of AS path prepending and can confuse third-party visibility if not carefully configured.

Policy Control with Route Maps and Communities

Regardless of scaling mechanism, policy control remains crucial. Tools like route maps, prefix lists, and BGP communities are essential to enforce route filtering and path selection. Communities in particular are helpful in influencing decisions across RRs and can be used to tag routes with desired behaviors like “no-export”, “local-preference”, or custom policies.

In some environments, tagging with BGP communities is automated and integrated with provisioning systems, allowing for sophisticated, dynamic routing decisions that adapt to service-level agreements (SLAs), cost models, or even traffic engineering policies.

Real-World Deployment Tips

• Use redundant Route Reflectors and ensure they don’t reflect to each other to avoid routing loops.
• Monitor cluster list lengths to detect suboptimal route paths.
• When using Confederations, document sub-AS boundaries clearly and ensure correct AS path prepending.
• Implement extensive logging and validation during convergence testing to understand the behavior of policies and route propagation.
• Pair Route Reflectors with route filtering logic to avoid accidental advertisement of internal prefixes.

Conclusion

BGP is inherently scalable, but without careful design, large-scale deployments can become fragile. Route Reflectors and Confederations are both powerful tools to mitigate iBGP scaling issues, but they require attention to detail in design, policy control, and testing. When combined with smart policy enforcement and operational discipline, they enable the kind of flexible, scalable, and resilient routing that modern enterprise and SP environments demand.

Eduardo Wnorowski is a network infrastructure consultant and technologist.
With over 17 years of experience in IT and consulting, he brings deep expertise in networking, security, infrastructure, and transformation.
Connect on Linkedin