🚀 Scaling BGP with Route Reflectors: Building the Backbone, Phase 2

➡️ Missed the first part? Start with Phase 1: EBGP Interop Lab

Continuing our BGP lab series, we’re scaling up the architecture by introducing a Route Reflector (RR). In a traditional iBGP full-mesh, each router must establish a peer with every other router — which becomes inefficient and difficult to scale as the network grows. Route Reflectors solve this problem by allowing routers (clients) to peer only with the Route Reflector, which then reflects routes between clients.

Instead of starting from scratch, we’re reusing the existing devices from the last lab and adding one more router to demonstrate route reflection in a Service Provider-like setup.

This step is all about scaling smart — using the same core router (now as a Route Reflector) and introducing a second Cisco IOS router to act as another client in the iBGP domain.

In this lab, we’ll:

• Deploy a Juniper vMX as a BGP Route Reflector
• Connect two Cisco IOS routers as RR clients
• Share loopbacks across the topology using iBGP
• Validate full route reflection without a full mesh

🧠 Lab Objective

• Convert the existing Juniper vMX router into a Route Reflector
• Keep Cisco IOS R1 from the previous lab as an iBGP client
• Add a new Cisco IOS R3 as an additional iBGP client
• Maintain loopback-to-loopback peering and advertise reachability
• Validate iBGP functionality through the Route Reflector without a full mesh

🌐 Topology

R1 (Cisco IOS)        RR (Juniper vMX)        R3 (Cisco IOS)
 1.1.1.1/32             2.2.2.2/32              3.3.3.3/32
     Lo0                     Lo0                    Lo0
     |                        |                      |
   Gi0/0 ------------- ge-0/0/0  ge-0/0/1 -------- Gi0/0
        10.1.12.0/30                    10.1.23.0/30

🔢 Addressing & ASNs

📄 Configuration

Cisco IOS – R1

hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 10.1.12.1 255.255.255.252
!
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
 network 10.1.12.0 0.0.0.3 area 0
!
router bgp 65001
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 65001
 neighbor 2.2.2.2 update-source Loopback0
!

Cisco IOS – R3

hostname R3
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
interface GigabitEthernet0/0
 ip address 10.1.23.2 255.255.255.252
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
 network 10.1.23.0 0.0.0.3 area 0
router bgp 65001
 bgp log-neighbor-changes
 network 3.3.3.3 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 65001
 neighbor 2.2.2.2 update-source Loopback0

Juniper vMX – Route Reflector

set system host-name RR
set interfaces ge-0/0/0 unit 0 family inet address 10.1.12.2/30
set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/30
set interfaces lo0 unit 0 family inet address 2.2.2.2/32

set routing-options router-id 2.2.2.2
set routing-options autonomous-system 65001

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

set protocols bgp group RR-CLIENTS type internal
set protocols bgp group RR-CLIENTS cluster 2.2.2.2
set protocols bgp group RR-CLIENTS local-address 2.2.2.2
set protocols bgp group RR-CLIENTS neighbor 1.1.1.1
set protocols bgp group RR-CLIENTS neighbor 3.3.3.3

set policy-options policy-statement export-lo0 term 1 from route-filter 2.2.2.2/32 exact
set policy-options policy-statement export-lo0 term 1 then accept
set policy-options policy-statement export-lo0 then reject
set protocols bgp group RR-CLIENTS export export-lo0

💡 Note: The local-address command explicitly tells the RR to use its loopback (2.2.2.2) as the BGP source. While Junos may choose this automatically, setting it manually avoids ambiguity and ensures consistency — especially in larger or more dynamic networks.

🔍 Verification

✅ Step 1: Confirm OSPF Adjacency

On R1 and R3:

show ip ospf neighbor

On Juniper RR:

show ospf neighbor

You should see full OSPF adjacency between:

• R1 and RR
• R3 and RR

✅ Step 2: Validate Loopback Reachability

From R1:

ping 2.2.2.2 source 1.1.1.1
ping 3.3.3.3 source 1.1.1.1

From R3:

ping 2.2.2.2 source 3.3.3.3
ping 1.1.1.1 source 3.3.3.3

From RR (Juniper):

ping 1.1.1.1 source 2.2.2.2
ping 3.3.3.3 source 2.2.2.2

✅ Step 3: Confirm BGP Sessions and Reflected Routes

On R1 and R3:

show ip bgp summary
show ip route bgp

So, show ip route bgp is appearing empty, I believe because R1 is learning both loopbacks via OSPF, not BGP, But BGP is still functioning 100% correctly behind the scenes.

🧠 Why This Happens

Cisco routers install only the best route into the routing table. Since OSPF has an administrative distance of 110, and BGP has 200, the OSPF route wins.

But you can still use BGP for policy, route reflection, VPNs, etc., and it’s working as intended.

On Juniper RR:

show bgp summary
show route receive-protocol bgp 1.1.1.1
show route receive-protocol bgp 3.3.3.3

You should see:

• iBGP sessions in the Established state
• Loopback routes of other iBGP clients present in the BGP table
• RR successfully reflecting routes between clients

Result

You now have a functioning iBGP setup with Route Reflection, allowing iBGP clients to exchange routes without forming a full mesh.

🧠 — Bryan

🚀 Next up: Phase 3 – Delivering Services with MPLS L3VPN