ManyIn our previous article dedicated to BGP attributes, we covered how routers evaluate BGP attributes found in the Update message to select the best path to be installed in the routing table. In that article, we also covered some important definitions that provide context for discussing BGP functionality. 

Although BGP communities represent just one of the BGP attributes available, there’s a lot to be said about them. In this article, we’ll explore what kind of BGP communities exist and how you can use them to manipulate network traffic. 

What Is a BGP Community?

A BGP community is an optional, transitive BGP attribute that is recognized and passed to other BGP peers. You might see a BGP community as a tag attached to the BGP routes exchanged between two BGP peers.

To get started, let’s look at what a BGP community set to a route looks like in an Update message. Consider this simple network, where R111 advertises the 10.10.10.0/24 route to the AS 11 BGP peer. R111 sets the community 1:110 on the routes it advertises to R11.g.

When looking at the BGP Update message from R111 (1.1.3.2) towards R11 (1.1.3.1), we can see multiple BGP attributes along with their value. One of these BGP attributes is the community. Remember, this attribute is optional and it’s showing up because it was set on the route before being advertised:

When we check the route on R11 (because R11 accepted the route and also doesn’t execute any operation on the community), we can see the route having the 1:110 community:

R11#show ip bg 10.10.10.0/24
BGP routing table entry for 10.10.10.0/24, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  111
    1.1.3.2 from 1.1.3.2 (10.10.10.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 1:110
      rx pathid: 0, tx pathid: 0x0
R11#

Now that you’ve seen what a BGP community looks like within an Update message, let’s begin exploring the more advanced concepts surrounding this attribute. 

Advanced BGP Community Concepts

A community is a 32-bit value split into two 16-bit sections. The first 16 bits encode the AS number that originated the community and the last 16 bits represent a unique number assigned by the AS. Because each AS number is unique, each community is also unique on the internet. This means that an AS with the ASN 9999 (which in hex is 0x270F) can have communities in the range 0x270F0000 – 0x270FFFFF.

Well-known BGP Communities

The following are few well-known communities that must be recognized by all community aware BGP implementations.

1. No-Advertise Community 

When a No-Advertise community is attached to a route, the BGP speaker won’t advertise the route to any internal or external BGP peers.

The following example shows a No-Advertise Route (10.10.10.0/24) not being advertised by R1 to peers R11, R12, R111.

2. No-Export Community

When a No-Export community is attached to a route, the router won’t advertise the route to external peers–only to internal peers. 

The following example shows a No-Export Route (10.10.10.0/24) not being advertised by R1, R11, or R12 to their external peer, R111.

In this specific case, R1 will not advertise the route to R111, only to R11 and R12, because these two are internal BGP peers. Subsequently, R11 and R12 will not advertise either route to R111 because it is an external BGP peer. 

3. Local AS Community

To avoid any BGP routing loops, there is an important rule regarding the internal BGP neighbors: an IBGP neighbor cannot advertise a route to an IBGP neighbour if it received that route from another IBGP neighbor.

The following example shows a Local AS Route (10.10.10.0/24) not being advertised between IBGP neighbors (R11 and R111) within the local AS. 

More exactly, R11 advertises the route to R22, but R22 does not advertise the route to R111, based on the rule mentioned above. For R111 to have the route, there are multiple solutions like creating a full mesh of IBGP sessions between the routers of AS11, or breaking the AS 11 into a sub-AS inside of a confederation.

The world outside of AS11 is unaware of AS 1000 and AS1001. This allows R111 to receive the 10.10.10.0/24 route without having full mesh BGP peering. The Local-AS community doesn’t advertise routes outside of the sub-AS.

4. Graceful Shutdown Community

The Graceful_SHUTDOWN (65535:0) community is used to smoothly shut down paths a router might use when its peer router is about to be intentionally shut down. For illustration, suppose that R111 is using R11 to reach the 10.10.10.0/24 subnet, but R11 will go down for a reboot to be upgraded:

Once R11  advertises this community, R111 responds by switching traffic over to R12 with minimal impact:

5. Extended Community

An Extended community is a 8-byte value that is divided into two main sections:

• First 2 bytes: Specifies community type
• Last 6 bytes: Provides unique information specific to the community type 

An extended community has three fields: type, administrator, assigned number (type:administrator:assigned-number). Based on the value of the high-order byte in the Type field, the administrator field can be an AS or an IP address.

The most well-known application for extended communities is in MPLS-VPN which makes use of two extended communities:

• Route Target community:  Identifies the routers that can receive a specific set of routes. 
• Route Origin community: Identifies the routers that inject a specific set of routes into BGP.

A Virtual Routing and Forwarding (VRF) is a virtual routing table that can have its own separate routing policies separate from the global routing table or from other VRFs. Basically, you can connect multiple sites of a customer and have a separate routing table (VRF) across the entire network just for this customer and implement routing policies that are different from the routing policies of another customer.

This separation is possible due to multiprotocol BGP extensions and MPLS.

6. Route Target Community

The Route Target community is used in MPLS VPN environments to separate two customers routing tables, as shown in the following diagram:

In this specific case, VRF Customer RED is present only on R1 and R12 and VRF Customer BLUE is present only on R11 and R22, but they could have been present on all four routers.

When a route is exported through BGP from VRF Red, the route-target 100:100 is assigned to the route via export. When the route reaches R12, it imports the route from R1 so the sites connected to R1 and R12 are able to communicate.

7. Route Origin Community

In an MPLS VPN environment, the route origin community is used to identify where routes originated from, so that readvertisement back to that site is avoided.

In this case, when PE1 receives the route from CE1, besides the route-target that is attached to the route (using export), it also attaches the route origin community. 

The route reaches PE2, but PE2 does not advertise it to CE2, because it knows that it came from the site.

8. Large Communities

A Large community is a 12-byte BGP community that was developed when the 4-byte AS began to be allocated. Since each of the standard or extended communities use 2-byte values for the AS,  a 4-byte AS would not fit into the standard 2-byte value.

The Large community is displayed as follows: 32-bit-ASN:32-bit-value:32-bit-value.

BGP Best Path Selection Algorithm

As you have seen, BGP communities have multiple applications. They are important for tagging routes, manipulating traffic, and performing various actions on the BGP attributes of routes matching specific communities. 

Whenever a router must determine which path of many to take to a given destination, it has to follow the BGP best path selection algorithm, which evaluates BGP attributes. You can read more about the BGP best path selection algorithm in our previous article, BGP Attributes.

BGP Community Examples

This section demonstrates how a BGP community attached to a route can influence the upload and download traffic to and from hosts from that prefix.

Upload

There are multiple ways to influence the upload traffic path, but the most common is to make use of the local preference. As you’ve seen in the BGP Attributes article, the higher the value of the local preference for a route, the more likely that path is chosen by the BGP best path selection algorithm.

In the following illustration, R11 and R12 are configured to: 

• Set the local preference to 205 if they receive a route with community 1:205.
• Set the local preference to 210 if they receive a route with community 1:210.

Both of these routers advertise the routes to R1, which must decide which path to use. In this case, R1 uses the path from R11, meaning the traffic will flow like this: 

Upload Router Output

R1#sh ip bgp 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 2
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  111
    1.1.3.2 (metric 20) from 1.1.1.2 (1.1.100.11)
      Origin IGP, metric 0, localpref 210, valid, internal, best
      Community: 1:210
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  111
    1.1.4.2 (metric 20) from 1.1.2.2 (1.1.100.12)
      Origin IGP, metric 0, localpref 205, valid, internal
      Community: 1:205
      rx pathid: 0, tx pathid: 0
R1#

Download

A common way to influence your download traffic path (or how others send traffic to your AS), is to perform AS_PATH prepend for your AS. The longer the AS_PATH, the less likely that path is selected by the best path selection algorithm.

In the next illustration, AS 1 prefers that traffic forwarded from AS 111 is sent from R12. 

AS 111 (because of R111) has a policy stating that if AS 1 announces a prefix with the community 1:1, perform one AS_PATH prepend. Therefore, R111 sets the AS_PATH of the route as [1 1]. If the route is coming with the community of 1:3, then perform three AS_PATH prepends ([1 1 1 1]).

R111 receives the two paths and must act based on the community attached to those paths. Since it prefers the route from R12, the traffic flows like this:

Download Router Output

R111#sh ip bgp  10.10.10.0/24
BGP routing table entry for 10.10.10.0/24, version 4
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     6
  Refresh Epoch 2
  1 1 1 1
    1.1.3.1 from 1.1.3.1 (1.1.100.11)
      Origin IGP, metric 100, localpref 100, valid, external
      Community: 1:3
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  1 1
    1.1.4.1 from 1.1.4.1 (1.1.100.12)
      Origin IGP, localpref 100, valid, external, best
      Community: 1:1
      rx pathid: 0, tx pathid: 0x0
R111#

Summary

In this article, we discussed the most common BGP communities available for the BGP Community attribute and how they are used to direct traffic. Although BGP Communities are optional attributes, they are powerful for both internal and external traffic routing. You can even use them to prepare traffic redirection for planned reboots and shutdowns. 

FAQs