In the last two articles in this BGP series, we discussed route aggregation and somewhere in those articles, we used BGP communities. I promised that we will have an article dedicated to BGP communities and that is what we will be discussing in this article.

We will use the network diagram shown below:

The COMMUNITIES BGP path attribute is an optional transitive attribute made up of 32 bits. It is used to group routes that share a common property. There are a couple of well-known communities defined in BGP such as those defined in RFC 1997 as follows:

  1. NO_EXPORT (0xFFFFFF01): A BGP speaker that receives a route containing this community value must not advertise that route to its external BGP peers; it can be advertised to IBGP peers. It can also be advertised to confederation peers in other member ASs inside its local confederation.
  2. NO_ADVERTISE (0xFFFFFF02): A BGP speaker that receives a route containing this community value must not advertise that route to any peer, external or internal.
  3. NO_EXPORT_SUBCONFED (0xFFFFFF03): A BGP speaker that receives a route containing this community value must not advertise that route to any external peer including peers in other member ASs inside its confederation. In other words, the route must be kept inside the local member AS of a confederation.

Hint: Cisco also defines internet as a well-known community attribute. Moreover, Cisco uses the “local-AS” option to identify the NO_EXPORT_SUBCONFED community.

Let’s take a couple of examples to see how these communities affect routes. You can download the GNS files including initial and final configurations from here. The files are split into two folders: one for the first 2 examples and the 2nd folder contains the GNS3 files for the 3rd example.

Example 1: NO_EXPORT community attribute

Our configuration will be from the perspective of AS65501 as the customer having AS4323 as its ISP. AS4323 in turn peers with AS65504. We have normal BGP sessions between our routers (i.e. R1 forming EBGP sessions with R2 and R3); R2 and R3 have an IBGP session between themselves; and R2 and R4 have an EBGP session between themselves. Also, R1 is advertising the 10.10.10.0/24 route into BGP. Currently, all other routers know about this route as shown below:

Now let’s assume that for some reason, the customer (AS65501) doesn’t want its ISP to advertise the 10.10.10.0/24 to other neighbors (i.e. AS4323 should not advertise that route to its EBGP peers). We can use the NO_EXPORT community to achieve this. The configuration on R1 is as follows:

access-list 100 permit ip host 10.10.10.0 host 255.255.255.0
!
route-map SET_COMM permit 10
match ip address 100
set community no-export
!
route-map SET_COMM permit 20
!
router bgp 65501
neighbor 192.168.12.2 send-community
neighbor 192.168.12.2 route-map SET_COMM out
neighbor 192.168.13.3 send-community
neighbor 192.168.13.3 route-map SET_COMM out

There are two things I want to highlight in this configuration. The first is that I have used a weird access-list. Normally, I use prefix-lists because it is just easier to match routes (prefix/prefix-length). The reason I have written an access-list such as this is because I want it to match only that route. If I had used a standard access-list like access-list 1 permit 10.10.10.0 0.0.0.255, I will match not only the 10.10.10.0/24 prefix but also routes like 10.10.10.0/25, 10.10.10.0/26 and so on. This is because the standard access-list cannot check the length of a prefix. Therefore the format to match prefix/prefix-mask using an extended ACL is: access-list [permit | deny] ip host host . In summary, if you are not restricted by a question, I will just use a prefix-list.

The second thing I want to point out is the “neighbor send-community” command that I have used for both neighbors R2 and R3. The reason is because, by default, community attributes are not sent to BGP neighbors.

Note: You should also configure R2 and R3 to send community attributes between each other. If this is not done and the link between R1 and R3 goes down for example, R3 will use R2 as its next hop to reach that route. With the NO_EXPORT community attribute advertised by R2 to R3, R3 will advertise that route to its EBGP neighbors.

The other part of the configuration should be familiar: I have created a route map called SET_COMM to set the NO_EXPORT community on the 10.10.10.0/24 route. I have then applied this route map to updates sent to both R2 and R3.

Let’s view one of the BGP UPDATE messages sent to R2 so we can see the COMMUNITIES attribute:

To see the effect of our configuration, we will check that the 10.10.10.0/24 is still advertised to both R2 and R3 (and also between R2 and R3).

However, if we were to check R4, we will discover that the 10.10.10.0/24 route is no more advertised to it; thus our goal is achieved:

Example 2: NO_ADVERTISE community attribute

The next example we will consider is the NO_ADVERTISE community attribute. Like we said above, not only will this prevent the route from being advertised to EBGP peers; it will also prevent the route from being advertised to IBGP peers.

Let’s change our route map to use the “no-advertise” community instead of the “no-export” that is currently there.

route-map SET_COMM per 10
no set community no-export
set community no-advertise

The effect of this configuration is that R2 will not send the 10.10.10.0/24 to R3 and vice versa. Therefore, if we look at the BGP table of those routers, we see only one path each (as opposed to two paths that we had before now).

Example 3: NO_EXPORT_SUBCONFED community attribute

For this example, we will use a different network diagram as shown below:

Before our configuration, we can confirm that all other routers know about the 10.10.10.0/24 route via BGP:

Now, let’s consider the difference between the NO_EXPORT and NO_EXPORT_SUBCONFED community attributes in a BGP confederation. First, we will configure R1 to attach the NO_EXPORT community attribute to the 10.10.10.0/24 route sent to R2.

access-list 100 permit ip host 10.10.10.0 host 255.255.255.0
!
route-map SET_COMM permit 10
match ip address 100
set community no-export
!
route-map SET_COMM permit 20
!
router bgp 65501
neighbor 192.168.12.2 send-community
neighbor 192.168.12.2 route-map SET_COMM out

If we were to look at the BGP tables of the other routers, we see that the route is only missing on R5; R2 still advertises it to R3 and R4.

Therefore with the NO_EXPORT community attribute, all routers within a confederation (even in different member ASs) are not affected.

The second scenario is to configure R1 to attach the “local-AS” community attribute to the 10.10.10.0/24 route sent to R2. The configuration change is as follows:

route-map SET_COMM permit 10
no set community no-export
set community local-AS

When we look at the other routers’ BGP tables now, we discover that R2 advertises that route only to R4 because R4 is part of its local member AS. Since R3 is not in the same member AS, the route is not advertised to R3, even though they are in the same confederation.

Summary

In this article, we have discussed the well-known communities in BGP including the NO_EXPORT, NO_ADVERTISE and NO_EXPORT_SUBCONFED community attributes. The first one prevents a route from being advertised to EBGP peers; the second one prevents a route from being advertised to any peer at all; while the third one prevents a route from being advertised to EBGP peers including confederation EBGP peers.

In the next article, we will look at how to use communities to implement routing policies. I hope you have enjoyed this article and I look forward to the next one in the series.

References and further reading