Remember the split horizon rule in iBGP? Route Reflector (RFC 4456) is one of the three solutions and often use as an alternative to Full Mesh topology. Route Reflectors allows iBGP speaker to have partial mesh topology while still propagating iBGP routes to another iBGP speaker. It modifies the iBGP split horizon rule by allowing the router to forward incoming iBGP updates to an outgoing iBGP session under. With Route Reflector, it lowers CPU and memory requirements by reducing the number of TCP sessions to be maintained.

Route Reflector has two iBGP peers: Client peers and Non-Client peers. Route-Reflector clients behave like normal iBGP routers. They are not required to form full mesh, can have any number of eBGP sessions and they can have only one iBGP session and that is the connection to Route-Reflector. When Route Reflector fails, they can no longer receive or send updates to the rest of the AS. In this kind of design, Route Reflector represents a single point of failure. In order to solve this, we need redundant Route Reflectors. Each Clients needs to connect to redundant Route Reflectors. Route Reflectors receive the same iBGP update from its Clients and reflect it all other Clients and Route Reflectors send same routes to each Clients.

The use of redundancy in Route Reflectors may introduce routing loops in the network. However, no need to worry as Route Reflector has Cluster_List and Originator_ID attributes.

Route Reflector and its Clients formed a cluster. Each cluster must have a unique Cluster ID. The Cluster ID is being prepended to the “Cluster_List” each time the route is being reflected. Cluster_List is an Optional Non-Transitive BGP attribute. Remember the BGP Path selection process? It is the 12th criteria of BGP selection attribute. Like AS Path, the minimum cluster list length is more preferred. Also like AS Path, it shows the path the route has passed. It also serves as a loop avoidance mechanism as it discarded routes with the same local Cluster ID. Take note that Cluster ID is configured in Route Reflector. When a Route Reflector receives a routing update from another Route Reflector in the same cluster, it rejects the update.

There is another loop avoidance mechanism of Route Reflector and that is the Originator_ID. It is another Optional Non-Transitive BGP Attribute and as the name suggests, it identifies the originator of the route. The router ID is added as the Originator_ID to the route when received from eBGP peer and when there is already one exists, a router needs not to add another Originator_ID. When a routing update is received from the same local Originator_ID, then the update is discarded.

All other that are not part of the cluster are non-clients. Non Clients do not support Route Reflector functionalities. Unlike with Clients, Non-Clients need to fully mesh.

Route Reflector Forwarding of Prefixes Rules

Route Reflector propagates eBGP learnt prefixes and iBGP prefixes learnt prefixes from Clients and Non-Clients to Clients. Route reflector propagates eBGP learnt prefixes and iBGP learnt prefixes from Clients to Non-Clients. It will not forward learnt iBGP prefixes from Non-Clients to Non-Clients.

Before we end this discussion, there is one more important thing to remember. A Route Reflector can reflect route only within a single cluster. It can participate in multiple clusters but only as a client. A client can only function as a client only to Route Reflector belonging to the same cluster.