What is Route Reflector ?

Route Reflector are used to solve the issue introduced by IBGP loop prevention. The loop prevention rule states that routes learn from and IBGP neighbor will not be advertised to other IBGP neighbors.

So if I learn a route from EBGP, I will pass it to my IBGP neighbors because I learned it from EBGP. But my IBGP neighbors will never pass this route to other IBGP neighbors in my AS.

 

One way to solve this issue is to have full mesh of IBGP neighbor. In my topology here is doable, a full mesh will only consist of a new IBGP peering between R1 and R2. But see it now from the standpoint of an ISP, there can be many Border Routers and this will multiply the need of IBGP neighborship, this is not scalable.

There is two ways to deal with this issue. This first is called Confederations and the other one, the one that matters here, the Route Reflectors.

What a Route Reflector do is to receive routes from its IBGP peers and reflect it to other IBGP peers. This also greatly increase the scalability of the solution because a full mesh is not needed anymore and by so the number of IBGP peering that are needed is reduced.

The rules for reflecting are as follow :

• A route received from a non-client peer will only be reflect to client
• A route received from a client will be reflect to clients and non-clients
• A route received by EBGP will be reflected to clients and non-clients

 

The configuration is pretty easy :

On R1 I have a simple configuration with IBGP by loopbacks and EBGP to R5 (which is the ISP router) :

<R1>dis cur sec bgp
[V200R003C00]
#
bgp 100
peer 3.3.3.3 as-number 100 
peer 3.3.3.3 connect-interface LoopBack0
peer 15.15.15.5 as-number 500 
#
ipv4-family unicast
  undo synchronization
  peer 3.3.3.3 enable
  peer 3.3.3.3 next-hop-local 
  peer 15.15.15.5 enable
#

On R2 the configuration is the same :

<R2>dis cur sec bgp
[V200R003C00]
#
bgp 100
peer 3.3.3.3 as-number 100 
peer 3.3.3.3 connect-interface LoopBack0
peer 26.26.26.6 as-number 600 
#
ipv4-family unicast
  undo synchronization
  peer 3.3.3.3 enable
  peer 3.3.3.3 next-hop-local 
  peer 26.26.26.6 enable
#

 

I am receiving a route from R5 on R1. So this is an EBGP route from R1 standpoint :

[R1]dis bgp routing-table

BGP Local router ID is 1.1.1.1 
Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete

Total Number of Routes: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

*>   7.7.7.0/24         15.15.15.5                            0      500 700i
*>   77.77.77.0/24      15.15.15.5                            0      500 700i

 

Right now the configuration of R3 is just the same as R1/R2, a reverse configuration to build the IBGP peering. The only difference is that it’s configured inside a peer-group, a peer-group is just a container on which you apply configurations and these configurations are applied to every peer in that container :

<R3>dis cur sec bgp
[V200R003C00]
#
bgp 100
group IBGP internal
peer IBGP connect-interface LoopBack0
peer 1.1.1.1 as-number 100 
peer 1.1.1.1 group IBGP 
peer 2.2.2.2 as-number 100 
peer 2.2.2.2 group IBGP 
#
ipv4-family unicast
  undo synchronization
  peer IBGP enable
  peer 1.1.1.1 enable
  peer 1.1.1.1 group IBGP 
  peer 2.2.2.2 enable
  peer 2.2.2.2 group IBGP 
#

If we take a look at the BGP routing table of R3 we should see the route 7.7.7.0/24 and 77.77.77.0/24 :

<R2>dis cur sec bgp
[V200R003C00]
#
bgp 100
peer 3.3.3.3 as-number 100 
peer 3.3.3.3 connect-interface LoopBack0
peer 26.26.26.6 as-number 600 
#
ipv4-family unicast
  undo synchronization
  peer 3.3.3.3 enable
  peer 3.3.3.3 next-hop-local 
  peer 26.26.26.6 enable
#

But do we see it on R2 ?

<R2>dis bgp routing
<R2>

Nope, no route on R2. The reason why is because R3 learned the route from R1 so the route was learn from IBGP and will not be passed to other IBGP neighbor.

If I build a peering between R1 and R2, R2 will get the route because it will now be an EBGP route passed down to an IBGP peer. But this is not want we want to do, let’s configure a Route Reflector on R3 so that it reflects the routes !

[R3-bgp]peer IBGP reflect-client

This is that simple ! I apply it to my peer group but you can apply to individual peers if you want :

Now let’s take a look at the result on R2 :

<R2>dis bgp routing

BGP Local router ID is 2.2.2.2 
Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete

Total Number of Routes: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

*>i  7.7.7.0/24         1.1.1.1                    100        0      500 700i
*>i  77.77.77.0/24      1.1.1.1                    100        0      500 700i

So now as the routes have been learned from a route reflector client, R3 will forward it to other route reflector client.

Redundancy

So now the Route Reflector become a  critical piece of the environment, if it fails we can lose a lost a BGP information and not be able to maintain the routing. This is why we need to have at least a pair of Route Reflectors to ensure redundancy.

Let’s take a scenario :

The dotted lines represent an IBGP peering.

We have a peering from each border router (R1 and R2) to each Route Reflector to ensure redundancy  and we have an IBGP peering between RR1 and RR2. An IBGP peering between two Route Reflectors can be needed for various reasons, one possible reason is when multiple route reflector are created for dispersed geographical location.

For example I can have a set of BGP routers that are located in the US and use a pair if Route Reflector on that geographical location, I can then have another set of BGP routers that are located in Europe that use another pair Route Reflector. This allows to scale a large BGP network like this :

As Route Reflection can be hierarchical, if many regions need to be connected, it’s still possible to add another level of Route Reflector that will have the task to aggregate all the Route Reflectors. Now the issue we can run into the issue where a Route Reflector will reflect  a route to another Route Reflector deserving the same set of client, and here we could run into a loop.

The way to overcome this is the use of CLUSTER_ID.

The CLUSTER_ID is an optional non-transitive attribute that can be used for BGP to determine the source of the BGP update. By default a Route Reflector use its own BGP Router ID as CLUSTER_ID. What the CLUSTER_ID do is determine from which cluster of Router Reflector the update are coming from so that if one of the Route Reflector receives an update that comes from its own cluster, it will discard it.