BGP Communities

BGP communities can be summarized as a set of tags that can be used to further classify BGP prefixes.  That might not be a ‘RFC’ definition, but in my mind, that’s truly what they are.  Boiled down further, BGP communities are 32 bit values which are sometimes referred to in 4 octet values.  In IOS you can define communities in two manners.  The first is the standard 32 bit number format.  The second is a 32 bit value broken into two 16 bit sub values.  This second method is referred to as the ‘new-format’.  It is recommended that the first 16 bit number be used to identify the AS that originated the community and the second 16 bit number be defined as some unique value. 

It is possible (with proper configuration) to apply multiple community strings to the same BGP update or prefix.  In addition to user defined communities, there are several ‘well known’ community values.  These include…

NO-EXPORT – This community implies that the BGP prefix should not be advertised to other eBGP peers.

NO-ADVERTISE – This community implies that the BGP prefix should not be advertised to any other BGP peer (iBGP or eBGP)

LOCAL-AS – This community implies that the BGP update should not be advertised outside of the local AS. 

Note: You might be wondering what the difference is between the NO-EXPORT and the LOCAL-AS option as they appear to accomplish the same thing.  The difference boils down to confederations.  NO-EXPORT when used with confederations will keep the prefix within the confederation but not share it externally.  LOCAL-AS will prevent the route from even going to confederation peers.

So let’s start with a basic lab and go from there…

Now let’s create some dummy routes on router1 to play with and redistribute them into BGP…

As you can see, the prefixes are being advertised through the chain of routers into router4’s IP routing table…

Let’s first play around with the well known BGP communities to make sure they work as expected…

The first thing we do is create a prefix list since we only want to apply the community to a certain prefix.  Next, we create a route-map and tell it to match the prefix list we created, and set the LOCAL-AS community based on the match.  Finally we clear the BGP neighbors to make the changes go into effect.  Looking at router2 we see the following routes…

As you can see, router2 is only receiving the 10.10.10.0/24 prefix.  Do you know why that is?  When we configured the route-map on router1, we didn’t create a match-all route-map entry to allow other prefixes to go through after the initial sequence 10 match.  That means that only the prefixes that match sequence 10 will get sent to the peer.  We’ll fix that in a second, but let’s see if we got the community in the prefix we did receive…

It doesn’t appear that we have a community on the prefix.  We must have made another mistake.  One of the configuration items you need to make when using communities is to tell the BGP peer to send communities.  Let’s fix that issue first and verify…

Looking back at router2 we can see that the community is now attached to the prefix…

Now let’s fix the route-map so we get all of the prefixes…

Once we create the blank sequence 20 we can see that all of the prefixes are now being received by router2…

Furthermore, we can see that only one of the prefixes (10.10.10.0/24) has the LOCAL-AS community attached to it. 

So now, lets see if this is working as expected.  The LOCAL-AS community tells the routers that receive the prefix not to forward it to any BGP peers outside of the local AS (in this case 200)…

Router3 has the prefix as expected, now let’s check router4…

Router4 has it too.  That’s not right.  So what did we forget this time?  Recall we had to tell router1 to send BGP communities to router2?  We also need to tell router2 to send them to router3.  If we look at the prefix in the BGP table on router3, we’ll see it doesn’t have the community…

Quick fix on router2 and we should be in good shape…

If we look at router3 we should now see that it has the community…

And if we look at router4, we’ll see that it no longer has the prefix…

So that’s how the LOCAL-AS community works, let’s change it to the NO-ADVERTISE community and see what happens…

Looking at router2, we can see that it is still receiving the 10.10.10.0/24 prefix…

But if we look at router3, we see it no longer has the prefix in it’s BGP table…

So there you have it.  That’s a quick look at the well known BGP communities.  Now let’s take a look at the user defined communities. 

Recall that a user defined community can either be a straight 32 bit number or a 32 bit value broken into two smaller 16 bit numbers.  Let’s configure prefixes 20.20.20.0/24 and 30.30.30.0/24 to have user defined communities on them when they are originated from router1…

So here we create two new prefix lists to match the second and third prefixes.  We then create a route-map sequence for each matching the prefix list and setting a community based on the match.  We then set it on router1’s BGP peer in the outbound direction.  Since you can only have one route-map, in each direction, per peer, this overwrites the well known route-map we had configured earlier.

Looking at router2, we can see that it is receiving all 3 prefixes in BGP, and the second command shows that the second and third prefixes have an associated community. In the third command, I attempt to show the prefixes that have the community of 100:2 but the router kicks back the command…

Let’s look at the community associated with the prefix and see what happened…

Now what is that?  That’s not the ‘100:2’ that we configured earlier.  Actually, it is, it just took your ‘100:2’ and turned it into a 32 bit number.  So if we turn 100:2 into binary, we end with something like…

0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0

Which when considered as one long 32 bit binary string would equal…

1 1
2 2
3 4
4 8
5 16
6 32
7 64
8 128
9 256
10 512
11 1024
12 2048
13 4096
14 8192
15 16384
16 32768
17 65536
18 131072
19 262144
20 524288
21 1048576
22 2097152
23 4194304
24 …

6553602 would be the total of all of those bits.  So that’s sort of a pain right?  To make things easier, you can enable the global command ‘ip bgp new-format’ on the routers.  When you do that, you’ll see that you can now specify the new format in the show commands…

Now, let’s have router2 modify the communities before sending them on to router3…

So since we applied this on ingress, we can look at router2’s BGP table to see the results.  Let’s look at the BGP table to see what we have…

Huh, nothing…  So what did we do wrong here?  This is a mistake I made time and time again when dealing with communities.  The configuration we made makes sense.  You’re matching on one thing and setting another.  However, if we take more time and look at the settings for matching a community we see this…

The match is NOT looking for the actual community.  Rather, it’s looking for a community list that contains a match.  So let’s rebuild the modify route-map using the community lists and see what happens…

Now if we look at the BGP table, we see that we have two prefixes total and two of them have attached communities…

Note again that we did not include a empty route-map clause on router2 so we once again don’t have the 10.10.10.0/24 prefix since there was nothing there to match it.  Now let’s look at the communities and make sure they were updated correctly based on our match statements…

Note that 20.20.20.0 had it’s community updated as expected to 100:22.  However, note that the prefix 30.30.30.0 now shows that it has two communities.  Take a close look at the configuration we did on router2.  Note that the set command for the ‘match community thirdprefix’ route-map entry uses the word ‘additive’.  This tells the router to maintain it’s existing community, and add on the one you are configuring. 

Now, let’s talk a little bit more about community lists.  As you saw above, it was required that we use a community list to use for the match statement in the route-maps.  There are really two kinds of community lists, standard and expanded.  Standard community lists expect a specific community or string of communities.  Expanded community lists use regex for string matching.  Let’s go through a quick example on router2 so you can see how they work. 

First, lets update the 20.20.20.0 prefix so that it includes an additive community…

Since this was a inbound route-map, we can check the local router to make sure it worked…

Now, let’s define some community lists to play with…

So before we start, let me explain how matching works with community lists and route-maps.  Community lists AND each community per entry.  That is, community-list 50 expects the prefix to have 100:3, 100:22, and 100:33 attached to it. 

Route-maps use the OR logic.  If you have a community-list match sequence that lists multiple community-lists, it will accept any of the community list matches.  There’s also an option to use ‘exact-match’ on the route-map.  This tells the route-map to only match prefixes that have the EXACT list of communities.  Let’s go through a couple of examples…

Let’s assume that the route-map outbound has not yet been created but is attached to the iBGP peer of router 2 in the outbound direction.

Let’s tell it to advertise anything matching community-list 90 to it’s peer and then clear the BGP session.  The result on router3 is…

Router3 has both of the prefixes in it’s BGP table.  The logic behind this is simple.  The route-map ran through the community-list 90 and looked for matching prefixes.  Recall that a community-list uses AND logic on each permit statement.  Since community-list 90 only has a single community per entry, there is nothing to AND.  The route-map uses OR logic and when it looks at it’s prefixes it sees that it has a 2 prefixes that matches the list of communities.

Now, let’s change the route-map slightly…

Note the addition of the command ‘exact-match’ on the route-map.  Let’s see what router3 now has…

Nothing.  The route-map in this case went through each prefix it had and looked for ones that ONLY had a single community that matched a community-list entry in community-list 90.  Since the community-list only specifies single communities per entry, and we know that both prefixes have two communities, we can safely assume that no prefixes will be advertised without even looking at the communities. 

Let’s change the route-map again and see if you can figure out what prefixes will be advertised…

Community-list 60 references communities of 100:3 and 100:33 and 90 references 101:22.  As you can see below, router3 receives both prefixes…

Why is that?  The route-map uses OR logic and see that it has a prefix that matches both 100:3 and 100:33 (30.30.30.0/24) and one that matches 101:22 (20.20.20.0/24).  Note that we weren’t using the exact-match syntax on the route-map so it only cares about matching one of many possible communities on the prefix.  If we added that we’d see…

20.20.20.0/24 goes away since it has two communities and the previosuly matching community-list of 90 only specifies one. 

Lastly, let’s look at an expanded community list…

If we recall our BGP regex lab, the regex of ^100 will match strings that begin with 100.  Let’s see what router3 ends up with…

Again, it receives both prefixes since each prefix has at least one community that starts with 100.  You would think you could change this to use the exact-match sequence but that’s not possible…

Well, that’s it for this post.  I think the key take away is how community-lists are processed.  That was the big eye opener for me.