In a previous post on BGP, we covered eBGP (inter-AS communication) and iBGP (intra-AS communication). We also mentioned how iBGP requires a full-mesh topology between all the BGP routers within an Autonomous System (AS) to achieve route reachability. In this post, we will review some of the issues that a full-mesh topology adds to the network, what is a BGP Route Reflector and how a BGP Route Reflector removes the need for a full-mesh topology.
As per the design of BGP, when forwarding route updates, a BGP router must add its own Autonomous System number (ASN) to the AS_Path attribute. If it sees its own ASN in the AS_Path list, a BGP router will drop a route to prevent the occurrence of routing loops.
The same action occurs if an iBGP router adds its own ASN and forwards a route it learned to another iBGP peer (all iBGP routers are located within the same AS). The peer router, upon seeing its own ASN in the route update, will assume a loop has occurred and drop the update.
To achieve loop avoidance and prevent iBGP routers from dropping routes with their own ASN, iBGP routers can be programmed not to advertise the external routes they learned to other iBGP peers. However, this affects route reachability, because the lack of routing updates means that a router that is at the second hop and further away will not receive all the eBGP routes.
To overcome this challenge, every iBGP router within an AS must be logically connected to every other iBGP router, resulting in what is known as a full-mesh topology.
Deploying iBGP full-mesh topology introduces two major problems. First, full-mesh iBGP in a large network can cause scalability issues. To exchange routing updates with all the other BGP routers in the full-mesh, each peering router uses up more CPU, memory, and bandwidth.
Second, adding a new iBGP router can be an issue, because network engineers must establish a connection to every other BGP router within the AS. This calls for configuration changes on backbone routers, which usually is a major reason for network downtime. This can be especially challenging in service provider networks that can have hundreds or even thousands of routers.
Let is look at what is a BGP Route Reflector. A Route Reflector (RR) is an iBGP feature that eliminates the need for a BGP full-mesh topology and allows iBGP to scale in large networks. The route reflector mechanism allows a BGP speaker (an iBGP router) to act as a route reflector that advertises (reflects) the routes it learns from one iBGP router to other iBGP peers within the AS.
The internal peers that connect to an RR are classified as RR client peers. Every other iBGP router that is not an RR or an RR client is classified as a non-client peer. An RR along with its client peers form a cluster. Each cluster can have multiple RRs which helps avoid a single point of failure and achieve redundancy. It is also possible to have multiple RRs within an AS where each RR is a non-client peer to another RR.
When an RR receives a route update from its iBGP peers, it selects the best path and follows one of the following rules depending on the type of peer that sent the route:
An RR also has mechanisms to detect and avoid loops. When a route is reflected by an RR to its clients, it adds two new BGP attributes to the route:
We hope this has given you insight into the basics of BGP Route Reflector. If you are ready to configure one in your network, here are some additional resources:
Finally, to ensure routing performance, prevent route leaks and route hijacks, and to make informed BGP peering decisions, you need to monitor your BGP routing. It is also important to gain visibility into route distribution details, including the distribution of routes from each RR client in the topology. Route distribution reports will help network engineers troubleshoot route reachability issues between Autonomous Systems, and this can be done using products that can monitor routing behavior in real time.
The “Network Basics by Packet Design” blog series covers the basics of various terminologies and technologies used by network operators and service providers, including routing, MPLS, Traffic Engineering, SDN, etc. Don’t forget to check out the other blogs in this series here.