Deploying BGP RRs allows IBGP peers to communicate without establishing full-mesh connections between them. Using BGP RRs simplifies network configurations and improves route advertisement efficiency.
To ensure the connectivity between IBGP peers within an AS, you need to establish full-mesh connections between the IBGP peers. When there are many IBGP peers, it is costly to establish a fully-meshed network. A route reflector (RR) can solve this problem.
A cluster ID can help prevent routing loops between multiple RRs within a cluster and between clusters. When a cluster has multiple RRs, the same cluster ID must be configured for all the RRs within the cluster.
If full-mesh IBGP connections are established between clients of multiple RRs, route reflection between clients is not required and wastes bandwidth resources. In this case, prohibit route reflection between clients to reduce the network burden.
Within an AS, an RR transmits routing information and forwards traffic. When an RR connects to a large number of clients and non-clients, many CPU resources are consumed if the RR transmits routing information and forwards traffic simultaneously. This also reduces route transmission efficiency. To improve route transmission efficiency, prohibit BGP from adding preferred routes to IP routing tables on the RR to enable the RR only to transmit routing information.
bgp { as-number-plain | as-number-dot }
peer { ipv4-address | group-name } reflect-client
reflector cluster-id cluster-id
By default, each RR uses its router ID as the cluster ID.
By default, route reflection is allowed between clients.
routing-table rib-only [ route-policy route-policy-name ]
By default, BGP adds preferred routes to IP routing tables.