BGP Route Reflector

Understanding BGP Route Reflectors: Simplifying iBGP Full Mesh

A detailed guide to BGP Route Reflectors—learn how they simplify iBGP full mesh, key reflection rules, configuration steps, loop prevention with Originator-ID and Cluster-ID, plus advantages and best practices for scalable and resilient network design.

The Border Gateway Protocol (BGP) is the backbone of the internet, responsible for exchanging routing information between different autonomous systems (ASes). When we move inside a single AS, we deal with Internal BGP (iBGP). iBGP ensures that routers within the same AS share consistent routing information.

However, iBGP comes with one important rule that creates scalability challenges:

Split-horizon rule of iBGP:
A route learned from one iBGP neighbor cannot be advertised to another iBGP neighbor.

This rule exists to prevent routing loops, but it also forces a requirement: iBGP needs a full mesh of peerings between all routers inside the AS.

The Problem with Full Mesh

Let’s start with an example. Suppose you have 5 routers inside an AS. For them to exchange routes via iBGP, you need a full mesh of sessions. The formula to calculate the required connections is:

N (N – 1) / 2

Where N is the number of routers.

• For 5 routers: 5(5–1)/2 = 10 sessions
• For 20 routers: 20(19)/2 = 190 sessions
• For 100 routers: 100(99)/2 = 4,950 sessions

As you can see, the number of sessions grows very quickly and becomes impossible to manage in large networks.

Full Mesh Topology connectivity diagram –

So how do we simplify this? This is where the BGP Route Reflector (RR) comes in.

What is a Route Reflector?

A Route Reflector is a special iBGP router that allows us to bypass the full mesh requirement. Instead of every iBGP router connecting to every other router, they simply connect to one or more Route Reflectors.

The RR then takes care of “reflecting” routes between its clients, solving the split-horizon problem.

This reduces the number of iBGP sessions dramatically while maintaining full route visibility.

Route Reflector Topology

Let’s imagine the same 5 routers, but now one of them is configured as a Route Reflector (R1).

• All other routers (R2, R3, R4, R5) form iBGP sessions only with R1.
• They are considered clients of the Route Reflector.
• R1 is responsible for reflecting routes between them.

So instead of 10 sessions, we now have only 4!

This is why Route Reflectors are widely used in service provider networks and large enterprises.

Route Reflector Clusters and Loop Prevention

When a Route Reflector (RR) is deployed, it and its clients together form what is called a cluster. Each cluster is identified by a Cluster ID, which plays a key role in loop prevention.

Two attributes are used to stop reflected routes from circulating endlessly:

• Originator ID → Records the Router ID of the device that originally advertised the route.
• Cluster ID → Marks the cluster through which the route has already passed.

Here’s how it works:

• Whenever the RR reflects a route, it attaches its own Cluster ID.
• If that same route later comes back carrying the same Cluster ID, the RR discards it—ensuring no loops form within the cluster.
• Similarly, the Originator ID prevents the route from being re-accepted by the router that first generated it.

Together, these mechanisms allow route reflection to scale iBGP designs without creating routing loops, making it possible to support large and complex networks efficiently.

In the below BGP prefix output you can see this information.

🔹 Types of Route Reflector Peerings

A Route Reflector can have three types of relationships:

1. eBGP neighbor – A regular external BGP peer.
2. iBGP Client – The routers that depend on the RR to receive reflected routes.
3. iBGP Non-Client – Regular iBGP peers; routes are not reflected to them automatically.

When configuring, it’s important to specify whether a peer is a client or a non-client—this determines whether the routes will be reflected.

When a Route Reflector (RR) redistributes routes, it follows a specific set of rules:

• Rule 1 – Routes from a non-client: If the RR learns a route from a non-client iBGP peer, it advertises it only to its clients, not to other non-clients.

• Rule 2 – Routes from a client: If the RR learns a route from a client, it reflects that route to both clients and non-clients. The originating client also receives the update but discards it, recognizing itself as the originator.

• Rule 3 – Routes from an eBGP neighbor: If the RR learns a route from an eBGP peer, it advertises it to both clients and non-clients.

Configuration–

Let’s walk through a simple example using three iBGP routers and one route reflector.

Complete configurations of all router for a reference:

Step by Step configuration –

In this setup, we have three routers: R1, R2, and R3. Under normal iBGP behavior, if R1 receives a route from R2, it will not forward that route to R3 due to the iBGP split-horizon rule. To overcome this limitation, we’ll configure R1 as the Route Reflector (RR).

We’ll begin by setting up the basic iBGP configuration on R2 and R3 first:

The configuration for R2 and R3 remains exactly the same as any standard iBGP peering setup. The only difference lies with the Route Reflector (R1)—this is where we apply the special configuration that enables reflection of routes between its clients.

Here’s where the magic happens: when configuring a Route Reflector, we need to explicitly define its clients. In this case, R1 and R3 are configured as clients of R2.

Now, let’s advertise the loopback IPs of R2 (2.2.2.2/32) and R3 (3.3.3.3/32) into BGP. Once these loopbacks are advertised, we can verify how the routes are exchanged across the network and confirm that the Route Reflector is properly distributing them.

This step will also help us validate end-to-end connectivity between the routers while showcasing how the Route Reflector eliminates the IBGP split-horizon rule.

After advertising lets verify the routes at both side –

Yes, at both end the routes are being exchanged let’s verify the connectivity –

On the Route Reflector (R1), if we check the BGP routing information, we can clearly see that the routes are being received from the RR client.

Have a look at the output in the image below — it shows the reflected prefixes along with the details of the client from which they were originally learned. This confirms that the RR is successfully receiving and processing routes from its clients before reflecting them onward.

Advantages of Route Reflectors

• Reduce iBGP session count
• Simplify configuration and management
• Improve scalability in large networks
• Allow flexible hierarchical designs with multiple RRs

Best Practices

• Redundancy: Always deploy at least two RRs for resiliency.
• Hierarchy: Large networks often use multiple layers of RRs.
• Next-Hop Handling: Use next-hop-self or policies when reflecting routes to avoid broken paths.
• Filtering: Apply route policies to maintain control and avoid unwanted route propagation.

Summary

The BGP Route Reflector is a powerful feature that solves the scalability issues of iBGP. Instead of building a full mesh, we can designate one or more routers as Route Reflectors, which then handle the distribution of routes among their clients.

By understanding the rules, loop prevention mechanisms, and best practices, network engineers can design scalable and resilient iBGP topologies that support both service provider and enterprise networks.