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