Route reflector

A route reflector is a technique for interconnecting Border Gateway Protocol (BGP) routers, inside an autonomous system, to improve scalability. One of the major scalability problems of BGP running over TCP is that TCP takes a substantial amount of processing, as can the per-interface issues of BGP setup, advertising, and acceptance. Two techniques, route reflectors and BGP confederations can reduce the need for the high overhead of full meshing. The methods can be used in conjunction with one another.

Architecture

The basic rule of iBGP is that all BGP speakers within an AS must peer with one another, which leads to an exponential growth of BGP sessions. Session maintenance, both of the BGP session proper and the TCP connection over which it runs, are processor-intensive and may require more powerful router control plane hardware.

BGP route reflector introduce hierarchy, a well-recognized means of scaling, into iBGP. Route reflector clusters have at least one route reflector that acts as a server to other iBGP speakers within the cluster, and some number of route reflector clients. There must be full iBGP meshing inside the cluster, but only the route reflector server needs to peer, via iBGP, with other iBGP speakers (including other clusters) inside the AS. Route reflection improves iBGP scalability by removing the need to have a full mesh of BGP sessions among all routers in the AS; it allows the creation of hierarchies of routers, with full mesh only on the "route servers" in each "cluster" of BGP speakers.

Basic cluster structure

A basic cluster has a reflector that connects, in a full mesh, to all other iBGP nodes not in clusters, and some number of route reflector clients, which have iBGP sessions with the reflector but none outside the reflector cluster.

Fault tolerance

To improve fault tolerance, there can be more than one reflector. The reflectors have iBGP sessions with one another, and with each client.

Hierarchies of clusters

A reflector in one cluster can simultaneously be a client in a hierarchically higher cluster, as long as the protocol messages in each cluster are disambiguated with a cluster identifier parameter.

Pathologies of route reflection

Both major techniques can suffer from instability unless you use an OSPF-like rule. In OSPF, intra-area routes are always preferred, regardless of metric. The equivalent, for avoiding oscillation, is always to prefer cluster-local or confederation-internal routes.

Route reflectors and confederations

While both techniques allow increased iBGP scalability, they do it in different ways, and indeed the two techniques may be used in the same AS. Confederations give more policy control than do route reflectors, but with greater complexity and overhead. It is perfectly reasonable, however, to have route reflector clusters, or even hierarchies of clusters, inside confederation-specific autonomous systems.