Load Balancing using BGP Communities

In this post we will look at how we can achieve load-balancing using the BGP communities. 

Community values are similar to the "tag" we use in IGP. They are used to group the prefixes. When the neighbour receives the prefixes, it will examine the community value and take an action such as filtering or modifying the BGP attributes.

We are going to use the below topology for our experiment.

As we can see, there are four routers which are in different BGP AS numbers. All of them have EBGP neighborship with it's directly connected router.
R1 is advertising two prefixes i.e. 1.1.1.0/24 and 11.11.11.0/24 into the BGP process.

The BGP table of R4 shows that it has learned both the prefixes from R2 and R3.

At the moment R4 is prefers the paths learned through R3 as they were received first (oldest route).

If I want R4 to prefer the the link to R2 then I may advertise these prefixes with AS_Prepend from R3. However in real world, it will guarantee that R4 will use R2 to reach the prefixes.

Generally service providers have route-map configured on their devices which applies various local preference to the routes based on the community values received with them. (e.g. http://www.onesc.net/communities/as7018/)

In our example, let's create a policy on R4 which says that if it receives a prefix with community 40:100 then it will assign the local preference 100 to that route otherwise by default it will assign local preference 10 to any other route.

To configure this policy, first of all we have to create a community-list which matches the community value. The name of the list is "LOCAL_PREF_100" and it matches the community value "40:100". You can even specify the community number in decimal format (1-4294967295) however the new format aa:nn looks neat. 

Now we will configure a route-map which matches this list and assigns the local preference 100.

We have created a second entry matching the remaining routes which assign the local pref 10.

This route-map will be applied on the both the neighbours inbound.

Now let's say we want R4 to prefer the link toward R2 for the prefix 1.1.1.0/24 and link towards R3 for the prefix 11.11.11.0/24.

On R1, let's configure two prefix lists matching loopback subnets.

We will configure two route-maps that match the prefix-list and assign a community value. 

If we do show route-map, we can see that the community values is in decimal.

The value 2621540 in decimal is the same as 40:100 in the new format. To view this in new format, we have to apply the command "ip bgp-community new-format". 

We can see that now the route-map shows the community value in new-format. 

I have applied this command on all the routers.

The relevant route-map will now be applied to the neighbor R2 and R3.

After resetting the neighborship, we still can't see the community value on either R2 or R3.

By default BGP neighbour's do not exchange community values. We have to apply the command "send-community" under the BGP process for each neighbor to send the community value.

We need to do the same on R2 and R3 as well. Once the command has be configured, R2 and R3 can see the community with the prefix.

Now if we look at the BGP table on R4, we can see that it has assigned the local preference based on the community value.

Couple of things to remember while dealing with BGP communities,

i. BGP neighbors do not exchange communities by default, you have to apply the command "neighbor x.x.x.x send-community".

ii. To set the community, you will have to use the community "value" in the route-map but when you match the community, you will have to configure a "community-list" and match that list under the route-map.