BGP Route Reflector

Internal BGP (iBGP) does not re-advertise routes learned from one iBGP peer to another by default, a rule that exists to prevent routing loops within an AS since AS_PATH prepending — the loop-prevention mechanism used in eBGP — is not applied between iBGP speakers. Historically this forced operators into a full mesh: every iBGP router had to peer directly with every other iBGP router, which scales as O(n²) sessions and becomes operationally untenable past a few dozen nodes. Route Reflectors (RR), defined in RFC 4456, break this constraint by designating certain routers as reflectors: a reflector accepts routes from its iBGP clients and is explicitly permitted to reflect them to other clients and non-client iBGP peers, collapsing the mesh into a hub-and-spoke or hierarchical topology.

Loop prevention without full-mesh peering relies on two non-transitive BGP attributes attached by the reflector. The ORIGINATOR_ID records the Router ID of the route’s originating iBGP speaker; if a reflector later receives a route back with its own originator ID, it discards it. The CLUSTER_LIST (paired with a configured CLUSTER_ID per RR or RR redundancy group) records the chain of clusters a route has traversed; a reflector drops any update whose CLUSTER_LIST already contains its own cluster ID. These attributes are stripped before propagation to eBGP peers, since they carry no meaning outside the AS.

The critical architectural trade-off is path visibility: standard BGP best-path selection means a router only advertises its single best path per prefix, so a reflector by default reflects only that one path to its clients — even if better or equally valid alternate paths exist elsewhere in the topology. This can produce non-deterministic or suboptimal routing during partial failures, because clients never see the paths a reflector considered inferior. Modern deployments mitigate this with BGP Add-Path (RFC 7911) or Diverse-Path reflection, at the cost of additional control-plane state and update volume. Redundancy is typically achieved by deploying two or more RRs per cluster with an identical CLUSTER_ID, which client routers peer with independently; misconfiguring distinct cluster IDs on a redundant pair defeats loop suppression and can reintroduce routing loops or duplicate advertisements. Hierarchical RR topologies (RRs peering with higher-tier RRs) are common in large carrier and hyperscale networks, and RRs are foundational to modern EVPN-VXLAN spine-leaf fabrics, where spine switches act as route reflectors so leaf switches avoid a full iBGP mesh across the fabric.

Route reflectors are a pure control-plane construct — they do not sit in the data-forwarding path for the prefixes they reflect unless independently selected as a next-hop, which is often misunderstood by engineers new to large-scale BGP designs. Their correct deployment is what allows iBGP to scale from dozens to thousands of routers within a single autonomous system without a combinatorial explosion of TCP sessions, but that scalability is purchased with reduced path diversity and a dependency on careful cluster-ID and redundancy planning; getting either wrong trades a scaling problem for a subtle, hard-to-diagnose routing-loop or black-hole problem.