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

Redistribution Pitfalls: Avoiding Routing Loops and Black Holes

July 2015 - Reading Time: ~9 minutes

Route redistribution can be a powerful technique for connecting different routing domains, protocols, or administrative boundaries. However, when improperly configured, it can introduce severe problems such as routing loops, suboptimal paths, and even black holes that silently drop traffic. This post explores how redistribution works, the risks involved, and techniques to ensure safe, efficient route redistribution in your enterprise network.

What Is Route Redistribution?

Route redistribution allows routes learned by one routing protocol to be advertised into another. This is useful when transitioning from one protocol to another (e.g., EIGRP to OSPF), or when integrating networks acquired during a merger.

Consider a network that uses EIGRP internally but must share connectivity with a provider running OSPF. Redistribution makes this possible—but not without introducing risk. Each protocol calculates metrics differently, lacks awareness of the other's internal topologies, and may create asymmetric paths.

Common Redistribution Scenarios

• Mutual Redistribution: Injecting routes in both directions (e.g., OSPF ↔ EIGRP)
• Partial Redistribution: One-way sharing of routes (e.g., static → OSPF)
• Multiple AS Integration: Combining domains with different protocols during M&A or inter-domain peering

Mutual redistribution, while common, is particularly susceptible to routing loops.

Pitfall 1: Routing Loops

Loops often result when redistributed routes are re-learned and re-advertised in a circular fashion across protocol boundaries. Consider this scenario:

• Route A exists in EIGRP
• It is redistributed into OSPF
• OSPF advertises Route A back into EIGRP (now as external)
• EIGRP prefers the new external route over the internal, due to metric manipulation or administrative distance

This loop creates instability and traffic misdirection. Without proper filtering and tagging, the router cannot differentiate between the original and redistributed versions of the same route.

Solution: Route Tagging

To prevent loops, apply route tags during redistribution. Tags act as metadata that inform the receiving protocol about the route’s origin.

    router ospf 10
     redistribute eigrp 100 subnets tag 100

    router eigrp 100
     redistribute ospf 10 metric 10000 100 255 1 1500 route-map BLOCK_OSPF_TAG

    route-map BLOCK_OSPF_TAG deny 10
     match tag 100

    route-map BLOCK_OSPF_TAG permit 20
  

In this example, OSPF routes tagged with 100 will be filtered out by EIGRP, preventing re-injection of external routes.

Pitfall 2: Metric Mismatches

Protocols use different metrics: OSPF uses cost, EIGRP uses bandwidth and delay. Without careful planning, redistributed routes may have absurd metrics, causing poor path selection or path flapping.

Solution: Define Metrics Explicitly

Always define metrics during redistribution. Relying on defaults may result in inconsistent behavior or loops. Consider using route-maps to apply metrics and selectively filter undesirable routes.

    router ospf 1
     redistribute eigrp 1 subnets metric-type 1 metric 10
  

Pitfall 3: Subnet Inconsistencies

Redistribution without including subnet information can collapse multiple prefixes into a single advertisement, causing reachability issues or loss of granularity.

Use the subnets keyword to ensure all routes are properly advertised:

    redistribute eigrp 100 subnets
  

Design Best Practices

• Use route tagging religiously
• Implement route-maps to control what is redistributed
• Monitor redistributed routes with logging and route tracking
• Avoid mutual redistribution unless absolutely necessary
• Use summarization to reduce route churn

Lab Simulation: OSPF-EIGRP Redistribution

Set up a small lab with two routers: R1 running EIGRP and R2 running OSPF. Connect them via a common interface and configure mutual redistribution. Tag routes from EIGRP with tag 100, then apply a route-map on R2 to block those tagged routes from being redistributed back.

This exercise reinforces tagging and filtering while visualizing how loops may emerge without protection.

Conclusion

Redistribution is not a set-and-forget tool—it demands careful planning, deep understanding of routing behavior, and continuous monitoring. Use route-maps, tagging, metric definition, and thorough testing to protect your network from inadvertent instability. A clean, loop-free redistribution design can make multi-protocol integration seamless and secure.

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