Light when bounces off an object is called “reflection.” Remember the “Law of Reflection” during High School days? The angle of incidence equals to the angle of reflection. Thinking about this might somehow give you a better grasp on the BGP Route Reflectors. As we progress this topic, you will see how routes are reflected.
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.