Table of Contents

Network Design Fundamentals Course

02:28:37 Hours
17 Lectures


BGP Training

22:46:48 Hours
22 Lectures


Cisco CCIE Service Provider Training

96:02:27 Hours
242 Lectures


BGP Optimal Route Reflection – BGP ORR

BGP Optimal Route Reflection provides Optimal Routing for the Route Reflector Clients without sending all available paths.

I recommend you to read this post if you don't know about BGP Route Reflector.

If you are reading this post, you probably know that BGP Route Reflector by default choses and advertise only best path to their clients, from their point of view. If higher level BGP attributes are the same for two paths (Longest match, Local pref, Origin, MED etc.) BGP Route Reflector chooses the best path based on IGP cost. Shortest cumulative IGP distance path is selected as best path and advertised to the RR Clients.

When RR advertises the best path to the clients in this way, it can lead to suboptimal routing for the clients.

Let's understand the suboptimal routing as well briefly. Sub optimality in almost all books which you read is considered as a cumulative IGP cost from source to destination.

It is not based on delay, monetary cost, fiber mile distance, reliability of the path etc. Just based on shortest total/cumulative cost.

Optimal Route Reflection is a IETF Draft but there are many vendor implementation as of 2019

Based on this solution, the RR will do the optimal path selection based on each client's point of view. It runs SPF calculation with their clients as the root of the tree and calculates the cost to the BGP next-hop based on this view.

With ORR Route Reflectors location would be independent from the selection process of the best-path. Each ingress BGP border router can have a different exit point to the transit providers, for the same prefix.

What does BGP ORR (Optimal Route Reflection) Achieve?

Let's have a look at below topology to understand what BGP Optimal Route Reflection achieves.

BGP Optimal Route Reflection

In the picture above, Blue, Green and Orange links are physical connections and dashed black lines are IBGP sessions. Numbers are representing the IGP cost from each device to the BGP next hops.

Same BGP prefix is received from IGW1, IGW2 and IGW3 and advertised to RR. As you can see, RR chooses IGW3 due to shortest IGP cost and advertises to all PE devices, which are RR Clients.

IGW3 is the shortest path only for PE3 as PE3 shortest path would choose IGW3 as the best path.

IGW3 is not the best path for PE1 and PE2.

With BGP Optimal Route Reflection, RR advertises IGW1 to PE1 , IGW2 to PE2, IGW3 to PE3 as the best path.

Not IGW3 for all the PE devices.

By sending only one path, RR provides Optimal Routing (Remember how we defined optimal routing above?)

Without BGP Optimal Route Reflection, RR needs to advertise all three IGW to all PE devices, in turn, PE devices can calculate their shortest path to the BGP destinations.

Obviously this can create resource issue on the PE devices. But would be only way to provide Optimal Routing to the clients.

With BGP ORR, you can think that, processing requirement is moved from the RR Clients to RR itself. It doesn't only hold all necessary prefixes with multiple next-hops, but also needs to run SPF from each client point of view to calculate and advertise shortest path per client.

BGP ORR Requirements:

Link-state routing protocol is required in the network for the Route Reflectors to have a complete view of the network topology based on the IGP perspective. No changes are required to be done by the clients.

ORR is applicable only when BGP path selection algorithm is based on IGP metric to BGP next hop, so the path will be the lowest metric for getting the Internet traffic out of the network as soon as possible

How BGP ORR Works:

With ORR, 1st step, the topology data is acquired via ISIS, OSPF, or BGP-LS. The Route Reflector will then have the entire IGP Topology, so it can run its own computations (SPF) with the client as the root. There could be as many rSPF(Reverse SPF) run based on the number of RR clients, which can increase the CPU load on the RR.

So, a separate RIB for each of the clients/groups of clients is kept by the RR. BGP NLRI and next-hop changes trigger ORR SPF calculations. Based on each next-hop change, the SPF calculation is triggered on the Route Reflector.

The Route Reflectors should have complete IGP view of the network topology for ORR, so a link-state routing protocol is required to be used in the network. OSPF/IS-IS can be used to build the IGP topology information.

IGP is great for link state distribution within a routing domain or an autonomous system but for link state distribution across routing domains EGP is required. BGP-LS provides such capability at high scale by carrying the link state information from IGP protocols as part of BGP protocol messages.

Route Reflectors keeps track of which route it has sent to each client, so it can resend a new route based on changes in the network topology (BGP/IGP changes reachability). The Route Reflector function is 1 process per route but the ORR function is 1 process per route per client router.

ORR brings the flexibility to place the Route Reflector anywhere in the topology, which provides Hot Potato Routing, supports resiliency via ORR Groups, requires no support from clients and finally brings much better output when is used with BGP ADD-PATH.

If you liked this post and would like to see more, please let me know in the comment section below. Share your thoughts so I can continue to write similar ones.

Created by
Orhan Ergun

Orhan Ergun, CCIE/CCDE Trainer, Author of Many Networking Books, Network Design Advisor, and Cisco Champion 2019/2020/2021

He created OrhanErgun.Net 10 years ago and has been serving the IT industry with his renowned and awarded training.

Wrote many books, mostly on Network Design, joined many IETF RFCs, gave Public talks at many Forums, and mentored thousands of his students.  

Today, with his carefully selected instructors, OrhanErgun.Net is providing IT courses to tens of thousands of IT engineers. 

View profile