By default, iBGP routers must use a full-mesh topology. As the network grows, this presents a scalability problem.

One of the ways we can manage this is with route reflectors. How big does the network have to be before you use them? As a general rule, if there are more than four iBGP speakers, it’s time to use route reflectors. And, you should always use more than one for redundancy.

Spend some time thinking about where you will place your route reflectors. This is where to place them in the topology, and which routers to use based on available resources.

From a topology perspective, the route-reflectors are best placed centrally. This helps to prevent sub-optimal routing.

Regular BGP speakers may peer with Route Reflectors, or other non-RR’s. Ideally, it’s best to have all non-RR’s peering with route-reflectors. Sometimes this is not practical, so make your mind up based on your needs.

In some cases, routers may be dedicated to being route-reflectors. That is, they do not forward traffic, just reflect routes. How to do this depends on your needs.

Dedicated RR’s only pass routing information. They won’t be in the data path, so the control plane is more of a concern than the data plane. So, while a large network may need a high-end router, smaller networks may be able to use virtual routers. This is a cost-effective and scalable option.

By default, any prefixes that a BGP speaker learns ends up in the RIB and FIB. A dedicated RR does not need the prefixes in the FIB. So, consider filtering these out of the FIB with the table-map command.

If you have only one route-reflector, this router becomes a single point of failure. To solve this problem, we use clusters.

Each route reflector in a cluster has a cluster-id. We assign this ID on the RR. The client is unaware of any special configuration and has normal configuration. The ID itself may be manually configured or assigned based on the router-ID.

To prevent loops, the route reflectors add additional attributes to the prefixes. The cluster-list attribute is a list of Cluster ID’s that the prefix has passed through.

One design approach allocates the same cluster-ID to all route reflectors. All RR’s will receive updates from clients and will reflect them to other RR’s. RR’s in the cluster discard these updates, as the cluster ID matches their own. Fully mesh clients with all RR’s in the cluster. This is a simple design but may result in sub-optimal routing in some cases.

Another approach is to allocate a different cluster-ID to each route reflector. Each RR is in a different cluster, but this still mitigates the single point of failure. Loop prevention now uses the Router-ID rather than the cluster-ID. Further, optimise routing by evaluating the cluster-list length.

Route Reflectors limit the need to have a full-mesh in your iBGP topology. Unfortunately, you still need a full-mesh between your route reflectors.

To address this, consider deploying route reflectors hierarchically. The idea behind this is to create multiple clusters. Route reflectors can then become clients of other route reflectors. Creating these layers breaks the full mesh into smaller areas.

Try not to create more levels of hierarchy than needed. This can become more difficult to manage.