Building a Scalable BGP Design with Route Reflectors and Confederations

Author Ermias Teffera

itvue fast data Center

Overview

In today’s growing multi-AS enterprise environments, designing a scalable and manageable BGP topology is crucial. This post walks through a BGP topology using Route Reflectors (RRs) and Confederations as seen in the sample network diagram above, focusing on devices R5 and R6 as RRs, and highlighting the segmentation via Confederations (AS 64513 and 64514). This architecture is implemented by ITVue Networks.

AS Topology Summary

• Core AS: 500 (ITVue Networks Core)

• Confederate Sub-ASes:

  • AS 64513 (Left sub-AS: R1, R3, R5)

  • AS 64514 (Right sub-AS: R2, R4, R6)

    
    

• External Connections:

  • ISP-1: R1 to R7 via 216.185.3.2/30 (AS 200)

  • ISP-2: R2 to R8 via 198.1.51.2/30 (AS 100)

  • Customer: R9 to CUST-1 (AS 64512) via 150.0.0.0/24

    
    

Route Reflector (RR) Design

In a full mesh iBGP setup, each iBGP peer must connect to every other peer within the AS. This becomes unwieldy as the number of routers grows. To solve this, Route Reflectors are used.

R5 and R6 as Route Reflectors:

• R5 and R6 are configured as RRs with Cluster ID: 1.

• Clients of R5: R1, R3

• Clients of R6: R2, R4

• RR-to-RR Peering: Established over 10.1.0.48/30 between R5 (.49) and R6 (.50)

  
  

This minimizes the iBGP mesh to:

• Client-to-RR sessions only

• RR-to-RR session between R5 and R6

iBGP Sessions:

• R1 to R5 over 10.1.0.38

• R3 to R5 over 10.1.0.45

• R2 to R6 over 10.1.0.29

• R4 to R6 over 10.1.0.26

  
  

Sample BGP Configurations

R5 (Route Reflector for AS 64513)

router bgp 64513

bgp router-id 5.5.5.5

bgp cluster-id 1

bgp log-neighbor-changes

neighbor 10.1.0.38 remote-as 64513

neighbor 10.1.0.38 route-reflector-client

neighbor 10.1.0.45 remote-as 64513

neighbor 10.1.0.45 route-reflector-client

neighbor 10.1.0.49 remote-as 64514

R6 (Route Reflector for AS 64514)

router bgp 64514

bgp router-id 6.6.6.6

bgp cluster-id 1

bgp log-neighbor-changes

neighbor 10.1.0.29 remote-as 64514

neighbor 10.1.0.29 route-reflector-client

neighbor 10.1.0.26 remote-as 64514

neighbor 10.1.0.26 route-reflector-client

neighbor 10.1.0.50 remote-as 64513

R1 (Client in AS 64513)

router bgp 64513

bgp log-neighbor-changes

neighbor 10.1.0.41 remote-as 64513

R2 (Client in AS 64514)

router bgp 64514

bgp log-neighbor-changes

neighbor 10.1.0.30 remote-as 64514

R5 and R6 Confederation Global Settings

router bgp 500

bgp confederation identifier 500

bgp confederation peers 64513 64514

Confederation Setup

To further scale and isolate the network, the large AS 500 is broken into two smaller sub-ASes using BGP Confederation:

• R1, R3, R5: part of Confederation AS 64513

• R2, R4, R6: part of Confederation AS 64514

Each sub-AS runs full iBGP or RR-based iBGP internally, and uses eBGP-like rules between the sub-ASes (inter-confed).

Confederation Benefits:

• Reduces iBGP mesh within sub-AS

• Retains route scalability while appearing as a single AS (500) to external peers

• Allows policy control between sub-ASes

  
  

Key Confederation Links:

• R5 (.50) <--> R6 (.49) over 10.1.0.48/30 (confed eBGP between sub-ASes)

• R3 (.9) to R9 (.2) over 150.1.0.0/30 (confed eBGP to customer)

  
  

Peering with External Networks

• R1 peers with ISP-1 (R7) using 216.185.3.2

• R2 peers with ISP-2 (R8) using 198.1.51.2

• R9 (internal edge router) peers with CUST-1 AS 64512 over 150.0.0.0/24

All external sessions are true eBGP.

Summary

This BGP topology demonstrates:

• Efficient scaling with Route Reflectors (R5, R6)

• Controlled segmentation via Confederations (AS 64513 & 64514)

• Clean external peering using eBGP

The architecture ensures scalability, reduced complexity, and efficient policy control for large networks. Ideal for enterprise, cloud, or ISP-grade BGP designs — and proudly implemented by ITVue Networks.