BGP Route Reflector

You built an iBGP full mesh. The ping succeeded, but this design quickly hits a wall.
Remember the iBGP split-horizon rule: a router never re-advertises an iBGP-learned route to another iBGP peer.

Figure 1 – Three routers, three iBGP sessions

To keep full reachability, every single router must connect directly to every other router.

Session Scaling

This does not scale.
Every new router must connect to all existing devices, and your session count compounds rapidly.

Figure 2 – Ten routers, 45 iBGP sessions

You calculate this growth with a simple formula, where n is the number of routers:

n(n-1)/2

Watch how fast your connections explode:

• 3 routers: 3 sessions.

• 10 routers: 45 sessions.

• 50 routers: 1,225 TCP connections.

With hundreds of routers in a real provider core, a full mesh becomes impossible to maintain.

Configuration Overhead

Session counts are only half the problem.

Adding a single new router forces you to log into every existing device to add a neighbor line.
You need a design where adding a device requires zero changes elsewhere.

To fix this, you break the split-horizon rule on one router.
You deploy a Route Reflector (RFC 4456).

The Hub-and-Spoke Architecture

Figure 3 – One route reflector, two iBGP sessions

• The Reflector (R3): This is your hub. It sits between your edges as the only router exempt from split horizon.

• Clients (R2 and R4): You explicitly declare these spoke routers on R3. They peer only with the reflector using standard iBGP.
  Your client does not even know it is a client.

• Non-Clients: These are standard iBGP neighbors outside the cluster. Toward them, R3 behaves normally.

This design drops your sessions from 3 down to 2.
With 10 routers, you drop from 45 sessions down to just 9.

When R3 receives a route, its choice depends entirely on who sent it.

Rule 1 – Route from eBGP

You reflect this route to all clients and non-clients.
This matches standard BGP behavior.

Figure 4 – Rule 1, an eBGP route goes to everyone

The reflector sends it to every iBGP neighbor.
Every BGP router already does this, reflector or not.

Rule 2 – Route from a Client

You reflect this route to all clients and non-clients, the sender included.
This rule replaces your full mesh.

Figure 5 – Rule 2, a client route goes to everyone

R4 sends a route to R3. R3 reflects it to R2 and R6.
R3 even sends it back to R4. R4 recognizes its own router ID inside the route and drops it, thanks to an attribute you meet in section 4. Figure 5 leaves that useless copy out.

Rule 3 – Route from a Non-Client

You reflect this route to clients only.
You never send it to other non-clients.

Figure 6 – Rule 3, a non-client route goes to clients only

Non-clients are still subject to split horizon.
They must remain fully meshed among themselves outside the cluster.

Reflection Rules Summary

• From eBGP: Reflected to clients and non-clients.

• From a client: Reflected to clients and non-clients.

• From a non-client: Reflected to clients only.

Bypassing split horizon removes internal loop protection.
BGP replaces it with two new attributes.

Figure 7 – The reflected route carries two new attributes

ORIGINATOR_ID

R3 stamps the route with the router ID of the node that injected it, like 4.4.4.4.

If a router receives a route matching its own router ID, it drops it immediately.
This stops the originator from accepting its own route back.

CLUSTER_LIST

Each reflector prepends its cluster ID, which defaults to its router ID like 3.3.3.3.
If a reflector sees its own cluster ID in the list, it drops the route. This stops loops between redundant reflectors.

That wraps up the theory.
In the next lesson, you configure it on R3 and read both attributes in the CLI.