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 neighbors 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 learned from an iBGP neighbor must never be advertised to any other iBGP neighbor.”
Figure 1 - BGP Split Horizon.
This, of course, 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 in order to be fully meshed.
Figure 2 - Full mesh peering.
One solution to reduce 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.
Figure 3 - Reduced iBGP sessions.
The route reflector reflects routes considered as best only. Additionally, a route reflector is NOT allowed to change any attribute of the reflected route including the next-hop attribute.
The are two types of internal peers to a route reflector - Client and Non-Client. Let's look at the differences:
Note: A cluster is just a collection of Router Reflectors and Router Reflector clients.
|Peer Type||Full Mesh||Cluster||
|Client (RR Client)||Not Required||With other clients and RR to form a cluster||A route from a client peer is reflected to all the non-client peers and client peers (Figure 4)|
|Non-Client (Regular iBGP)||Required||Sits outside of the cluster||A route from a non-client iBGP peer reflect to all the clients (Figure 4)|
Furthermore, and to summarize the above: ONLY the route reflector is aware of who is a client and who is a non-client. To the route reflector, the non-client is simply 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.
Figure 4 - Client vs Non-Client.
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. In order 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. 
- 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 neighbors and appended its CLUSTER_ID to the CLUSTER_LIST attribute. When the RR receives an UPDATE that contains the router's own CLUSTER_ID within the CLUSTER_LIST, the UPDATE is discarded. 
- 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.
The configuration to define a router reflector is extremely simple. Note: Below is based on Cisco IOS.
Configure RR Client
R1(config)# router bgp 65001 R1(config)# ... R1(config)# neighbor 188.8.131.52 route-reflector-client
R1# show ip bgp 184.108.40.206/24 BGP routing table entry for 220.127.116.11/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) 18.104.22.168 (metric 2) from 22.214.171.124 (126.96.36.199) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0
 "RFC 4456 - BGP Route Reflection: An Alternative to Full ... - IETF Tools." https://tools.ietf.org/html/rfc4456 . Accessed 15 Nov. 2017.
 "BGP Route Reflection and Multiple Cluster IDs - Cisco." 14 Sep. 2015, https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/200153-BGP-Route-Reflection-and-Multiple-Cluste.html . Accessed 15 Nov. 2017.