Categories R&S

BGP – implement and troubleshoot Scalability – Route-Reflector Clusters

Route reflector are mainly used in large iBGP deployment.

It removes the needs of full mesh peering.

 

There is some important rules to remember when deploying BGP cluster:

  • A route from an external BGP speaker is advertised to all clients and nonclient peers.
  • A route from a nonclient peer is advertised to all clients.
  • A route from a client is advertised to all clients and nonclient peers. Hence, the clients need not be fully meshed.

 

Requirements:

Create two route-reflector cluster with R1 and R2.

R5 and R6 will be client of R1 and R3 and R4 will be client of R2.

 

Reestablish the eBGP session between R6 and R10  and R3 to R20.

 

Diagram:

route-reflector

 

Configuration and verification:

Let’s start with the peering between R1 and R2.

Because they are in two different cluster, they must be route-reflector client each other.

R1(config)#router bgp 100
R1(config-router)#bgp cluster-id 1.1.1.1
R1(config-router)#neighbor 10.100.10.2 remote-as 100
R1(config-router)#neighbor 10.100.10.2 route-reflector-client

R2(config)#router bgp 100
R2(config-router)#bgp cluster-id 2.2.2.2
R2(config-router)#neighbor 10.100.10.1 remote-as 100
R2(config-router)#neighbor 10.100.10.1 route-reflector-client

 

Now, the peering on R1 to R5 and R6.

R1(config-router)#neighbor 10.100.10.50 remote-as 100
R1(config-router)#neighbor 10.100.10.50 route-reflector-client
R1(config-router)#neigh 10.100.10.66 remote-as 100
R1(config-router)#neigh 10.100.10.66 route-reflector-client

R5(config-router)#neigh 10.100.10.65 remote-as 100

R6(config-router)#neigh 10.100.10.65 remote-as 100

 

Then we do the same for the peering on R2 to R3 and R4.

 

Let’s have a look on the router received on R5.

R5#sh ip bgp
BGP table version is 6, local router ID is 10.100.1.5
SNIP

     Network          Next Hop            Metric LocPrf Weight Path
 *>i 10.100.1.1/32    10.100.10.49             0    100      0 ?
 *>i 10.100.1.2/32    10.100.10.2              0    100      0 ?
 *>i 10.100.1.3/32    10.100.10.18             0    100      0 ?
 *>  10.100.1.5/32    0.0.0.0                  0         32768 ?
 *>i 10.100.1.6/32    10.100.10.66             0    100      0 ?

 

So R5 is receiving the update from all the loopbacks.

If we check the details of the prefix received from R6 (in the same cluster ID), we can see the originator with the cluster ID.

R5#sh ip bgp 10.100.1.6 255.255.255.255
BGP routing table entry for 10.100.1.6/32, version 3
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.100.10.66 (metric 20) from 10.100.10.49 (10.100.1.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Originator: 10.100.1.6, Cluster list: 1.1.1.1
      rx pathid: 0, tx pathid: 0x0

 

If we compare to the prefix received from R3:

R5#sh ip bgp 10.100.1.3
BGP routing table entry for 10.100.1.3/32, version 6
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.100.10.18 (metric 30) from 10.100.10.49 (10.100.1.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Originator: 10.100.1.3, Cluster list: 1.1.1.1, 2.2.2.2
      rx pathid: 0, tx pathid: 0x0

 

We see here the two cluster ID references.

Now, let’s reconfigure the eBGP peering between R6 and R10  and R3 and R20.

R10#sh ip bgp sum
BGP router identifier 10.10.1.10, local AS number 10
SNIP
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.10.0    4          100       8       5       19    0    0 00:00:45        7

R20#SH IP BGP SUM
BGP router identifier 10.20.1.20, local AS number 20
SNIP
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.20.0    4          100       8       6       31    0    0 00:01:37        7

 

We can see on R5 that we learned correctly all the prefixes.

R5#sh ip bgp
BGP table version is 13, local router ID is 10.100.1.5
SNIP
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 10.10.1.10/32    10.100.10.66             0    100      0 10 i
 *>i 10.20.1.20/32    10.100.10.18             0    100      0 20 i
 *>i 10.100.1.1/32    10.100.10.49             0    100      0 ?
 *>i 10.100.1.2/32    10.100.10.2              0    100      0 ?
 *>i 10.100.1.3/32    10.100.10.18             0    100      0 ?
 *>i 10.100.1.4/32    10.100.10.34             0    100      0 ?
 *>  10.100.1.5/32    0.0.0.0                  0         32768 ?
 *>i 10.100.1.6/32    10.100.10.66             0    100      0 ?

 

That’s all for BGP route-reflector.

 

Please note that this post is only there to present BGP route-reflector cluster.

BGP route-reflector and BGP route-reflector cluster design and configuration can become really complicated when it comes to large BGP network.

 

Usually in large network, you may want to avoid RR to be in the transit path, RR routers should only serve the purpose of “reflecting” routes.

 

 

 

Thank you for reading.

 

 

 

BGP – implement and troubleshoot Scalability – Route Reflector Clusters