Split-horizon
Split-horizon rule is to prevent the routing loop. In IBGP a router that learns prefixes from a BGP speaker will not advertise to BGP speaker, this makes a full mesh IBGP peering necessary for other BGP speakers to know about the routes.
The number of TCP sessions can be calculated with this formula n (n-1)/2 where n is the number of BGP speakers. Let's say if there are 10 BGP speakers the number of TCP sessions needed in a full mesh peering is 45.
In order to reduce the number of TCP sessions as the network grow, a route reflector can be used. Route reflector bypasses the split-horizon rule, route learned from an IBGP speaker will be advertised to another IBGP speaker, the IBGP speakers however will peer to route reflector only.
Route Reflector
A BGP router implementing route reflector functionality propagates BGP routes according to these rules:
Locally originated routes and routes received from EBGP peers and selected as best routes are propagated to all BGP internal and external peers. The routes received from IGBP peer that is not a route-reflector client and the best routes are propagated to EBGP and IGBP routers configured as route-reflector clients. Routes are received from a route-reflector client and the best routes are propagated to all BGP peers (internal and external). Whenever an IBGP route is reflected to another IBGP peer, the route reflector appends two optional non-transitive attributes to the BGP route.
If a route does not have an Originator ID attribute the router ID of the neighbor IBGP peer from which the route has been received is copied into the Originator attribute. If the route does not have the Cluster ID attribute, its added to the route. The value configured with the BGP cluster-id router configuration command or the router ID of the route reflector is prepended to the Cluster list attribute.
Route reflector configured router does not change or remove any other attributes of the advertised routes, ensuring that there is no change in IBGP routes inside an autonomous system. The next-hop-self neighbor configuration parameter or set options of outbound route-map configured on route-reflector clients are ignored for reflected routes.
BGP next-hop can be changed by set IP next-hop route-map command or with neighbor next-hop-self all feature introduced to support large-scale DMVPN networks using IBGP.
Standard and extended BGP communities are removed from the reflected routes unless the neighbor send-community is configured. The link bandwidth community is removed from the reflected route if the route-reflector performs IBGP multipath load-sharing for that route.
