Lab Objective
Configure one router as a BGP route reflector with two client peers, verify the reflector re-advertises a route learned from one client to the other despite no direct session existing between the two clients, and confirm this solves exactly the propagation failure observed in the previous lab.
Lab Purpose
The previous lab demonstrated that iBGP's split-horizon-like rule requires a full mesh of sessions to guarantee route propagation, which becomes impractical as the number of routers in an AS grows. A route reflector is specifically exempted from that rule for its designated clients, allowing a hub-and-spoke iBGP design instead of a full mesh.
Lab Topology
R2 (route reflector) ---- R1 (client)
R2 (route reflector) ---- R3 (client)
R1 ---- R3 direct session intentionally
NOT configured, mirroring the
incomplete mesh from the previous lab
All routers in AS 65010
R1's LAN: 192.168.220.0/24Task 1: Configure R2 as a Route Reflector
On R2, configure both R1 and R3 as route reflector clients within the same iBGP sessions already established.
Task 2: Advertise R1's Network
Advertise R1's LAN into BGP, exactly as in the previous lab.
Task 3: Verify R2 Receives the Route
Confirm R2 learns the route from R1 as before.
Task 4: Verify R3 Now Learns the Route Without a Direct R1 Session
Confirm R3 receives the route this time, despite still having no direct session with R1.
Task 5: Verify the Reflected Route's Attributes
Examine the route on R3 for the originator ID and cluster list attributes that mark it as reflector-relayed.
Solution and Verification
R2(config)# router bgp 65010
R2(config-router)# neighbor 10.1.1.1 route-reflector-client
R2(config-router)# neighbor 10.2.2.2 route-reflector-client
-- Both existing sessions from the previous
-- lab are simply flagged as clients --
-- no new sessions or removed sessions,
-- just a behavioral change in how R2
-- treats routes received from these peersR1(config)# router bgp 65010
R1(config-router)# network 192.168.220.0 mask 255.255.255.0R2# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 192.168.220.0/24 10.1.1.1 0 100 0 i
-- R2 learns the route from R1, unchanged
-- from beforeR3# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 192.168.220.0/24 10.1.1.1 0 100 0 i
-- Unlike the previous lab, R3 now
-- successfully learns the route, despite
-- having no direct session with R1 --
-- R2's route reflector role permitted it
-- to forward this iBGP-learned route on
-- to its other client, R3R3# show ip bgp 192.168.220.0 255.255.255.0
BGP routing table entry for 192.168.220.0/24
Refresh Epoch 1
Local
10.1.1.1 (metric 0) from 10.2.2.1 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 1.1.1.1, Cluster list: 2.2.2.2
-- Originator confirms the route genuinely
-- came from R1 (1.1.1.1) originally, and
-- Cluster list shows R2 (2.2.2.2) is the
-- reflector that relayed it -- these
-- attributes exist specifically to prevent
-- reflected routing loops in more complex
-- multi-reflector topologiesKey Takeaway
A route reflector's clients do not need sessions with each other at all — only with the reflector itself — collapsing what would otherwise be an N-squared full-mesh requirement into a simple hub-and-spoke design; the originator ID and cluster list attributes exist precisely because this relaxation of the split-horizon rule reintroduces loop potential in larger deployments with multiple reflectors, and these attributes are what BGP uses to detect and prevent that.