BGP Communities

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.

Communit Tag 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.

BGP Communities

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 VIRL lab and running configs 


R1 - Assign Communities

Prefix lists identify the routes to assign communities to. In this case, and is in Group1, and 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.


R1 - Assign Communities
! Identify networks with prefix lists
ip prefix-list Group1 seq 5 permit
ip prefix-list Group1 seq 10 permit
ip prefix-list Group2 seq 5 permit

! Match networks, and set community values
route-map R2_Peer permit 10
 match ip address prefix-list Group1
 set community 10:100

route-map R2_Peer permit 20
 match ip address prefix-list Group2
 set community 10:200

! Enable the new community format
ip bgp-community new-format

router bgp 10
 ! Enable sending communities
 neighbor send-community
 neighbor send-community extended

 ! Apply the route map to this neighbour
 neighbor route-map R2_Peer out



Verify Communities

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


R2 Verification
! Enable the new community format
ip bgp-community new-format

! Verify that the community is set
R2#show ip bgp
BGP routing table entry for, version 2
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  10 from (
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 10:100
      rx pathid: 0, tx pathid: 0x0

R2#show ip bgp
BGP routing table entry for, version 4
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  10 from (
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 10:200
      rx pathid: 0, tx pathid: 0x0


Set Policies

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.


R2 - Set Policies
! Create a named community list to identify the communities
ip community-list expanded High_Weight permit 10:100
ip community-list expanded Low_Weight permit 10:200

! Create a route-map to match the communities, and set the weight
route-map R1_Peer permit 10
 match community High_Weight
 set weight 100

route-map R1_Peer permit 20
 match community Low_Weight
 set weight 10
! Apply the route map to the neighbour
router bgp 20
 neighbor route-map R1_Peer in


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.



Verify Policies

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


R2 - Verification
! Verify that the weights are set
R2#show ip bgp
BGP table version is 4, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>               0           100 10 i
 *>               0           100 10 i
 *>               0            10 10 i



Well Known Communities

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.



Designing for Communities

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.



Twitter: @NetwrkDirection


Suggested Articles





Ethan Banks - BGP Well-Known Communities

Marwan Al-shawi and Andre Laurent - Designing for Cisco Network Service Architectures (ARCH) Foundation Learning Guide: CCDP ARCH 300-320 (ISBN 158714462X)


Last update 2017-08-29 09:11