BGP Communities: Standard, Extended, and Large

As your BGP policy grows beyond a handful of prefix lists and route maps, you need a way to tag routes with meaning — "this is a customer route," "prefer this path," "don't advertise this outside our region." BGP communities provide exactly this. They're optional transitive attributes (carried across AS boundaries by default) that let you signal intent without having to build complex match conditions on every router.

Standard Communities (RFC 1997)

A standard community is a 32-bit value, typically written as two 16-bit numbers separated by a colon: ASN:VALUE. For example, 65001:100 means "defined by AS 65001, value 100." The meaning is entirely up to the operator — communities are just tags with no inherent behavior (except for a few well-known ones).

Well-Known Communities

Configuring Standard Communities

First, you must enable community sending to the peer — it's off by default on Cisco:

R1-HQ(config-router)# neighbor 172.16.0.2 send-community
R1-HQ(config-router)# neighbor 2.2.2.2 send-community

Tag routes with a community using a route-map:

route-map TAG-CUSTOMERS permit 10
 match ip address prefix-list CUSTOMER-NETS
 set community 65001:100 additive
!
route-map TAG-CUSTOMERS permit 20

The additive keyword is critical — without it, set community replaces all existing communities. With additive, it appends to the existing community list.

Matching on Communities

Create a community list, then reference it in a route-map:

ip community-list standard CUSTOMERS permit 65001:100
!
route-map PREFER-CUSTOMERS permit 10
 match community CUSTOMERS
 set local-preference 200
route-map PREFER-CUSTOMERS permit 20

Community lists can be standard (exact match on specific values) or expanded (regex-based matching):

! Standard: match exact community value
ip community-list standard CUSTOMERS permit 65001:100

! Expanded: match using regex — any community from AS 65001
ip community-list expanded ANY-65001 permit 65001:[0-9]+

Extended Communities (RFC 4360)

Extended communities are 8 bytes (vs 4 for standard), providing more structure. They're primarily used in MPLS VPN environments for route targets and site-of-origin:

! Route target (used in VRF import/export)
ip vrf CUSTOMER-A
 rd 65001:1
 route-target export 65001:100
 route-target import 65001:100

Extended communities are less commonly manipulated in pure internet BGP — they're an MPLS/VPN tool. But they follow the same transitive behavior: they're carried across AS boundaries unless explicitly stripped.

Large Communities (RFC 8092)

Standard communities have a 16-bit ASN field, which doesn't fit 4-byte ASNs (anything over 65535). Large communities solve this with a 12-byte format: ASN:Function:Parameter.

! Large community example for 4-byte ASN
set large-community 394210:100:1 additive

! Matching
ip large-community-list standard LC-EXAMPLE permit 394210:100:1
!
route-map MATCH-LC permit 10
 match large-community LC-EXAMPLE

The three-field format also provides more semantic structure — for example: ASN:Action:Region where Action=100 means "set local-pref" and Region=1 means "US-East."

Community-Based Policy Design

A well-designed community scheme lets customers signal routing preferences to their ISP without needing per-customer configuration changes on the ISP side. Common ISP community schemes:

The ISP implements this with a single inbound route-map that matches community values and takes the appropriate action. Adding a new customer or changing policy doesn't require config changes — just different community tags on the customer's advertisements.

Verification

R1-HQ# show ip bgp community 65001:100
BGP table version is 24, local router ID is 1.1.1.1
   Network          Next Hop         Metric LocPrf Weight Path
*> 10.1.0.0/16      0.0.0.0               0         32768 i
*> 10.2.0.0/16      172.16.0.5            0    100      0 65002 i

R1-HQ# show ip bgp 10.1.0.0/16
  ...
  Community: 65001:100

R1-HQ# show ip bgp community-list CUSTOMERS
  ... (routes matching community list)

R1-HQ# show ip community-list
Community standard list CUSTOMERS
    permit 65001:100

Stripping Communities

You should strip internal communities before advertising to eBGP peers — they're your internal policy tags and leaking them reveals your routing strategy:

route-map STRIP-INTERNAL-OUT permit 10
 set community none
!
router bgp 65001
 neighbor 172.16.0.2 route-map STRIP-INTERNAL-OUT out

Or selectively delete specific communities while preserving others:

ip community-list standard INTERNAL permit 65001:100
ip community-list standard INTERNAL permit 65001:200
!
route-map CLEAN-OUT permit 10
 set comm-list INTERNAL delete

Troubleshooting

Key Takeaways

• Communities are tags (not actions) — they carry no inherent behavior but enable policy decisions on routers that match them.
• Always use additive with set community to append rather than replace existing communities.
• Enable send-community per neighbor — Cisco doesn't send communities by default.
• Large communities (RFC 8092) solve the 4-byte ASN limitation and provide better semantic structure.
• Strip internal communities before advertising to eBGP peers to avoid exposing your policy design.