Packet Design is now part of      Learn More

Network Basics by Packet Design: What is a BGP Route Reflector?

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.

iBGP Loop Avoidance

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.

Partial and Full-Mesh Topology

Partial and Full-Mesh Topology

iBGP Full-Mesh Topology Problem

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.

Achieving iBGP Scalability with BGP Route Reflectors

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.

What is a BGP Route Reflector

What is a BGP Route Reflector

How a Route Reflector Works

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:

  1. EBGP Peer: The best routes are propagated to all BGP peers including other RRs, client peers, and non-client peers.
  2. Non-client Peer: The best routes are reflected to all the client peers as well as to the eBGP peers.
  3. Client Peer: The best routes are reflected to all non-client peers as well as to the client peers.

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:

  1. Originator ID: This is the Router ID of the originator of the route. When a route update is sent back to its originator based on the above rule, it ignores the update.
  2. Cluster List: This is the list of clusters that an update has traversed. When an RR sends a route it received from a client peer to a non-client peer, it adds its local cluster ID to the Cluster List. If the RR then receives a route update with its own Cluster ID in the Cluster List, the update is ignored.

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:

BGP Route Reflector by Ivan Pepelnjak

BGP Route Reflector Design Issues

Route Reflector Configuration on Cisco Devices

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.

More Resources | Request a Personalized Demo