Your local AS has a large number of IBGP routers, and you want to reduce the number of IBGP sessions that you need to configure and maintain.
Configure one of the IBGP routers to be the route reflector for a route reflection cluster:
[edit protocols bgp] aviva@RouterG#
The configuration in Recipe 13.2, in which all BGP systems within the AS are fully meshed, is a standard IBGP implementation. The full mesh results from listing all
IBGP peers in a peering group rather than from having them all be physically connected and from using an IGP within the AS to distribute BGP routes. The full mesh is necessary so that external routing information can be redistributed among all routers within the AS with the help of the IGP running in the AS. As you can imagine, as the number of IBGP routers increases, you have to configure many BGP
neighbor commands in each router's configuration, and there is a lot of overhead because a large number of TCP connections need to be maintained for each IBGP peering.
There are two common ways to deal with this scaling issue. One is route reflection, which provides one means of decreasing BGP control traffic and minimizing the number of update messages sent within the AS. The second method is confederations.
With normal BGP route redistribution rules, IBGP peers are not allowed to advertise routes learned from IBGP rules. Route reflection works ...