BGP community strings are a way of marking or tagging a route. Routing policy can then match on a community string, and take a defined action.
They are typically used in one of two ways:
- Grouping routes for use with routing policy
- Informing another party they should take some particular action on a route.
Types Of Community Strings
Broadly speaking, there are three types of community strings.
- Standard communities
- Extended communities
- Large communities.
Standard communities are 4 bytes long and broken into two 2-byte groups. The first group is typically set to the AS Number adding the community to the route, and the second group is an identifier that is meaningful within that AS. The AS number portion may also be used to identify the AS that should pay attention to the community string and act on it.
Examples include 65000:100 and 65100:12345. If you come from a Cisco background, this is referred to as the new format.
Standard communities are also sometimes expressed as an 8-character hexadecimal number, as shown in the well-known communities below.
There are several well known-standard communities, the most common are:
- No-Export (0xFFFFFF0) – Received routes with this community must not be advertised to another AS.
- No-Advertise (0xFFFFFF02) – Received routes with this community must not be advertised to any other BGP peer.
- No-Export-Subconfed (0xFFFFFF03) – Received routes with this community must not be advertised to BGP peers in other confederations.
Extended communities are 8 bytes long. They are broken into three groups. The first one or two bytes communicate the type and sub-type. The remaining 6 bytes may be organized into either a 4-byte group and a 2-byte group, or a 2-byte group and a 4-byte group.
Extended communities are used in MPLS VPN environments and commonly represent route targets or route origins.
In practice, these are formatted as type:AS:value or type:IP address: value. For example, target:65000:100 or target:10.10.10.10:200 or origin:65000:300.
Large communities are 12 bytes long. They are broken into three groups of 4 bytes. This allows for the first group to represent a 4-byte ASN number and two groups that are locally meaningful within that AS.
These may look like AS:value 1:value 2. For example, 4200000000:100:1 or 65000:200:2.
Note that although we often say the first part of a community string should be an AS number, implying it should be your AS number, it doesn’t have to be. Unless you have a good reason though, it is best to stick with convention.
One of the best ways to understand how useful community strings are is with a couple of simple examples.
Example 1 – Controlling Route Advertisements With Communities
This is an example of grouping routes together to simplify routing policy.
Consider the following diagram for a moment. AS 65001 connects to two transit providers, two customers, and one peering point.
Typically, we will want to ensure the following:
- Transit providers only receive customer routes
- Peering points only receive customer routes
- Customers receive other customer routes, plus peering routes and transit routes.
We also don’t want to update all our routing policies every time a new route is announced or a new customer connects to the network.
This can be achieved by the use of only three communities – let’s call them customer, peering, and transit. Our simplified policy might look like this
| Connection Type | Import Policy | Export Policy |
| Transit | Add transit community to all incoming routes | Only advertise routes with customer community attached |
| Peering | Add peering community to all incoming routes | Only advertise routes with customer community attached |
| Customer | Add customer community to all incoming routes | Advertise routes with either customer, peering, or transit communities attached |
Example 2 – Controlling Route Attributes With Communities
Keep the diagram from example 1 in mind. AS 65001 could create a new community to match on and call it No-Peering. AS 65001 can tell customers that if they don’t want their routes advertised to the peering connection, they can attach the No-Peering community to it. Note that adding this new community to the route is something the customer does, not AS 65001.
The routing policy for the connection to the peering point would change slightly. It would need to first reject any routes tagged with No-Peering, before advertising any other routes with the customer community attached.
The above is an example of community strings being used to tell another organization how to treat a route. In this case, it is the customer telling AS 65001.
For a more practical demonstration, see the following: