Info from http://freeccnplab.com/2013/12/30/free-ccnp-gns3-lab-bgp-route-reflector/
One important point to remember about iBGP relationships is that iBGP assumes that all of the routers within a single AS are fully meshed.
That is, each router is peered to every other router within the same AS. The purpose of this is namely to fix any issues around loop prevention.
You’ll recall the BGP uses the AS-Path attribute to prevent against loops. A BGP speaker will drop any update it receives that has its own AS listed in the AS-Path attribute. Since iBGP updates are sent within a single AS, the AS-path attribute isn’t updated and if iBGP speakers continued to forward updates, we would have routing loops. Bottom line is that iBGP speakers will not forward iBGP learned routes to other iBGP peers.
In some network designs, peering each router to every other router in the same AS could be quite complicated and costly.
One of the ways to get around this restriction is to use route reflectors (RR):
- RR allow iBGP speakers to have a partial mesh topology while still propagating all iBGP learned routes to all iBGP speakers
- RR consist of RR servers and RR clients
- eBGP routes learned by RR servers are advertised to other eBGP neighbors, RR clients and non-clients.
- iBGP routes learned from non-clients are advertised to eBGP neighbors and RR clients
- iBGP routes learned from RR clients are advertised to other clients, non-clients and eBGP neighbors.