If you’ve been working with BGP for a while, you already know the protocol can do a lot more than just advertise routes. One of the most powerful — and often underutilized — tools in your BGP toolkit is BGP Communities. When combined with route-maps and prefix-lists, communities let you attach metadata to prefixes and make routing decisions based on that metadata, at scale, across multiple routers and even across AS boundaries.
This guide is a deep dive into BGP communities on Cisco IOS-XE: what they are, how to set and match them, and how to build real-world route filtering policies. We’ll cover standard communities (RFC 1997), extended communities, and the newer large communities (RFC 8092). All examples use IOS-XE syntax with realistic show command output.
If you’re just getting started with BGP fundamentals, check out our BGP protocol overview before diving in. And if you’re working across multiple OS versions, our Cisco IOS vs IOS-XE vs IOS-XR comparison is worth reading alongside this guide.
What Are BGP Communities?
A BGP community is an optional transitive path attribute — a 32-bit tag attached to a BGP prefix. Communities don’t affect the routing decision directly; they’re metadata. You set them on prefixes as they’re advertised, and routers along the path can match on them to make policy decisions: accept, reject, prefer, deprioritize, or advertise onward.
The classic representation of a standard community is AA:NN, where AA is the ASN and NN is a local tag value. So if you’re AS 65001 and you want to tag prefixes learned from a customer, you might use community 65001:100.
RFC 1997 also defines a handful of well-known communities:
- no-export (
0xFFFFFF01) — Don’t advertise this prefix to any eBGP peer - no-advertise (
0xFFFFFF02) — Don’t advertise this prefix to any peer (iBGP or eBGP) - local-AS (
0xFFFFFF03) — Don’t advertise outside the local confederation - internet (
0x00000000) — Advertise to everyone (the default)
Enabling Community Propagation
By default, IOS-XE does not send the COMMUNITIES attribute to eBGP neighbors. You have to explicitly enable it per-neighbor:
router bgp 65001
neighbor 203.0.113.1 send-community
For extended communities (used in MPLS VPNs and route-target policies), use:
router bgp 65001
neighbor 203.0.113.1 send-community extended
Or to send both standard and extended:
router bgp 65001
neighbor 203.0.113.1 send-community both
Forgetting this is one of the most common BGP community misconfigurations. If your community tags are disappearing across eBGP sessions, this is the first thing to check.
Setting Communities with Route-Maps
Communities are set using set community inside a route-map. Here’s a straightforward example: tagging all prefixes learned from a downstream customer with community 65001:200 before advertising them to upstream peers.
! Step 1: Define a route-map to set the community on customer routes
route-map SET_CUSTOMER_COMMUNITY permit 10
set community 65001:200
! Step 2: Apply inbound on the customer-facing neighbor
router bgp 65001
neighbor 192.168.10.1 route-map SET_CUSTOMER_COMMUNITY in
neighbor 192.168.10.1 send-community
To set multiple communities on a single prefix:
route-map SET_MULTI_COMMUNITY permit 10
set community 65001:200 65001:300 additive
The additive keyword appends to existing communities rather than replacing them. Without it, you’ll overwrite whatever communities were already attached to the prefix — a subtle but critical difference in most real deployments.
Matching Communities with Community-Lists
To act on communities at another router, you first create a community-list, then reference it in a route-map.
Standard Community-Lists
! Match prefixes tagged as customer routes
ip community-list standard CUSTOMER_ROUTES permit 65001:200
! Match prefixes tagged as backup paths
ip community-list standard BACKUP_ROUTES permit 65001:300
Extended Community-Lists (Regex)
For more flexible matching, use an expanded (regex) community-list:
! Match any community where the first part is 65001
ip community-list expanded MATCH_AS65001 permit 65001:.*
! Match communities indicating a specific region code (100-199)
ip community-list expanded MATCH_REGION_WEST permit 65001:1[0-9][0-9]
Route-Map Using Community-List
route-map FILTER_CUSTOMER_ROUTES permit 10
match community CUSTOMER_ROUTES
set local-preference 150
route-map FILTER_CUSTOMER_ROUTES permit 20
! Implicit permit — pass everything else through unchanged
router bgp 65001
neighbor 203.0.113.1 route-map FILTER_CUSTOMER_ROUTES in
Notice the explicit permit 20 clause. A route-map ends with an implicit deny — if your policy only has a permit 10 that matches community X, every prefix that doesn’t carry community X will be dropped. This is one of the most common misconfiguration patterns in BGP policy and a frequent source of unexpected route loss.
Real-World Use Case: Blackhole Communities (RTBH)
A common operational use case is RTBH (Remotely Triggered Black Hole) filtering for DDoS mitigation. The convention is community 65535:666 (or your own AS:666). When a router receives a prefix with this community, it sets the next-hop to a null interface and drops all traffic destined for that prefix.
! On the receiving router: set up the blackhole route-map
route-map BLACKHOLE_RTBH permit 10
match community BLACKHOLE_COMMUNITY
set local-preference 200
set origin igp
set community no-export
set ip next-hop 192.0.2.1 ! This IP must point to Null0
! Configure the static discard route
ip route 192.0.2.1 255.255.255.255 Null0
! Define the community
ip community-list standard BLACKHOLE_COMMUNITY permit 65535:666
! Apply to iBGP peers distributing the blackhole signal
router bgp 65001
neighbor 10.0.0.0 route-map BLACKHOLE_RTBH in
To trigger a blackhole for a specific host under attack, originate the /32 with the community from your NOC or automation system:
router bgp 65001
address-family ipv4
network 198.51.100.123 mask 255.255.255.255 route-map SET_BLACKHOLE
route-map SET_BLACKHOLE permit 10
set community 65535:666 no-export
The no-export well-known community keeps the blackhole signal from leaking to upstream providers — you only want your own routers to discard the traffic, not to signal upstream to do so.
Verifying Communities
Once your community policy is in place, verify it with these commands:
R1# show ip bgp community 65001:200
BGP table version is 47, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i 10.100.0.0/24 10.0.1.2 0 150 0 65002 i
*>i 10.100.1.0/24 10.0.1.2 0 150 0 65002 i
*>i 10.100.2.0/24 10.0.1.2 0 150 0 65002 i
R1# show ip bgp 10.100.0.0/24
BGP routing table entry for 10.100.0.0/24, version 31
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
65002
10.0.1.2 from 10.0.1.2 (10.0.1.2)
Origin IGP, metric 0, localpref 150, valid, internal, best
Community: 65001:200
Last update: 00:14:22 ago
R1# show ip bgp community-list CUSTOMER_ROUTES
BGP table version is 47, local router ID is 10.0.0.1
Network Next Hop Metric LocPrf Weight Path
*>i 10.100.0.0/24 10.0.1.2 0 150 0 65002 i
BGP Community-Based Traffic Engineering
One of the most powerful operational uses of communities is influencing routing at upstream providers. Major transit operators publish community schemas that let downstream customers:
- Set local preference on routes they advertise into the upstream network
- Control which peers the upstream advertises your prefixes to
- Prepend AS paths to shift inbound traffic flows
- Selectively withdraw routes from specific peering regions
For example, a common AS prepending convention used by many transit providers:
! Assuming upstream AS 1299 accepts communities for AS-path prepending:
! 1299:101 = prepend once, 1299:102 = prepend twice, 1299:103 = prepend three times
route-map PREPEND_TO_PRIMARY permit 10
match ip address prefix-list PREFIXES_TO_SHIFT
set community 1299:102 additive
router bgp 65001
neighbor 80.91.255.1 route-map PREPEND_TO_PRIMARY out
neighbor 80.91.255.1 send-community
This tells your transit provider’s routers to prepend your AS twice in the AS path when advertising your prefixes to their peers and other customers — making those paths look less attractive and directing inbound traffic toward your secondary link instead. Always check your provider’s published community schema; it varies significantly between carriers and is typically found in their IRR (Internet Routing Registry) records or their NOC documentation.
Large BGP Communities (RFC 8092)
Standard communities are 32 bits — fine for small operators, but the AA:NN format limits the NN field to 16 bits, which isn’t enough for networks with large ASNs or complex hierarchical policies. RFC 8092 introduced Large Communities, which use a 96-bit format: Global_Administrator:Local_Data_Part_1:Local_Data_Part_2.
IOS-XE supports large communities from version 16.6+. Configuration is similar to standard communities but with the large-community keyword:
! Set a large community on outbound advertisements
route-map SET_LARGE_COMMUNITY permit 10
set large-community 65001:100:200 additive
! Define a large community-list for matching
ip large-community-list standard LARGE_CUSTOMER permit 65001:100:200
! Route-map using the large community-list
route-map MATCH_LARGE permit 10
match large-community LARGE_CUSTOMER
set local-preference 120
R1# show ip bgp large-community 65001:100:200
BGP table version is 52, local router ID is 10.0.0.1
Network Next Hop Metric LocPrf Weight Path
*> 10.200.0.0/22 203.0.113.1 0 120 0 65003 i
Large communities are increasingly the standard for IXP and transit policy signaling. If you’re operating at scale, getting familiar with them now will save you significant rework later — most major IXPs and carriers are moving their community schemas to RFC 8092 format.
Stripping Communities Before Advertising
There are situations where you want to strip communities before sending prefixes to certain peers — for instance, to avoid leaking internal operational tags to customers or untrusted upstream peers:
route-map STRIP_INTERNAL_COMMUNITIES permit 10
set community none
router bgp 65001
neighbor 192.168.20.1 route-map STRIP_INTERNAL_COMMUNITIES out
To strip only specific communities while leaving others intact, match the communities to remove and then explicitly clear them:
ip community-list standard INTERNAL_TAGS permit 65001:500
ip community-list standard INTERNAL_TAGS permit 65001:501
route-map STRIP_SPECIFIC permit 10
match community INTERNAL_TAGS
set community none
route-map STRIP_SPECIFIC permit 20
! Pass everything else unchanged — do NOT forget this clause
This pattern is especially important at AS boundaries where your internal operational communities shouldn’t be visible to customers or peers who could potentially use that information to infer your network topology.
Designing a Community Schema
Before you start tagging prefixes, it pays to design a consistent community schema. A few conventions used in real ISP and enterprise networks:
- Origin tagging — Tag prefixes by where they were learned:
AS:100= customer,AS:200= peer,AS:300= transit upstream - Geographic tagging — Tag by region or datacenter:
AS:1000= US-East,AS:1001= US-West,AS:1002= EU - Action tags — Prefixes that should be blackholed, prepended, or have reduced local-pref
- Peer group tags — Tag by upstream provider or IXP peering session for selective advertisement control
Document your schema in an internal wiki or comments in your router configs. It sounds obvious, but community schemas that aren’t documented tend to become tribal knowledge — and when the engineer who built it leaves, so does the understanding of what 65001:743 means.
Troubleshooting Community Policies
Community policies are applied through route-maps, and route-maps are evaluated top-down with first-match semantics. Common issues and how to diagnose them:
- Communities not propagating to eBGP peers — Check
send-communityis configured on the neighbor - Route-map not matching as expected — Use
debug ip bgp <neighbor> updates in(with caution; always filter with an ACL in production) - Missing permit 20 / implicit deny — A route-map that only matches community X will silently drop everything else
- Additive vs replace — Forgetting
additivewipes existing communities when setting new ones - Community visible in RIB but not propagating — Verify outbound route-map isn’t stripping the community
! Verify the route-map assignment
R1# show ip bgp neighbors 203.0.113.1 | include route-map
Route map for incoming advertisements is FILTER_CUSTOMER_ROUTES
Route map for outgoing advertisements is STRIP_INTERNAL_COMMUNITIES
! Inspect community-list definitions
R1# show ip community-list
Community standard list CUSTOMER_ROUTES
permit 65001:200
Community standard list BACKUP_ROUTES
permit 65001:300
! Check what a neighbor is actually receiving (after policy)
R1# show ip bgp neighbors 203.0.113.1 advertised-routes
For a thorough BGP peer troubleshooting workflow, the diagnostic patterns from our OSPF troubleshooting guide — show neighbor, debug filtering, soft reset — carry over directly to BGP and are worth revisiting.
Soft Reset After Policy Changes
After changing a community policy or route-map, you’ll need to reapply it. Hard resets (clear ip bgp X) drop the BGP session entirely, causing a routing outage. Use soft reset instead:
! Inbound soft reset — re-evaluates inbound policy using stored Adj-RIB-In
R1# clear ip bgp 203.0.113.1 soft in
! Outbound soft reset — re-advertises prefixes through updated outbound policy
R1# clear ip bgp 203.0.113.1 soft out
! Both directions
R1# clear ip bgp 203.0.113.1 soft
For soft inbound resets to work, the neighbor needs route-refresh capability. This is enabled by default on IOS-XE, but verify with:
R1# show ip bgp neighbors 203.0.113.1 | include refresh
Neighbor capabilities:
Route refresh: advertised and received(new)
If route-refresh isn’t available (older neighbor), you’ll need a hard reset or to pre-configure bgp soft-reconfig inbound on the neighbor, which stores a full copy of the Adj-RIB-In in memory (at the cost of additional RAM usage).
Summary
BGP communities are the right tool when you need to attach policy metadata to prefixes and act on that metadata at multiple points in your network — or across AS boundaries. The key takeaways:
- Enable
send-communityper-neighbor — it’s off by default for eBGP - Use
additivewhen setting communities unless you explicitly want to replace existing ones - Community-lists are your match tool; route-maps are your action tool
- Always include a trailing permit clause in route-maps to avoid silently dropping unmatched prefixes
- Large communities (RFC 8092) are the future — learn them now if you haven’t already
- Strip internal communities before advertising to untrusted peers
- Design and document your community schema before deploying it at scale
- Use soft reset (
clear ip bgp X soft) after policy changes to avoid session drops
The combination of community tagging, route-maps, and a well-designed community schema gives you a flexible, scalable routing policy framework that works equally well in a small enterprise network or a large multi-AS environment. Once you’ve built a few of these policies in the lab, the pattern becomes intuitive — and you’ll start seeing community opportunities everywhere in your production BGP configs.
