Home » BGP » Route Reflectors and Confederations

Route Reflectors and Confederations

Route Reflectors (RR) are useful when the organization has a lot of IBGP Routers. Normally for creating a fully meshed IBGP network the number of IBGP sessions will be n(n-1)/2 where n = number of IBGP Routers. Suppose an organization has 10 IBGP routers then it will need 45 peering sessions if all these 10 IBGP Routers are fully meshed. Route Reflectors (RR) offer a solution to having a fully meshed IBGP network. In most cases creating a fully meshed IBGP Structure is not possible, so using Route Reflectors (RR) all the IBGP routers in an organization do not have to be fully meshed and this solution will also bring down the number of IBGP peering sessions.

Using RR the number of IBGP sessions will be only (n-1) where n = number of IBGP Routers. Going back to the same  scenario where an organization has 10 IBGP routers, now with using RR the number of IBGP peering sessions needed will be only 9 instead of 45 when using the full mesh IBGP.

Implementing RR involves declaring atleast one router as Route Reflector (RR) and all other IBGP routers peer only with the RR. All other IBGP routers which peer with RR are called as clients. Collectively the RR and the Clients are called as a cluster.

There is however one IBGP rule which states that routes learnt from one IBGP neighbor cannot be advertised to other IBGP neighbors. This makes sure all the routers running IBGP must peer with each other to advertise and receive the routes forming a full mesh. However RR implementation completely ignores this IBGP rule and this rule is no longer applied when implementing RR. The reason for relaxing this rule is that all clients in the cluster will peer with the RR and RR will learn the routes from all clients and then advertise the learned IBGP routes from one IBGP Peer to other IBGP peers in the cluster.

Some of rules which are followed when using Route Reflector are

1. RR cannot change the path attributes received in the route advertisements from  IBGP clients. This is to avoid any routing loops or routing errors.

2. The RR can peer with both internal and external BGP neighbors. In addition to the Internal Peers  within the cluster, it can also peer with other IBGP Peers which are not in the cluster. So RR can peer with both external and internal BGP Routers within and outside of the cluster.

3. The Clients can peer with external BGP neighbors, but internally they can only peer with the RR and the clients within the cluster. The clients cannot peer with other IBGP Routers which are not a part of the cluster.

Since IBGP and IGP Synchronization rule states that to avoid any potential loops BGP cannot forward a route learnt from one IBGP Peer to another because the AS_Path attribute does not change within the same AS. However the RR is a BGP router which does not follow this rule and can cause potential routing loops. To avoid any situation where RR  can cause a routing loop, BGP defines two path attributes to be used for Route Reflectors.

1. ORIGINATOR_ID
2. CLUSTER_ID

1. ORIGINATOR_ID:
This is an optional non-transitive attribute. The ORIGINATOR_ID is the BGP Router ID of the originator of the route within the local AS. An RR does not advertise a route back to the originator of the same route, and even if it did the originator will ignore the update when it sees its own Router ID in the route update.

2. CLUSTER_ID
This is an optional non-transitive attribute used to track the cluster IDs in the same way as the AS_Path attribute tracks the AS numbers. Within each AS, there can be multiple Clusters and each cluster is identified by a unique 4-byte CLUSTER_ID.

If a Cluster has only one RR then the CLUSTER_ID is the Router ID of the RR. If a cluster has multiple RRs then each RR in the cluster has to be manually configured with a CLUSTER_ID.

Whenever an RR reflects a route from a client to a non-client it appends the cluster id to the CLUSTER_LIST. If the CLUSTER_LIST is empty then RR creates it.

When an RR receives a route update, it checks the CLUSTER_LIST, and if it sees its own Cluster ID in the Cluster List then it ignores the update since a routing loop has occurred.

RR Best Path Selection Decision Process.

RR uses the normal BGP rules to determine the best path when multiple routes to the same destination exist. Apart from the regular BGP best path selection decision rules, RR has to follow these 3 additional rules when making best path decisions.

1. If a route  is learnt from an IBGP Peer outside the cluster, then that route is reflected only to the clients inside the cluster.

2. If a route was learnt from a client then that route is reflected to all other clients in the cluster except the one which advertised it and it is also advertised to all non-clients (i.e., IBGP peers outside the cluster and/or EBGP Peers)

3. If a route was learnt from an EBGP peer then that route is advertised to all clients and non-clients.

Avoiding Single Point of failure:

Having only one RR in a cluster can create a single point of failure, if the router acting as an RR fails then the connectivity within the entire cluster is lost. To avoid this situation atleast 2 routers should be defined as RR in the cluster, and all clients should have physical connections to both the RRs and must peer with both the RRs. If one RR fails the clients in the cluster will still have a connection to the other RR and the connectivity will not be lost.

An AS can have multiple clusters and an RR in one of the Cluster can also be a client in another cluster of the same AS. Since the RR can form IBGP connection to  IBGP neighbor outside the cluster, this makes its possible for the RR to be a client in another cluster within the same AS.

 


Leave a Reply