BGP Route Reflectors

Another solution for the explosion of IBGP peering within an autonomous system is Route Reflectors (RR).

As demonstrated in the Internal BGP section, a BGP speaker will not advertise a route learned via another IBGP speaker to a third IBGP speaker. By relaxing this restriction a bit and by providing additional control, we can allow a router to advertise (reflect) IBGP learned routes to other IBGP speakers. This will reduce the number of IBGP peers within an AS.




In normal cases, a full IBGP mesh should be maintained between RTA, RTB and RTC within AS100. By utilizing the route reflector concept, RTC could be elected as a RR and have a partial IBGP peering with RTA and RTB. Peering between RTA and RTB is not needed because RTC will be a route reflector for the updates coming from RTA and RTB.

neighbor route−reflector−client

The router with the above command would be the RR and the neighbors pointed at would be the clients of that RR. In our example, RTC would be configured with the neighbor route−reflector−client command pointing at RTA and RTB's IP addresses. The combination of the RR and its clients is called a cluster. RTA, RTB and RTC above would form a cluster with a single RR within AS100.

Other IBGP peers of the RR that are not clients are called non−clients.


An autonomous system can have more than one route reflector; a RR would treat other RRs just like any other IBGP speaker. Other RRs could belong to the same cluster (client group) or to other clusters. In a simple configuration, the AS could be divided into multiple clusters, each RR will be configured with other RRs as non−client peers in a fully meshed topology. Clients should not peer with IBGP speakers outside their cluster.

Consider the above diagram. RTA, RTB and RTC form a single cluster with RTC being the RR. According to RTC, RTA and RTB are clients and anything else is a non−client. Remember that clients of an RR are pointed at using the neighbor route−reflector−client command. The same RTD is the RR for its clients RTE and RTF; RTG is a RR in a third cluster. Note that RTD, RTC and RTG are fully meshed but routers within a cluster are not. When a route is received by a RR, it will do the following depending on the peer type:

1. Route from a non−client peer: reflect to all the clients within the cluster.
2. Route from a client peer: reflect to all the non−client peers and also to the client peers.
3. Route from an EBGP peer: send the update to all client and non−client peers.

The following is the relative BGP configuration of routers RTC, RTD and RTB:

RTC#
router bgp 100
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 route−reflector−client
neighbor 1.1.1.1 remote−as 100
neighbor 1.1.1.1 route−reflector−client
neighbor 7.7.7.7 remote−as 100
neighbor 4.4.4.4 remote−as 100
neighbor 8.8.8.8 remote−as 200

RTB#
router bgp 100
neighbor 3.3.3.3 remote−as 100
neighbor 12.12.12.12 remote−as 300

RTD#
router bgp 100
neighbor 6.6.6.6 remote−as 100
neighbor 6.6.6.6 route−reflector−client
neighbor 5.5.5.5 remote−as 100
neighbor 5.5.5.5 route−reflector−client
neighbor 7.7.7.7 remote−as 100
neighbor 3.3.3.3 remote−as 100

As the IBGP learned routes are reflected, it is possible to have the routing information loop. The Route Reflector scheme has a few methods to avoid this:

1. Originator−id: this is an optional, non transitive BGP attribute that is four bytes long and is created by a RR. This attribute will carry the router−id (RID) of the originator of the route in the local AS. Thus, due to poor configuration, if the routing information comes back to the originator, it will be ignored.
2. Cluster−list: this will be discussed in the next section.