fir3net

PPS-Firenetbanner-780.5x190-30-03-17

What is a BGP Route Reflector?

Contents[Hide]

The Full Mesh Problem

Due to the BGP split horizon rule (within iBGP) all iBGP peers within an AS must be fully meshed. Why may you ask?

Whereas eBGP uses the AS-PATH for loop avoidance, iBGP neighbors do not add their ASN to the AS_PATH when sending updates. So what does iBGP use for loop prevention? Split horizon. The rule of iBGP split horizon states:

“Any routes learned from an iBGP neighbor must never be advertised to any other iBGP neighbor.”

image3

Figure 1 - BGP Split Horizon.

This, of course, presents complexity and scalability issues to both the BGP routers and the network due to the number of unique BGP sessions required.

For example, The total number of unique BGP sessions required within the AS can be calculated using the following, where n = BGP speakers within AS: n*(n-1)/2 i.e 10 BGP routers would require 45 BGP sessions in order to be fully meshed.

image4

Figure 2 - Full mesh peering.

Route Reflection

One solution to reduce the number of BGP peerings within an AS is route reflection. Rather than each BGP system having to peer with every other BGP system with the AS, each BGP speaker instead peers with a router reflector. Routing advertisements sent to the route reflector are then reflected out to all of the other BGP speakers.

image2

Figure 3 - Reduced iBGP sessions.

The route reflector reflects routes considered as best only. Additionally, a route reflector is NOT allowed to change any attribute of the reflected route including the next-hop attribute.

Peer Types

The are two types of internal peers to a route reflector - Client and Non-ClientLet's look at the differences:

Note: A cluster is just a collection of Router Reflectors and Router Reflector clients.

Peer TypeFull MeshCluster

RR Operation

Client (RR Client) Not Required With other clients and RR to form a cluster A route from a client peer is reflected to all the non-client peers and client peers (Figure 4)
Non-Client (Regular iBGP) Required Sits outside of the cluster A route from a non-client iBGP peer reflect to all the clients (Figure 4)

Furthermore, and to summarize the above: ONLY the route reflector is aware of who is a client and who is a non-client. To the route reflector, the non-client is simply just another iBGP peer. Because of this, the route reflector must adhere to the BGP split horizon rule, hence routes from a non-client are only reflected to clients.

image1

Figure 4 - Client vs Non-Client.

Routing Information Loops

Let's look at the three BGP attributes used to prevent routing information loops when using route reflectors.

  • CLUSTER_IDTo prevent a route reflector being a single point of failover multiple RRs can be configured. However, this presents a potential issue around advertisement loops between RRs. In order to have multiple RRs within the same cluster, all RRs in the same cluster can be configured with a 4-byte CLUSTER_ID so that an RR can discard routes from other RRs in the same cluster. [1]
  • CLUSTER_LIST -  But what if what our RR to be part of multiple clusters? In this case, the RR will use different CLUSTER_IDs for the relevant RR neighbors and appended its CLUSTER_ID to the CLUSTER_LIST attribute. When the RR receives an UPDATE that contains the router's own CLUSTER_ID within the CLUSTER_LIST, the UPDATE is discarded.  [2]
  • ORIGINATOR_ID - When the route reflector reflects a path it assigns router ID of the advertising router using the ORIGINATOR_ID attribute. If any router then receives an UPDATE that includes a path that contains an ORIGINATOR_ID matching its own router ID, the UPDATE is ignored.

Configuration

The configuration to define a router reflector is extremely simple. Note: Below is based on Cisco IOS. 

Configure RR Client 

R1(config)# router bgp 65001
R1(config)#  ...
R1(config)#  neighbor 3.3.3.3 route-reflector-client 

Verify

R1# show ip bgp 150.1.1.0/24
BGP routing table entry for 150.1.1.0/24, version 10
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     20         21         22        
  Refresh Epoch 2
  64512, (Received from a RR-client)
    150.0.0.17 (metric 2) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

References

[1] "RFC 4456 - BGP Route Reflection: An Alternative to Full ... - IETF Tools." https://tools.ietf.org/html/rfc4456 . Accessed 15 Nov. 2017.
[2] "BGP Route Reflection and Multiple Cluster IDs - Cisco." 14 Sep. 2015, https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/200153-BGP-Route-Reflection-and-Multiple-Cluste.html . Accessed 15 Nov. 2017.

Tags: eBGP, iBGP