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.