BGP Route Reflectors: Scaling iBGP Beyond Full-Mesh

The one-sentence mental model

iBGP is broken by default at scale. Every internal router must talk to every other → N routers = N(N−1)/2 iBGP sessions. At 100 routers that’s 4,950 sessions. Route Reflectors solve it: designate one (or a few) as reflectors, everyone peers only with the reflectors, RRs relay routes between clients.

The rule that causes the pain

Split-horizon rule for iBGP: a router that learns a route via iBGP will NOT re-advertise it to other iBGP peers.

This prevents iBGP loops (there’s no AS-path prepending inside an AS to detect loops via path). But it forces every iBGP router to hear every route directly from every other, which means a full mesh.

Route Reflectors: the exception

A Route Reflector (RR) is an iBGP router configured to violate the split-horizon rule in a controlled way. When it learns a route from an iBGP peer that is marked as a client, it re-advertises that route to other clients and non-client iBGP peers.

Roles:

• RR (Route Reflector): does the re-advertisement
• Client: an iBGP router that peers only with the RR (not with every other iBGP router)
• Non-client: a normal iBGP router that isn’t a client of this RR (typically another RR or an iBGP router in a different cluster)

RR advertisement rules:

• Route from eBGP → advertise to clients + non-clients (normal iBGP behavior)
• Route from a client → advertise to all other clients + non-clients (this is the special reflection)
• Route from a non-client → advertise to clients only (not to other non-clients, prevents loops)

Config

router bgp 65001
  neighbor 10.0.0.10 remote-as 65001
  neighbor 10.0.0.10 route-reflector-client
  neighbor 10.0.0.11 remote-as 65001
  neighbor 10.0.0.11 route-reflector-client
  neighbor 10.0.0.12 remote-as 65001                ! non-client (another RR)

Adding route-reflector-client under a neighbor makes that neighbor a client of this RR. Clients don’t need any special config. They just peer with the RR as normal iBGP.

Cluster-ID for redundant RRs

For redundancy you deploy two RRs in the same location. They can share one cluster-id (one logical cluster: less memory, fewer duplicate paths) or keep unique cluster-ids (more path diversity). Both designs are loop-free.

router bgp 65001
  bgp cluster-id 1.1.1.1

By default, cluster-id = RR’s router-id. Set it explicitly if you want both redundant RRs in the same cluster.

Loop prevention attributes

Without full-mesh’s AS-path loop check, RR needs its own loop prevention:

• ORIGINATOR_ID: the router-id of the router that first advertised the route into iBGP. If a route comes back to the originating router, it drops it.
• CLUSTER_LIST: list of cluster-ids the route has traversed. An RR checks its own cluster-id against the list; if present, drops the route (already traversed my cluster, would loop).

Both attributes are added by RRs on reflection. Non-RR routers don’t touch them.

Hierarchical RR design

Big networks build hierarchies of RRs:

• Top-tier RRs peer with each other in a full mesh (small set).
• Regional RRs are clients of top-tier RRs, and have local clients under them.
• Edge routers peer only with their regional RR.

Cluster-ids are per-tier or per-region. Loop prevention still holds because CLUSTER_LIST accumulates as you go up the hierarchy.

Alternatives to RRs

• BGP Confederations: split the AS into sub-ASes, each running its own full-mesh iBGP, with eBGP-like peerings between sub-ASes. Less common, more complex.
• Full mesh: still valid for < ~30 routers.

Common exam / real-world mistakes

1. Not choosing a cluster-id design for the redundant pair. By default each RR uses its own router-id, so the pair forms two clusters. That is loop-free (CLUSTER_LIST and ORIGINATOR_ID still apply) but clients receive and store duplicate paths. Pick shared or unique cluster-ids on purpose.
2. Mixing up RR roles by accident. In a flat design, redundant RRs peer with each other as non-clients (regular iBGP). In a hierarchy, lower-tier RRs are intentionally clients of the top tier. Document which design you run.
3. Adding a new iBGP router but forgetting to make it a client of the RR. New router won’t get any iBGP routes; nothing looks broken until traffic patterns shift.
4. Missing next-hop-self on eBGP-facing routers. eBGP next-hops don’t auto-recurse across the AS. Without next-hop-self, iBGP-received routes have unreachable next-hops.
5. Confusing route-reflection direction. Client → RR is a normal iBGP session. RR → client re-advertises reflected routes. The route-reflector-client command goes on the RR, not the client.

Verifying

show ip bgp neighbors 10.0.0.10                    ! look for "Route reflector client: Yes"
show ip bgp <prefix>                                ! look for Originator ID and Cluster list
show ip bgp summary                                 ! session count reduced vs full mesh

Cheat strip

Problem       iBGP split-horizon → full mesh N(N-1)/2 sessions
Solution      Route Reflector: re-advertises routes between clients

Roles         RR (does reflection) | Client | Non-client
Config        neighbor X route-reflector-client (on the RR)
Cluster       bgp cluster-id X.X.X.X (shared or unique per RR: design choice)

Loop prevent  ORIGINATOR_ID + CLUSTER_LIST attributes
              RR drops routes whose CLUSTER_LIST includes its cluster-id

Design        Simple: single RR pair per site
              Hierarchical: top-tier RRs + regional RRs + edge clients
Alternative   Confederations (rare)

Gotcha        remember next-hop-self on eBGP borders
              pick shared vs unique cluster-ids on purpose