Route Reflection · Lesson 01 of 01
Scaling iBGP with route reflection
iBGP does not re-advertise iBGP-learned routes, which forces a full mesh. Route reflectors relax that rule under control.
Written lesson
The full-mesh problem
iBGP has no AS_PATH-style loop prevention within the AS, so the rule is blunt: a router never advertises an iBGP-learned route to another iBGP peer. That guarantees no loops but demands a full mesh — every iBGP speaker peered with every other, which is n(n-1)/2 sessions and does not scale. A route reflector is allowed to break the rule and reflect iBGP routes between its clients, collapsing the mesh into a hub and spoke.
Configuration
A reflector and its client
router bgp 65001
neighbor 10.0.0.2 remote-as 65001
neighbor 10.0.0.2 update-source Loopback0
address-family ipv4 unicast
neighbor 10.0.0.2 route-reflector-clientWritten lesson
Reflection rules and redundancy
A reflector's behaviour depends on where a route came from. A route from a client is reflected to all other clients and all non-clients. A route from a non-client is reflected to clients only. A route from an eBGP peer goes to everyone. For redundancy you deploy two reflectors per cluster; give them the same cluster-id so a route reflected by one is recognised and dropped by the other's cluster-list, preventing a reflection loop between the redundant pair.
Path hiding
A reflector advertises only its own best path to clients, so clients may never see a second, diverse path that exists elsewhere — 'path hiding'. Add-Path (advertise multiple paths) or careful RR placement restores the diversity that fast reconvergence and multipath need.