Route Reflectors

Learning Objectives

Understand route reflector concepts and operation
Configure route reflectors and clients
Implement route reflector hierarchies
Troubleshoot route reflector loops
Design scalable route reflector architectures

Route Reflector Overview

Route reflectors solve the iBGP full mesh scaling problem by allowing a designated router to reflect routes between iBGP peers, breaking the split horizon rule under controlled conditions.

Full Mesh vs Route Reflector

Aspect	Full Mesh	Route Reflector
Sessions Required	n(n-1)/2	n-1 (star topology)
Scalability	Poor (quadratic growth)	Good (linear growth)
Configuration	Complex	Simple
Single Point of Failure	None	Route reflector
Loop Prevention	Split horizon	Cluster attributes

Route Reflector Components

A route reflector setup consists of route reflectors, clients, and non-clients with specific roles and relationships.

Route Reflector Terminology

Route Reflector (RR): Router that reflects routes between clients
Client: Router that receives reflected routes
Non-client: Router in full mesh with RR
Cluster: RR and its clients
Cluster ID: Unique identifier for each cluster
Originator ID: Router ID of route originator

Route Reflector Architecture

                    ┌─────────────┐
                    │   RR-1      │
                    │ (Primary)   │
                    └─────────────┘
                           │
            ┌──────────────┼──────────────┐
            │              │              │
      ┌─────────┐    ┌─────────┐    ┌─────────┐
      │Client-1 │    │Client-2 │    │Client-3 │
      └─────────┘    └─────────┘    └─────────┘
    
    Cluster ID: 1.1.1.1
    Clients: 10.1.1.2, 10.1.1.3, 10.1.1.4

Route Reflector Rules

Route reflectors follow specific rules for advertising routes to prevent loops and ensure proper operation.

Route Reflection Rules

Client to Non-client: Routes from clients are reflected to non-clients
Non-client to Client: Routes from non-clients are reflected to clients
Client to Client: Routes from clients are reflected to other clients
Non-client to Non-client: Routes are NOT reflected (normal iBGP rule)
eBGP routes: Always reflected to all iBGP peers

Basic Route Reflector Configuration

Configure a route reflector by designating client relationships on the RR router.

Route Reflector Configuration

# Route Reflector (RR-1) configuration
router bgp 65001
 bgp router-id 1.1.1.1
 bgp cluster-id 1.1.1.1
 bgp log-neighbor-changes
 
 # Client neighbors
 neighbor 10.1.1.2 remote-as 65001
 neighbor 10.1.1.2 description "Client-1"
 neighbor 10.1.1.2 route-reflector-client
 neighbor 10.1.1.2 update-source loopback 0
 
 neighbor 10.1.1.3 remote-as 65001
 neighbor 10.1.1.3 description "Client-2"
 neighbor 10.1.1.3 route-reflector-client
 neighbor 10.1.1.3 update-source loopback 0
 
 neighbor 10.1.1.4 remote-as 65001
 neighbor 10.1.1.4 description "Client-3"
 neighbor 10.1.1.4 route-reflector-client
 neighbor 10.1.1.4 update-source loopback 0
 
 # Non-client neighbor (optional)
 neighbor 10.1.1.5 remote-as 65001
 neighbor 10.1.1.5 description "Non-client"
 neighbor 10.1.1.5 update-source loopback 0

Client Configuration

# Client router configuration (no special config required)
router bgp 65001
 bgp router-id 10.1.1.2
 bgp log-neighbor-changes
 
 # Connection to route reflector
 neighbor 1.1.1.1 remote-as 65001
 neighbor 1.1.1.1 description "Route-Reflector"
 neighbor 1.1.1.1 update-source loopback 0
 
 # Local networks
 network 192.168.1.0 mask 255.255.255.0

Route Reflector Attributes

Route reflectors use special BGP attributes to prevent loops and maintain route information.

Route Reflector Attributes

Attribute	Type	Purpose	Usage
ORIGINATOR_ID	Optional Non-transitive	Loop prevention	Router ID of original advertiser
CLUSTER_LIST	Optional Non-transitive	Loop prevention	List of cluster IDs traversed
Cluster ID	Configuration	Cluster identification	Unique per cluster

Hierarchical Route Reflectors

Large networks may require multiple levels of route reflectors for scalability.

Hierarchical Route Reflector Design

                    ┌─────────────┐
                    │ Core RR-1   │
                    │ (Level 1)   │
                    └─────────────┘
                           │
            ┌──────────────┼──────────────┐
            │              │              │
      ┌─────────┐    ┌─────────┐    ┌─────────┐
      │Edge RR-1│    │Edge RR-2│    │Edge RR-3│
      │(Level 2)│    │(Level 2)│    │(Level 2)│
      └─────────┘    └─────────┘    └─────────┘
            │              │              │
        ┌───┴───┐      ┌───┴───┐      ┌───┴───┐
        │Client │      │Client │      │Client │
        │Group 1│      │Group 2│      │Group 3│
        └───────┘      └───────┘      └───────┘

Route Reflector Best Practices

Design Guidelines

Use unique cluster IDs for each route reflector
Deploy redundant route reflectors for high availability
Consider route reflector placement for optimal path selection
Monitor route reflector CPU and memory usage
Implement hierarchical design for large networks
Use consistent routing policies across route reflectors

Practice Exercise

Route Reflector Configuration Lab

Scenario: Configure a route reflector topology with one RR serving three clients in AS 65001.

Route Reflector Configuration:

BGP Confederations

Learning Objectives

Understand BGP confederation concepts
Configure confederation sub-ASes
Implement confederation boundaries
Compare confederations with route reflectors
Troubleshoot confederation issues

Confederation Overview

BGP confederations divide a large AS into smaller sub-ASes, reducing the iBGP full mesh requirement while maintaining external AS appearance.

Confederation Architecture

    External View: AS 65001
    ┌─────────────────────────────────────────────────────────┐
    │                                                         │
    │  Internal View: Sub-ASes                                │
    │  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐  │
    │  │  Sub-AS     │    │  Sub-AS     │    │  Sub-AS     │  │
    │  │   65101     │────│   65102     │────│   65103     │  │
    │  │             │    │             │    │             │  │
    │  └─────────────┘    └─────────────┘    └─────────────┘  │
    │                                                         │
    └─────────────────────────────────────────────────────────┘
    
    Confederation ID: 65001
    Member ASes: 65101, 65102, 65103

Confederation vs Route Reflector

Both solutions address iBGP scaling, but with different approaches and trade-offs.

Confederation vs Route Reflector Comparison

Aspect	Confederation	Route Reflector
Complexity	High (multiple ASes)	Low (single AS)
Scalability	Very High	High
Configuration	Complex	Simple
Path Selection	More granular	Standard BGP
Fault Tolerance	High	Medium
Standards	RFC 5065	RFC 4456

Confederation Configuration

Configure confederations by defining the confederation ID and member ASes.

Confederation Router Configuration

# Router in Sub-AS 65101
router bgp 65101
 bgp confederation identifier 65001
 bgp confederation peers 65102 65103
 bgp router-id 10.1.1.1
 bgp log-neighbor-changes
 
 # Internal confederation neighbors (eBGP-like)
 neighbor 10.2.2.2 remote-as 65102
 neighbor 10.2.2.2 description "Sub-AS-65102"
 
 # Internal sub-AS neighbors (iBGP)
 neighbor 10.1.1.2 remote-as 65101
 neighbor 10.1.1.2 description "Internal-65101"
 neighbor 10.1.1.2 update-source loopback 0
 neighbor 10.1.1.2 next-hop-self
 
 # External confederation neighbors (eBGP)
 neighbor 203.0.113.1 remote-as 65002
 neighbor 203.0.113.1 description "External-ISP"
 
 # Network advertisements
 network 192.168.1.0 mask 255.255.255.0

Confederation Peer Types

Confederations have three types of peer relationships with different behaviors.

Confederation Peer Types

Sub-AS iBGP

Same sub-AS number
iBGP rules apply
Admin distance: 200
Next-hop unchanged
Full mesh required

Confederation eBGP

Different sub-AS
eBGP-like behavior
Admin distance: 200
Next-hop unchanged
AS path not prepended

External eBGP

Outside confederation
Standard eBGP rules
Admin distance: 20
Next-hop modified
AS path prepended

Confederation Troubleshooting

Common Confederation Issues

Issue: Routes not propagating between sub-ASes

Symptoms: Missing routes in BGP table

Causes: Incorrect confederation peer configuration

Solution: Verify confederation peers command

Issue: External AS sees internal structure

Symptoms: Sub-AS numbers visible externally

Causes: Missing confederation identifier

Solution: Configure confederation identifier

Issue: Incorrect path selection

Symptoms: Suboptimal routing

Causes: Confederation path selection rules

Solution: Adjust local preference or use route maps

Route Filtering

Learning Objectives

Implement prefix-list filtering
Configure AS path filtering
Use standard and extended ACLs
Apply distribute-lists
Implement route filtering best practices

Route Filtering Overview

Route filtering in BGP controls which routes are advertised to or accepted from neighbors. Proper filtering is essential for security, performance, and routing policy implementation.

BGP Filtering Methods

Prefix-Lists

Most efficient method
Prefix and length matching
Supports ranges (le, ge)
Recommended for BGP

AS Path Filters

Regular expressions
AS path pattern matching
Origin AS filtering
Path length control

Prefix-List Filtering

Prefix-lists are the most efficient way to filter BGP routes based on network prefixes and subnet masks.

Basic Prefix-List Configuration

# Allow specific networks
ip prefix-list CUSTOMER-ROUTES seq 10 permit 192.168.1.0/24
ip prefix-list CUSTOMER-ROUTES seq 20 permit 192.168.2.0/24
ip prefix-list CUSTOMER-ROUTES seq 30 permit 10.0.0.0/8 le 16
ip prefix-list CUSTOMER-ROUTES seq 40 deny 0.0.0.0/0 le 32

# Apply to BGP neighbor
router bgp 65001
 neighbor 203.0.113.1 prefix-list CUSTOMER-ROUTES out
 neighbor 203.0.113.1 prefix-list ISP-ROUTES in

Prefix-List Operators

le (less than or equal): Maximum prefix length
ge (greater than or equal): Minimum prefix length
eq (equal): Exact prefix length (default)
seq: Sequence number for ordering

AS Path Filtering

AS path filters use regular expressions to match AS path patterns for advanced routing policies.

AS Path Filter Configuration

# Allow only directly connected ASes
ip as-path access-list 1 permit ^[0-9]+$

# Allow routes originating from specific AS
ip as-path access-list 2 permit _65002$
ip as-path access-list 2 permit _65003$

# Block routes from specific AS
ip as-path access-list 3 deny _65999_
ip as-path access-list 3 permit .*

# Allow only routes with AS path length <= 3
ip as-path access-list 4 permit ^([0-9]+ ){0,2}[0-9]+$

# Block routes with private AS numbers
ip as-path access-list 5 deny _64[5-9][0-9][0-9]_
ip as-path access-list 5 deny _65[0-4][0-9][0-9]_
ip as-path access-list 5 deny _655[0-2][0-9]_
ip as-path access-list 5 deny _6553[0-5]_
ip as-path access-list 5 permit .*

# Apply to BGP neighbor
router bgp 65001
 neighbor 203.0.113.1 filter-list 1 in
 neighbor 203.0.113.1 filter-list 5 out

AS Path Regular Expression Symbols

^: Start of string
$: End of string
_: AS boundary (space, start, end, comma)
.*: Any character, any number of times
+: One or more occurrences
?: Zero or one occurrence
[0-9]: Any digit
(pattern): Grouping

Filtering Application Methods

BGP filters can be applied in different directions and contexts.

Filter Application Options

Inbound Filtering

Filters routes received from neighbor
Applied before best path selection
Reduces BGP table size
Example: neighbor x.x.x.x prefix-list LIST in

Outbound Filtering

Filters routes advertised to neighbor
Applied after best path selection
Controls route advertisements
Example: neighbor x.x.x.x prefix-list LIST out

Route Maps

Learning Objectives

Configure advanced route maps
Implement conditional route manipulation
Use route maps for traffic engineering
Apply route maps with communities
Troubleshoot route map policies

Route Maps Overview

Route maps provide powerful, flexible route manipulation capabilities in BGP. They can match on various criteria and set multiple attributes simultaneously.

Basic Route Map Structure

# Route map with multiple sequences
route-map TRAFFIC-ENGINEERING permit 10
 match ip address prefix-list CUSTOMER-ROUTES
 match community GOLD-CUSTOMERS
 set local-preference 300
 set community 65001:100 additive
 set as-path prepend 65001

route-map TRAFFIC-ENGINEERING permit 20
 match ip address prefix-list PEER-ROUTES
 set local-preference 200
 set community 65001:200

route-map TRAFFIC-ENGINEERING permit 30
 set local-preference 100

# Apply to neighbor
router bgp 65001
 neighbor 203.0.113.1 route-map TRAFFIC-ENGINEERING in

Advanced Route Map Examples

Complex Traffic Engineering

# Time-based routing
time-range BUSINESS-HOURS
 periodic daily 08:00 to 18:00

route-map TIME-BASED-ROUTING permit 10
 match ip address prefix-list CRITICAL-APPS
 match time-range BUSINESS-HOURS
 set local-preference 400
 set community 65001:911

route-map TIME-BASED-ROUTING permit 20
 match ip address prefix-list CRITICAL-APPS
 set local-preference 200

# Conditional prepending
route-map CONDITIONAL-PREPENDING permit 10
 match ip address prefix-list CUSTOMER-ROUTES
 match community BACKUP-LINK
 set as-path prepend 65001 65001 65001

route-map CONDITIONAL-PREPENDING permit 20
 match ip address prefix-list CUSTOMER-ROUTES
 set as-path prepend 65001

# MED-based load balancing
route-map LOAD-BALANCE permit 10
 match ip address prefix-list PRIMARY-ROUTES
 set metric 50

route-map LOAD-BALANCE permit 20
 match ip address prefix-list SECONDARY-ROUTES
 set metric 100

BGP Multihoming

Learning Objectives

Implement single-homed vs multihomed designs
Configure primary/backup ISP scenarios
Implement load balancing across ISPs
Design multihoming for redundancy
Optimize multihoming performance

Multihoming Strategies

Multihoming provides redundancy and improved performance by connecting to multiple ISPs or using multiple links to the same ISP.

Primary/Backup ISP Configuration

# Primary ISP configuration
router bgp 65001
 neighbor 203.0.113.1 remote-as 65002
 neighbor 203.0.113.1 description "Primary-ISP"
 neighbor 203.0.113.1 route-map PRIMARY-IN in
 neighbor 203.0.113.1 route-map PRIMARY-OUT out

# Backup ISP configuration  
 neighbor 198.51.100.1 remote-as 65003
 neighbor 198.51.100.1 description "Backup-ISP"
 neighbor 198.51.100.1 route-map BACKUP-IN in
 neighbor 198.51.100.1 route-map BACKUP-OUT out

# Route maps for traffic engineering
route-map PRIMARY-IN permit 10
 set local-preference 200
 set weight 100

route-map BACKUP-IN permit 10
 set local-preference 100
 set weight 50

route-map PRIMARY-OUT permit 10
 match ip address prefix-list OUR-ROUTES
 set as-path prepend 65001

route-map BACKUP-OUT permit 10
 match ip address prefix-list OUR-ROUTES
 set as-path prepend 65001 65001 65001

BGP Load Balancing

Learning Objectives

Configure BGP equal-cost multipath
Implement unequal-cost load balancing
Design load balancing with link bandwidth
Optimize load balancing performance
Troubleshoot load balancing issues

BGP Load Balancing Configuration

BGP can load balance traffic across multiple equal-cost paths when properly configured.

Equal-Cost Multipath Configuration

# Enable BGP multipath
router bgp 65001
 maximum-paths 4
 maximum-paths ibgp 4
 
 # Configure multiple neighbors with same attributes
 neighbor 203.0.113.1 remote-as 65002
 neighbor 203.0.113.1 route-map EQUAL-COST in
 
 neighbor 203.0.113.5 remote-as 65002  
 neighbor 203.0.113.5 route-map EQUAL-COST in

# Route map to ensure equal attributes
route-map EQUAL-COST permit 10
 set local-preference 100
 set weight 0
 set metric 0

# Unequal cost multipath (Cisco proprietary)
router bgp 65001
 bgp bestpath multipath-relax
 maximum-paths 4

Previous: BGP Configuration Next: BGP Troubleshooting