The main purpose of BGP enabled routers is to advertise prefixes to other routers. These prefixes can be from several different address families, such as IPv4 and VPNv4. When advertising a prefix, BGP attaches extra information, called attributes. BGP uses these attributes to select the best path.

BGP can include more information with each prefix, in the form of Community Strings. A community string is a number value that the peer uses like a tag.

Communities create routing policies between peers. By tagging prefixes with communities, we tell the peer to handle the prefixes in a special way.

As an example, lets say that a specific group of prefixes need to have their weight set to 10 by a peer router. We can choose a community number to use, and tag the prefixes with it. If it sees a prefix from us tagged with this community, it will set the weight to 10.

We do have to agree with our peer on which communities to use. From a technical perspective, it’s up to them to decide how they will handle any community string. They could choose to ignore them altogether if they want to.

Providers may have a list of pre-defined communities that they use, and actions that they take. As the customer, we can set our communities to match their policies, to tune how they handle our prefixes.

Communities are optional and transitive. They are transitive so one peer can pass them to the next peer.

Each standard community is a 32-bit value. They are often broken into two 16-bit values, to make them easier to read. For example, the community 4259840100 is the same thing as 65000:100. Often the first 16-bits represent the AS, and the second 16-bits are a custom value.

There are also extended communities, which are for special purposes, such as MPLS VPN’s. These are 64-bit values. They comprise of a 16-bit type value, a 16-bit AS or IP value, and 32-bits for the custom community value.

Some communities are reserved:

• 0:0 – 0:65535
• 65535:0 – 65535:63335

Let’s lab this out to see how it works. Please be aware that this is not a real-world scenario.

For this lab, we’ll use two router’s with different ASN’s. R1 has several networks it wants to advertise to R2.

R2 assigns weights to the prefixes, depending on the attached communities:

• If the community is set to 10:100, it will set the weight to 100
• If the community is set to 10:200, it will set the weight to 10

Download the BGP Communities Lab

Prefix lists identify the routes to assign communities to. In this case, 172.16.0.0 and 172.16.10.0 is in Group1, and 172.16.20.0 is in Group2.

Route-maps match the prefix lists, then set the community on the route. Group1 is assigned community 100, and Group2 is assigned community 200.

By default, the communities are one large number, which is hard to read. The ip bgp-community new-format command changes this value to the ASN:Community format. This makes verification easier later on.

By default, Cisco routers do not send communities. Enable this per neighbour with the send-community and send-community extended commands.

Finally, the route map is applied to the neighbour outbound. When sending routes to the neighbour, the communities are attached.

Here, we can see that the communities are set on the routes that R2 receives.

Now that R2 is receiving routes with communities, it can apply policies to them.

First, we create a community list to identify specific communities. These are like using ACLs or prefix-lists to identify IP addresses. In this example we use a named community list. Unlike numbered community lists, they support RegEx, and may have unlimited entries. Numbered lists have a limit of 100 entries.

Route-maps match the community, and set the weight.

The route-map is applied to the neighbour for inbound prefixes.

These changes will not take place for routes already in your routing table. The easiest way to force this to apply is to reset the neighbour relationship. Bear in mind that this is disruptive, so don’t do it in a production network.

If you look at the BGP table on R2, you can see that the weights have been set as expected.

There are several pre-defined communities, called Well Known Communities. These communities have special pre-defined meanings that all BGP speakers support.

The more common ones include:

Internet – A Cisco proprietary community. This allows the router to advertise the prefix to all neighbours. This is a ‘catch-all’ community at the end of a community list. This is an exception, as it not all vendors will support it.

No-Export – Prevents advertising the prefix to any eBGP neighbours. This keeps a prefix in the AS.

No-Advertise – This prevents advertising the prefix to any neighbours at all.

Local-AS – Used with confederations to keep the prefix within the local AS. Allows prefix sharing with eBGP neighbours within the confederation.

When designing communities, consider these basic steps:

1. Define the routing administrative policy
   • Decide what to filter, and where to filter
   • Decide what attributes to change to influence traffic flow
2. Design the community scheme
   • That is, decide which values to use, based on the policy
3. Deploy the scheme using route maps
4. Create documentation

When receiving routes from an external source, consider tagging them based on the site they were received on. Likewise, when originating routes, consider tagging them with an ID for the site that originated them.