BGP Route Reflectors: When and Why to Use Them

The problem: iBGP full mesh

BGP's loop-prevention rule for iBGP is blunt: a route learned from one iBGP peer must not be advertised to another iBGP peer. There's no AS_PATH to detect loops inside your own AS, so BGP simply refuses to relay iBGP-learned routes.

The consequence is that every iBGP speaker must peer directly with every other iBGP speaker — a full mesh. The session count grows as n(n-1)/2. Ten routers need 45 sessions. Fifty routers need 1,225. Every new router means touching the config of every existing router — which is exactly the kind of change process that breeds outages.

What a route reflector actually does

A route reflector (RFC 4456) is an iBGP speaker allowed to break the relay rule in a controlled way. You nominate a router as the RR and configure its peers as clients. The reflection rules are:

• Route from a client → reflect to all clients and all non-clients
• Route from a non-client (regular iBGP peer) → reflect to clients only
• Route from an eBGP peer → advertise to everyone, as normal

Clients now need exactly one iBGP session (or two, for redundancy) instead of one per router. The full mesh collapses into a hub-and-spoke of control-plane sessions.

Loop prevention moves into two new BGP attributes: ORIGINATOR_ID (the router-id of the router that injected the route — a router drops routes carrying its own) and CLUSTER_LIST (each RR prepends its cluster-id; an RR drops routes already carrying its cluster-id).

When you actually need one

Rules of thumb from production:

• Under ~5 iBGP speakers: full mesh is fine. Don't add moving parts to a network that doesn't need them.
• Growing beyond that, or adding routers frequently: route reflectors. The win isn't just session count — it's that adding a router no longer touches every other router.
• VXLAN EVPN fabrics: RRs are essentially mandatory. Spines reflect EVPN routes to leaves; nobody full-meshes a fabric. Every leaf peers with two spine RRs and that's the entire overlay control plane.
• Confederations are the other RFC answer to the same problem — but in practice they're rare outside very large or historically merged service-provider networks. For an enterprise, RRs win on simplicity almost every time.

Design rules that keep you out of trouble

Always deploy in pairs

An RR is control-plane concentration: lose your only RR and clients keep forwarding on stale routes but converge on nothing new. Two RRs, every client peering with both. For most designs, give the pair different cluster-ids (the default — each uses its router-id) so each client genuinely receives and holds routes from both.

Keep the RR out of the data path — or don't, but decide

Nothing requires an RR to forward traffic. In DC fabrics the spine RRs are in the path anyway; in WAN designs a dedicated pair of control-plane-only RRs (even VMs) is a clean pattern. What matters is that you make the choice deliberately — an in-path RR that reflects a best path it wouldn't itself use for forwarding can blackhole traffic if next-hops aren't resolvable everywhere.

Beware path hiding

This is the trap. An RR reflects only its own best path. If two exits exist for a prefix, clients learn just the one the RR prefers — losing potential ECMP and slowing convergence (clients must wait for the RR to recompute after a failure, rather than failing over to a path they already hold).

Don't touch next-hop-self on reflected routes

RRs must not change the next hop when reflecting (client-to-client reflection with next-hop-self breaks the model and can loop traffic through the RR). Set next-hop-self on the border routers where eBGP routes enter the AS, and make sure your IGP can resolve those next hops everywhere.

Minimal working example

router bgp 65001
   router-id 10.0.0.1
   neighbor LEAVES peer group
   neighbor LEAVES remote-as 65001
   neighbor LEAVES update-source Loopback0
   neighbor LEAVES route-reflector-client
   neighbor LEAVES send-community extended
   neighbor 10.0.0.11 peer group LEAVES
   neighbor 10.0.0.12 peer group LEAVES
   !
   address-family evpn
      neighbor LEAVES activate

router bgp 65001
 bgp cluster-id 10.0.0.1
 neighbor 10.0.0.11 remote-as 65001
 neighbor 10.0.0.11 update-source Loopback0
 neighbor 10.0.0.11 route-reflector-client
 neighbor 10.0.0.12 remote-as 65001
 neighbor 10.0.0.12 update-source Loopback0
 neighbor 10.0.0.12 route-reflector-client

Clients need nothing special — they're ordinary iBGP speakers that happen to have only one or two peers. That asymmetry is half the operational appeal.

Summary

• Full mesh scales as n²; route reflectors make iBGP scale linearly
• Deploy RRs in pairs, clients peer with both, distinct cluster-ids by default
• RRs reflect only their best path — use ADD-PATH if you need clients to see alternatives
• Keep next-hop rewriting at the AS edge, not on the reflector
• Small network? Skip all of this and keep the mesh — simplicity is a feature