In the previous article, we discussed the well-known communities in BGP including NO_EXPORT, NO_ADVERTISE and NO_EXPORT_SUBCONFED. We configured examples on how these communities affect routes. In this article, we will be looking at how to use communities to control routing policies in neighboring ASs.

Our diagram remains the same from the previous article as shown below:

To begin our discussion, let’s take a look at the configuration options available under the community attribute:

We have already discussed the well-known communities. The additive option is used to add a community attribute to the matched routes rather than replacing the community attributes they already have on them.

Our area of focus for this article will be the highlighted options in the screenshot above. Like I said in the last article, community attributes are 32-bit values and they can be represented in one of three forms: decimal, AA:NN or hexadecimal.

The AA:NN format

The RFC recommended format is the AA:NN format where the AA represents the AS number and the NN represents a number defined for different purposes by the AS. As a real example, visit this link to see the different community attributes defined by Time Warner Telecom.

According to those community definitions, if Time Warner receives routes from its customers with community attribute 4323:120, it will set the local preference of such routes to 120. In this case, “4323” is the AS number of Time Warner (representing the AA part) and “120” means that Time Warner will set the local preference of such routes to 120 (representing the NN part).

By default, Cisco IOS displays the community values in decimal so even if we type “4323:120”, the value will be displayed in decimal. Let’s look at an example:

Converting from decimal to AA:NN format

You may be curious to know how to convert from decimal to AA:NN format. Remember that communities are 32-bit values so the first thing we need to do is convert our decimal into binary and pad them up with zeros if they are not up to 32 bits.

Hint: Just use a Windows calculator for this.

283312248 = 1 0000 1110 0011 0000 0000 0111 1000 (29 bits)
283312248 = 0001 0000 1110 0011 0000 0000 0111 1000 (32 bits i.e. zero padding)

The next thing we will do is split it up into two halves of 16 bits each. The first half represents the AA and the second half represents the NN.

Finally, we just convert each 16-bit half to decimal and add a colon between the halves.

0001 0000 1110 0011 = 4323
0000 0000 0111 1000 = 120

To convert from AA:NN to decimal, you can just follow the steps in the backward direction. The hexadecimal format can also be converted using the same steps. No matter the format, the value of the community attribute is the same.

We can change the format displayed by the Cisco IOS using the ip bgp-community new-format global configuration command.

Using communities to control routing policies

Now that we have discussed the general formats of communities, let us see how we can use them to influence routing policies. By tagging routes with a particular community, we can take decisions based on the community values.

In the Time Warner BGP community link that we saw earlier, we will use one of the BGP community definitions for our example. Time Warner uses a default local preference of 115 for all its customer routes. Let’s say we want the R1-R2 link to be used as the primary link while the R1-R3 link is used only as a backup. What we can do is set routes sent through the R1-R2 link with a higher local preference (e.g. 120). We don’t have to do anything on the R1-R3 link because the default Time Warner local preference of 115 will apply to it.

Normally, the ISP (e.g. Time Warner) will have done the necessary configuration on their side; the customer only needs to set the appropriate communities on its own routes. However for this article, we will configure both parts. First, the configuration on one of the ISP routers (R2) is as follows:

ip community-list 1 permit 4323:120
!
route-map POLICIES permit 10
match community 1
set local-preference 120
route-map POLICIES permit 20
set local-preference 115
!
router bgp 4323
neighbor 192.168.12.1 route-map POLICIES in

The configuration on the second ISP router (R3) will also be similar except for the neighbor statement.

In the above configuration, I have used a community list to define the community values I want to match. The community list is similar to an ACL except that it is used to match community attributes. Next I match the community list under a route map and set the local preference for routes with that community to 120. Then, I set a local preference on all other (unmatched) routes to 115. Finally, I apply that route to customer R1 (I’m not interested in neighbor R4).

Now, let’s move over to the customer side. The configuration on R1 is as shown below:

route-map SET_COMM permit 10
set community 4323:120
!
router bgp 65501
neighbor 192.168.12.2 send-community
neighbor 192.168.12.2 route-map SET_COMM out

Now when we check the BGP tables of the ISP routers, we see that the best path to get to the customer network (10.10.10.0/24 route) is through the R1-R2 link.

We can further confirm that our configuration works by testing from R4. I will traceroute to 10.10.10.1 from R4. When everything is working well, the traffic will go through R2 and then to R1.

Note: For this to work, you can configure static default routes on R1 pointing to R2 (primary) and R3 (secondary) as follows:

To test the backup path, I will shut down the interface between R1 and R2. When we trace route from R4 to 10.10.10.1, it will go through R2 then R3 and finally R1.

Summary

This brings us to the end of this article and our discussion on BGP communities. We have seen how to use BGP communities to influence the routing decision in our neighboring ASs. We configured a real example using Time Warner Telecom’s guide for BGP communities.

I hope you have found this article insightful and I look forward to the next article in the series.

References and further reading

  1. Using BGP Community Values to Control Routing Policy in Upstream Provider Network: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/28784-bgp-community.html