LAB 09 / 20

BGP Route Reflection — iBGP Scalability

MP-BGPRoute ReflectorClusterClient Peering

Active Nodes

09 BGP ROUTE REFLECTION Route Reflection — Active: CORE-1,CORE-2,EDGE-1,EDGE-2,EDGE-3,EDGE-4 See master topology for full 20-router diagram Active Nodes: CORE-1,CORE-2,EDGE-1,EDGE-2,EDGE-3,EDGE-4 Route Reflection CORE-1,CORE-2,EDGE-1,EDGE-2,EDGE-3,EDGE-4 Refer to lab.html for complete step-by-step configuration and verification commands for each active router Active Zone Inactive (dimmed) Ioannis (John) Alexander Konstas

Active routers: CORE-1, CORE-2, EDGE-1, EDGE-2, EDGE-3, EDGE-4, BORDER-1, BORDER-2

Key Concepts

Route Reflector Design

iBGP requires full mesh between all routers. With N peers, this means N(N-1)/2 sessions — 190 sessions for 20 routers. Route reflectors eliminate this by acting as relay points. The RR receives a route from an RR client and reflects it to all other clients AND non-clients. CORE-1 and CORE-2 are co-RRs in cluster 1, each maintaining the same set of client relationships. This provides RR redundancy without requiring client-to-client sessions.

Cluster-ID and Loop Prevention

The cluster-ID (set with bgp cluster-id) prevents routing loops when multiple RRs serve the same cluster. When an RR reflects a route, it adds its cluster-ID to the cluster-list attribute. If a route arrives containing the router own cluster-ID, it is discarded. ORIGINATOR_ID tracks the original advertising router — a router ignores updates with its own router-ID as ORIGINATOR_ID, preventing client-to-RR-to-client loops.

Non-Client Peering

Non-clients (routers in the iBGP domain that are not RR clients) require full mesh with each other AND with each RR. In this lab, BORDER-1 and BORDER-2 are non-clients — they have direct iBGP sessions to both CORE-1 and CORE-2 (RRs). If we had only clients and RRs, BORDER routers would need to be made clients too.

RR Configuration

CORE-1Route Reflector Cluster 1 — VPNv4 + IPv6
router bgp 65000
 bgp cluster-id 1
 no bgp default ipv4-unicast

 neighbor RR-CLIENTS peer-group
 neighbor RR-CLIENTS remote-as 65000
 neighbor RR-CLIENTS update-source Loopback0
 neighbor RR-CLIENTS route-reflector-client
 neighbor RR-CLIENTS password Fp6&kN3@sX

 neighbor 10.255.2.1 peer-group RR-CLIENTS
 neighbor 10.255.2.2 peer-group RR-CLIENTS
 neighbor 10.255.2.3 peer-group RR-CLIENTS
 neighbor 10.255.2.4 peer-group RR-CLIENTS
 neighbor 10.255.3.1 peer-group RR-CLIENTS
 neighbor 10.255.3.2 peer-group RR-CLIENTS

 neighbor 10.255.1.2 remote-as 65000
 neighbor 10.255.1.2 update-source Loopback0

 address-family vpnv4
  neighbor RR-CLIENTS activate
  neighbor RR-CLIENTS send-community extended
  neighbor RR-CLIENTS route-reflector-client
  neighbor 10.255.1.2 activate
  neighbor 10.255.1.2 send-community extended

Verification

show ip bgp summary
Expected: All configured neighbors in Established state. RR clients show in the table with "rcvd/sent" prefix counts.
show ip bgp vpnv4 all 10.255.6.1/32
Expected: CE-CORP-1 loopback visible at all PE routers via VPNv4. ORIGINATOR_ID matches PE-1 router-id. CLUSTER_LIST contains cluster-id 1.
show ip bgp neighbors 10.255.1.2 advertised-routes
Expected: Routes reflected from clients visible in RR-to-RR advertisement. Both co-RRs exchange all client routes.
show ip bgp vpnv4 all neighbors 10.255.2.1 routes
Expected: EDGE-1 (client) routes received at RR. Includes cluster-list and originator-id attributes.

Research and direction by Ioannis (John) Konstas; compiled and finalized with AI assistance.

Initial Configs — Load These First