What is a BGP Route Reflector?

The Full Mesh Problem

Due to the BGP split-horizon rule (within iBGP), all iBGP peers within an AS must be fully meshed.
Why may you ask? Whereas eBGP uses the AS-PATH for loop avoidance, iBGP neighbours do not add their ASN to the AS_PATH when sending updates. So what does iBGP use for loop prevention? Split horizon. The rule of iBGP split-horizon states:

"Any routes learnt from an iBGP neighbour must never be advertised to any other iBGP neighbour."

This presents complexity and scalability issues to both the BGP routers and the network due to the number of unique BGP sessions required.

For example, The total number of unique BGP sessions required within the AS can be calculated using the following, where n = BGP speakers within AS: n*(n-1)/2, i.e. 10 BGP routers would require 45 BGP sessions to be fully meshed.

Route Reflection

One solution to reducing the number of BGP peerings within an AS is route reflection. Rather than each BGP system having to peer with every other BGP system with the AS, each BGP speaker instead peers with a router reflector. Routing advertisements sent to the route reflector are then reflected out to all of the other BGP speakers.

The route reflector reflects routes considered as best only. Additionally, a route reflector is NOT allowed to change any reflected route attribute, including the next-hop attribute.

Peer Types

There are two types of internal peers to a route reflector - Client and Non-Client. Let's look at the differences,

Furthermore, to summarize the above, ONLY the route reflector is aware of a client and a non-client. To the route reflector, the non-client is just another iBGP peer. Because of this, the route reflector must adhere to the BGP split-horizon rule; hence routes from a non-client are only reflected to clients.

Routing Information Loops

Let's look at the three BGP attributes used to prevent routing information loops when using route reflectors.

CLUSTER_ID

To prevent a route reflector being a single point of failover, multiple RRs can be configured. However, this presents a potential issue around advertisement loops between RRs. To have multiple RRs within the _same cluster, _all RRs in the same cluster can be configured with a 4-byte CLUSTER_ID so that an RR can discard routes from other RRs in the same cluster.^[1]

CLUSTER_LIST

But what if what our RR to be part of multiple clusters? In this case, the RR will use different CLUSTER_IDs for the relevant RR neighbours and appended its CLUSTER_ID to the CLUSTER_LIST attribute. When the RR receives an UPDATE that contains the router's CLUSTER_ID within the CLUSTER_LIST, the update is discarded.^[2]

ORIGINATOR_ID

When the route reflector reflects a path, it assigns router ID of the advertising router using the ORIGINATOR_ID attribute. If any router then receives an UPDATE that includes a path that contains an ORIGINATOR_ID matching its own router ID, the UPDATE is ignored.

Configuration

router bgp 500
  ...
  neighbor 3.3.3.3 route-reflector-client 

r1#show ip bgp 150.1.1.0/24
BGP routing table entry for 150.1.1.0/24, version 10
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     20         21         22        
  Refresh Epoch 2
  64512, (Received from a RR-client)
    150.0.0.17 (metric 2) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

References