BGP Route Reflectors

Rules says that, routes learned via iBGP will never be advertised to another iBGP peer in normal conditions. One way to overcome this rule is to create a full mesh topology among iBGP peers. But in some conditions this is not feasible due to many reasons. So an alternative to BGP full mesh topology is Route Reflectors, which allows a router to advertise, or reflect, iBGP learned routes to other iBGP speakers. This route reflection reduces the number of iBGP peers within an AS.

In normal cases, maintain a full iBGP mesh among RTA, RTB and RTC within AS 100. If you utilize the RR concept, RTC can be elected as an RR. In this way, RTC has a partial iBGP peering with RTA and RTB. Peering between RTA and RTB is not necessary because RTC is an RR for the updates that come from RTA and RTB.
neighbor A.B.C.D route-reflector-client

The router with this command is the RR, and the neighbors at which the command points are the clients of that RR. In the example, the RTC configuration has the neighbor router-reflector-client command that points at the RTA and RTB IP address. The combination of the RR and the clients is a "cluster". In this example, RTA, RTB, and RTC form a cluster with a single RR within AS100.

Other iBGP peers of the RR that are not clients are "nonclients".


As AS can have more than one RR. In this situation, an RR treats other RRs just like any other iBGP speaker. Other RRs can belong to the same cluster (client group) or to other clusters. In a simple configuration, you can divide the AS into multiple clusters. You configure each RR with other RRs as nonclient peers in a fully meshed topology. Clients should not peer with iBGP speakers outside the client cluster.
Multiple Clusters

Consider the above diagram (Multiple Clusters). RTA, RTB and RTC form a single cluster where RTC is the RR. For RTC, RTA and RTB are clients and anything else is a nonclient. Remember that the neighbor route-reflector-client command points at clients of an RR. Similarly, RTD is the RR for clients RTE and RTF. RTG is an RR in the third cluster.

Note: RTD, RTC and RTG are fully meshed, but routers within a cluster are not. When an RR receives a route, the RR routes as list shows. However this activity depends on the peer type:
  1. Routes from a nonclient peer ▬ Reflects to all the clients within the cluster.
  2. Routes from a client peer ▬ Reflects to all the nonclient peers and also the client peers.
  3. Routes from an eBGP peer ▬ Sens the update all client and nonclient peers.
 Here 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

Because there is a reflection of the iBGP learned routes, there can be a routing information loop. the RR schemes has a few methods to avoid this loop:
  • Originator-ID: This is an optional, non-transitive BGP attribute that is 4 bytes long. An RR creates this attribute. The attribute carries the router ID (RID) of the originator of the route in the local AS. If, due to poor configuration, the routing information comes back to the originator, the information is ignored.
  • Cluster-list: A cluster list is a sequence of cluster IDs that the route has passed. When an RR reflects a route from the RR clients to nonclients outside of the cluster, the RR appends the local cluster ID to the cluster list. If this update has an empty cluster list, The RR creates one. With this attribute, an RR can identify if the routing information has looped back to the same cluster due to poor configuration. If the local cluster ID is found in the cluster list, the advertisement is ignored.


Redundancy with Multiple RRs within a Cluster

Usually, a cluster of clients has a single RR. In this case the router ID of the RR identifies the cluster. In order to increase redundancy and avoid single point of failure, a cluster can have more than one RR. You need to configure all RRs in the same cluster with a 4-byte cluster ID so that an RR can recognize updates from RRs in the same cluster.
Multiple RRs within a cluster
In the above diagram (Multiple RRs within a cluster) in this section, RTD, RTE, RTF and RTH belong to one cluster. Both RTD and RTH are RRs for the same cluster.

Note: There is redundancy because RTH has fully meshed peering with all the RRs. If RTD goes down, RTH takes the place of RTD.

Here is  the configuration  of RTH, RTD, RTF, and RTC:
RTH#
router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100
neighbor 9.9.9.9 remote-as 300
bgp cluster-id 10
 RTD#
router bgp 100
neighbor 10.10.10.10 remote-as 100
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100
neighbor 11.11.11.11 remote-as 400
bgp cluster-id 10
RTF#
router bgp 100
neighbor 10.10.10.10 remote-as 100
neighbor 4.4.4.4 remote-as 100
neighbor 13.13.13.13 remote-as 500
RTC#
router bgp 100
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-reflector-client
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-reflector-client
neighbor 4.4.4.4 remote-as 100
neighbor 7.7.7.7 remote-as 100
neighbor 10.10.10.10 remote-as 100
neighbor 8.8.8.8 remote-as 200
 Note: You do not need the bgp cluster-id command for RTC because only one RR exists in that cluster.





No comments:

Post a Comment