BGP Route Reflectors: Eliminating the Full Mesh

The iBGP full mesh requirement becomes unmanageable quickly — 10 routers need 45 sessions, 50 routers need 1,225. Route reflectors solve this by allowing designated routers to re-advertise iBGP-learned routes to other iBGP peers, breaking the split-horizon rule in a controlled way. This is the standard approach for scaling iBGP in both enterprise and service provider networks.

How Route Reflection Works

A route reflector (RR) is an iBGP peer with a special role: it's allowed to re-advertise routes learned from one iBGP peer to other iBGP peers. Its iBGP peers are divided into two categories:

• Clients: Routers explicitly configured as RR clients via route-reflector-client. Routes learned from a client are reflected to all other clients and non-client iBGP peers.
• Non-clients: Regular iBGP peers. Routes learned from a non-client are reflected to clients only. Non-clients must still be fully meshed with each other (or served by another RR).

The reflection rules:

1. Route learned from an eBGP peer → advertised to all iBGP peers (clients and non-clients). Normal eBGP-to-iBGP behavior.
2. Route learned from a client → reflected to all other clients AND all non-client iBGP peers.
3. Route learned from a non-client iBGP peer → reflected to clients only.

Configuration

Designating R1-HQ as a route reflector with R2-HQ as its client:

R1-HQ(config)# router bgp 65001
R1-HQ(config-router)# neighbor 2.2.2.2 remote-as 65001
R1-HQ(config-router)# neighbor 2.2.2.2 update-source Loopback0
R1-HQ(config-router)# neighbor 2.2.2.2 route-reflector-client
R1-HQ(config-router)# neighbor 2.2.2.2 next-hop-self

On R2-HQ, no special configuration is needed — it doesn't know (or need to know) that it's an RR client:

R2-HQ(config)# router bgp 65001
R2-HQ(config-router)# neighbor 1.1.1.1 remote-as 65001
R2-HQ(config-router)# neighbor 1.1.1.1 update-source Loopback0

That's it. The route-reflector-client command is only on the RR side. The client's configuration is identical to a standard iBGP peer.

Loop Prevention

Since route reflectors break the split-horizon rule, BGP needs another mechanism to prevent loops. Two attributes handle this:

ORIGINATOR_ID

The RR sets ORIGINATOR_ID to the router-id of the route's originator (the client that first advertised it). If a router receives a route with its own router-id in the ORIGINATOR_ID, it rejects the route. This prevents routes from looping back to their source.

CLUSTER_LIST

Each RR has a cluster-id (defaults to its router-id). When reflecting a route, the RR prepends its cluster-id to the CLUSTER_LIST attribute. If an RR receives a route with its own cluster-id already in the CLUSTER_LIST, it rejects the route. This prevents loops in hierarchical or redundant RR designs.

R2-HQ# show ip bgp 100.64.0.0/18
BGP routing table entry for 100.64.0.0/18, version 15
Paths: (1 available, best #1, table default)
  65010, (Received from a RR-client)
    1.1.1.1 from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 1.1.1.1, Cluster list: 1.1.1.1
      rx pathid: 0, tx pathid: 0x0

The Originator and Cluster list fields confirm this route was reflected.

Cluster-ID

By default, the RR uses its router-id as the cluster-id. In a redundant RR design (two RRs serving the same clients), both RRs should share the same cluster-id so they recognize each other's reflected routes and avoid duplicates:

R1-HQ(config-router)# bgp cluster-id 10.255.0.1

If each RR has a unique cluster-id (the default), clients receive duplicate routes — one from each RR — with different cluster-lists. This wastes memory but isn't a loop risk. Shared cluster-id is more efficient.

Redundant Route Reflector Design

Never deploy a single RR — it's a single point of failure for your entire iBGP mesh. Standard design:

• Two RRs per cluster, sharing the same cluster-id
• All clients peer with both RRs
• RRs peer with each other (iBGP) and with any non-client iBGP peers
• RRs should be placed on routers that are topologically central to minimize path distortion

Hierarchical Route Reflectors

In very large networks (ISP scale), a single RR level may not be enough. You can create hierarchical RR designs where top-level RRs reflect to lower-level RRs, which in turn reflect to their clients. The CLUSTER_LIST grows with each level, providing loop prevention across the hierarchy.

Path Selection Impact

Route reflectors can subtly affect path selection. The RR selects the best path from its own perspective and reflects only that best path to clients. If the RR's best path differs from what a client would choose (because the RR has different IGP costs), the client gets a suboptimal path. This is called the "RR path selection problem."

Mitigation options:

• Place RRs on routers with representative IGP costs (often the core or dedicated RR-only boxes)
• Use bgp additional-paths to allow the RR to reflect multiple paths, not just the best
• Design the IGP topology so the RR's view is representative of most clients

Verification

R1-HQ# show ip bgp neighbors 2.2.2.2 | include reflector
  Route-Reflector Client

R1-HQ# show ip bgp 100.64.0.0/18
  ...
  Advertised to update-groups:
     1          2
  65010
    172.16.0.2 from 172.16.0.2 (203.0.113.1)
      Origin IGP, metric 0, localpref 100, valid, external, best

The route is advertised to update-group 2, which includes the RR client R2-HQ.

Troubleshooting

Key Takeaways

• Route reflectors eliminate the iBGP full mesh by allowing designated routers to re-advertise iBGP routes to other iBGP peers.
• Only the RR needs route-reflector-client configuration — clients are configured as normal iBGP peers.
• Loop prevention uses ORIGINATOR_ID (prevents routes returning to source) and CLUSTER_LIST (prevents loops between RRs).
• Always deploy redundant RRs with a shared cluster-id. A single RR is a single point of failure.
• RRs can cause suboptimal path selection because they reflect only their own best path — consider bgp additional-paths for large-scale deployments.