BGP Route Reflectors

Within BGP there are two common ways to build a BGP network.

  • Full Mesh
  • With a BGP Route Reflector

The end goal is that each of the routers in your network has the prefixes from the other routers in the same topology \ business \ area, etc. Depending on the environment and the requirements you may choose to go with a full mesh design. With this, each router has a BGP neighbor configuration for each other router it will want to receive advertisements from and peer with. Think of how large this could be in an environment with a lot of routers. This could easily become a very complex network. Not that there is anything wrong with that, but it may be overkill depending on your situation. The solution to this would be to use BGP route reflectors.

What are BGP Route Reflectors?

BGP route reflectors are just what they sound like, they are devices that receive and reflect back out network advertisements. This eliminates the need to have a full mesh environment. Instead, each router would just need to peer with the BGP route reflector. The advertisements that the route reflector received would then be advertised back out to its other peers.

In terms of an example, you may have a case where you have 4 routers in a full mesh environment. It may look a bit like this:

Each router has a connection to each other router and would use that link for each BGP peer connection. In this case, you have a lot more connections to manage, but if a router goes down, the other three function with no issues.

The way BGP route reflectors could help this topology is by reducing the number of connections. Your configs would also become a lot shorter too. Let’s say that router “iosv-4” is our route reflector. Your topology would now look like this:

Quite a few less links to manage in this topology. That being the case though, a LOT is riding on router “iosv-4”. If that were to go down, the other three routers would be missing their advertisements. That is why having multiple route-reflectors is recommended. Understandably, they are very important because of how the other routers rely on them for all of the other advertisements. a second BGP route reflector would add the redundancy in the event of a device or link failure.

Basic BGP Route Reflector Configuration

Here is what our topology will look like for this demonstration. VIRL lab available for download below.

In terms of configuration, there is not much to it. The process, when outlined, looks like this:

  • Configure desired IP scheme
  • Establish BGP peering with route reflector router (router 2 in our case here) from each client router
  • Designate client routers as a route reflector clients.

Let’s get to it. We will be working with the AS number 65000 for all three routers. I will peer routers 1 and 3 with router 2. Nothing special about this configuration on each router, standard BGP peering with loopbacks:

iosv-1(config)#router bgp 65000
iosv-1(config-router)#neighbor 2.2.2.2 remote-as 65000
iosv-1(config-router)#neighbor 2.2.2.2 update-source lo0

Next I created an additional loopback on routers 1 and 3. This is our hypothetical network that each will be advertising. I used 192.168.1.0/24 and 192.168.3.0/24 respectively. After creating them, I advertised them both through BGP:
Router 1

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
router bgp 65000
 network 192.168.1.0

And then Router 3

interface Loopback1
 ip address 192.168.3.1 255.255.255.0
router bgp 65000
 network 192.168.3.0

The issue though is that router 1 does not know about router 3s network and vice versa. On router 1 for instance, there is no mention of router 3s network in a “show ip bgp”:

iosv-1#sh ip bgp
BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      0.0.0.0                  0         32768 i
iosv-1#

We can verify that both routers are advertising their network prefix correctly with a “show ip bgp” on router 2 which is peered with both of them:

iosv-2#sh ip bgp
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 192.168.1.0      1.1.1.1                  0    100      0 i
 *>i 192.168.3.0      3.3.3.3                  0    100      0 i
iosv-2#

This is where the need for a BGP route reflector comes in. Next we will configure router 2 as a BGP route reflector. Very easy config for a basic topology like this. All we need is one more neighbor statement for each client router:

iosv-2(config)#router bgp 65000
iosv-2(config-router)#neighbor 1.1.1.1 route-reflector-client
iosv-2(config-router)#neighbor 3.3.3.3 route-reflector-client

If we go ahead and run that “show ip bgp” on router 1 again, we should get some better looking results…

iosv-1#sh ip bgp
BGP table version is 6, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      0.0.0.0                  0         32768 i
 *>i 192.168.3.0      3.3.3.3                  0    100      0 i
iosv-1#

There it is. That’s all there was to it. Routers 1 and 3 can now share network prefixes to two routers each while only needing a single link to do it. Obviously this is a VERY basic lab and example of how this works. As mentioned earlier, I would recommend that if you are going the route of using a BGP route reflector that you use at least 2 of them (depending on the size of your topology. Using a single route reflector adds a single point of failure. A simple link or device failure would cause major network issues.

Otherwise, pretty straight forward. To see the lab in action, download my VIRL topology below!

 

 

 

Facebooktwittergoogle_plusredditpinterestlinkedintumblrmail
Kevin

Kevin

Cisco CCNP, Senior Network Engineer in the Healthcare Industry. Currently working on my CCIE R&S which is the focus of most of my latest blog posts. #NFD15 Delegate.

Leave a Reply

Your email address will not be published. Required fields are marked *