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

Mastering OSPF Stub Areas: When and Why to Use Them

March 2015   |   Reading Time: 10 min read

Introduction

Open Shortest Path First (OSPF) is a link-state routing protocol widely used in enterprise and service provider networks. As OSPF networks scale, it becomes critical to manage the size of routing tables and the number of LSAs (Link-State Advertisements) flooded throughout the topology. OSPF stub areas are one method to reduce this overhead without sacrificing network reachability.

What Are OSPF Stub Areas?

Stub areas are special types of OSPF areas where external routes (Type 5 LSAs) are restricted. Instead of learning each external route individually, routers in stub areas receive a default route (0.0.0.0/0) pointing toward the ABR (Area Border Router).

Types of Stub Areas

• Stub Area – Blocks Type 5 LSAs, injects a default route.
• Totally Stubby Area – Blocks Type 3 and Type 5 LSAs, only default route is allowed.
• Not-So-Stubby Area (NSSA) – Allows Type 7 LSAs from redistribution inside the area and converts them to Type 5 at the ABR.
• Totally NSSA – Like NSSA, but blocks inter-area routes (Type 3 LSAs).

When to Use Stub Areas

Stub areas are ideal for edge segments or branches that need connectivity but don't require visibility into external destinations. Using stub areas can reduce router CPU, memory usage, and LSA flooding, which improves convergence time.

Design Considerations

• All routers in the area must agree on stub configuration.
• You cannot have an ASBR inside a stub area (except for NSSA).
• Mixing stub and non-stub routers causes adjacency failure.
• Stub areas work best for leaf segments with a single path to the core.

Sample Configuration

    ! Configure Area 1 as a stub on the ABR
    router ospf 1
     area 1 stub
    !
    ! Configure on internal routers
    router ospf 1
     area 1 stub
    !
    ! To make Area 1 a totally stubby area
    router ospf 1
     area 1 stub no-summary

NSSA Configuration Example

    router ospf 1
     area 2 nssa
    !
    ! NSSA with no-summary (Totally NSSA)
    router ospf 1
     area 2 nssa no-summary
    !
    ! Redistributing into NSSA
    router ospf 1
     redistribute static subnets
     area 2 nssa

Benefits of Stub Areas

• Reduced routing table size
• Lower LSA flooding and faster convergence
• Minimized complexity for edge routers
• More predictable routing behavior

Limitations and Pitfalls

• Cannot have multiple exit points without breaking stub logic
• Default routes may mask suboptimal paths
• Cannot host an ASBR (except in NSSA)
• Must manually configure all routers consistently

Verification and Troubleshooting

• Use show ip ospf and show ip ospf database to inspect LSA types
• Check for neighbor issues using show ip ospf neighbor
• Confirm stub configuration with show ip protocols
• Debug with debug ip ospf adj for adjacency problems

Conclusion

Stub areas are a simple yet powerful way to optimize OSPF networks. By strategically applying stub area configurations, network engineers can ensure scalability, improve stability, and maintain control over routing behavior. Understanding the differences between stub types and applying them correctly is key to successful OSPF design.

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