BGP communities are one of the most underused yet most powerful tools in a network engineer’s toolkit. If you’ve been doing BGP without communities, you’ve been doing it with one hand tied behind your back. In this post, we’re going deep on BGP communities and route filtering on Cisco IOS-XE — not theory-heavy fluff, but actual configs you can adapt and deploy.
This is a natural companion to the foundational BGP protocol overview we covered earlier. That post explains the mechanics; this one shows you what to do with them in production.
What Are BGP Communities?
A BGP community is a 32-bit attribute you attach to a route (prefix) as it travels between BGP speakers. Think of it as a tag that carries policy intent alongside the route itself. Instead of building giant prefix-lists or complex route-maps everywhere, you tag a route with a community at one point, and every router downstream can match on that tag and apply the appropriate policy.
The original RFC 1997 communities use the format AS:value — for example, 65001:100. Extended communities (RFC 4360) and large communities (RFC 8092) expand this further, but for most enterprise and SP deployments, standard communities do the heavy lifting.
A few well-known communities to know cold:
- no-export (
65535:65281): Don’t advertise this prefix to eBGP peers — keep it inside the AS. - no-advertise (
65535:65282): Don’t advertise this prefix to any peer at all. - local-AS (
65535:65283): Don’t send this prefix outside the sub-AS in a confederation. - internet (
0x00000000): Advertise to everyone. The default if no community is set.
Enabling Community Propagation
Here’s the gotcha that trips up engineers new to communities: IOS-XE does not send communities to eBGP peers by default. You must explicitly enable it per-neighbor.
router bgp 65001
neighbor 203.0.113.1 remote-as 65002
neighbor 203.0.113.1 send-community
Without send-community, your communities are stripped before the update leaves your router. For iBGP peers, communities propagate by default, but being explicit is good practice:
router bgp 65001
neighbor 10.0.0.2 remote-as 65001
neighbor 10.0.0.2 send-community both
The both keyword sends standard and extended communities. Use extended alone if you’re carrying VPNv4 route targets.
Setting Communities on Outbound Routes
The most common use case: tagging routes leaving your AS so your upstream provider can apply the right policy — maybe lower local-preference for a backup link, or blackhole a prefix under attack.
ip prefix-list PFX_BACKUP_ROUTES seq 5 permit 198.51.100.0/24
ip prefix-list PFX_BACKUP_ROUTES seq 10 permit 198.51.101.0/24
route-map SET_COMMUNITY_OUT permit 10
match ip address prefix-list PFX_BACKUP_ROUTES
set community 65002:200 additive
route-map SET_COMMUNITY_OUT permit 20
! everything else — permit with no changes
router bgp 65001
neighbor 203.0.113.1 route-map SET_COMMUNITY_OUT out
The additive keyword is critical — without it, set community replaces any existing communities on the prefix rather than appending to them. Almost always use additive unless you intentionally want to clear existing communities.
In this example, community 65002:200 signals “this is a backup route” — the meaning is agreed upon with AS 65002. Providers typically publish a community document specifying what values trigger which policies.
Filtering on Incoming Communities
On the receiving side, you match communities and apply policy. Say your upstream tags primary routes with 65001:100 and backup routes with 65001:500. Here’s how to use that to set local-preference:
ip community-list standard COM_PRIMARY permit 65001:100
ip community-list standard COM_BACKUP permit 65001:500
route-map SET_LOCPREF_IN permit 10
match community COM_PRIMARY
set local-preference 200
route-map SET_LOCPREF_IN permit 20
match community COM_BACKUP
set local-preference 50
route-map SET_LOCPREF_IN permit 30
! default — permit with no changes
router bgp 65001
neighbor 203.0.113.1 route-map SET_LOCPREF_IN in
Local-preference is an iBGP attribute that doesn’t leave your AS, but it controls which exit point your internal routers prefer. Higher wins. Primary at 200, backup at 50 means all traffic exits via primary until it’s gone.
Community lists come in two flavors: standard matches exact communities; expanded uses regex. For simple values, standard is cleaner and faster to process.
Using Community-List with Regex (Expanded)
When working with a range of communities — say, anything tagged 65002:1xx — expanded community lists let you write one regex instead of dozens of standard entries:
ip community-list expanded COM_UPSTREAM_POLICY permit 65002:1[0-9][0-9]
route-map MATCH_UPSTREAM_POLICY permit 10
match community COM_UPSTREAM_POLICY
set local-preference 150
IOS uses extended regex on community-lists. Test your patterns before pushing to production — use show bgp community-list COM_UPSTREAM_POLICY to validate.
BGP Route Filtering: Prefix-Lists and AS-Path Filters
Communities work best when combined with the rest of the filtering toolkit.
Prefix-Lists
! Accept only a customer's assigned /24s and more-specifics up to /28
ip prefix-list CUSTOMER_A_PREFIXES seq 10 permit 192.0.2.0/24 le 28
! Block traffic from a hijacked block
ip prefix-list BOGON_BLOCK seq 10 deny 100.64.0.0/10 le 32
ip prefix-list BOGON_BLOCK seq 20 permit 0.0.0.0/0 le 32
Prefix-lists stop at the first match. Always end with an explicit permit or deny — the implicit deny at the end will silently drop routes you wanted to keep.
AS-Path Filters
AS-path access-lists use regex to match the AS path of routes. Useful for rejecting transit through untrusted ASes or accepting only directly connected customers:
! Only accept routes originated by AS 65100 (direct peer, no transit)
ip as-path access-list 10 permit ^65100$
! Reject routes that have passed through AS 65999 (untrusted)
ip as-path access-list 20 deny _65999_
ip as-path access-list 20 permit .*
route-map PEER_INBOUND permit 10
match as-path 10
set local-preference 100
route-map PEER_INBOUND deny 20
match as-path 20
route-map PEER_INBOUND permit 30
The ^ anchors path start, $ anchors the end, and _ matches a delimiter (space, start, end, or brackets). ^65100$ means AS 65100 is the only AS in the path — no transit anywhere.
Route-Map Sequence Logic
Route-maps process top-to-bottom, stopping at the first matching sequence:
route-map COMPLEX_POLICY deny 10
match community COM_BLACKHOLE
route-map COMPLEX_POLICY permit 20
match community COM_BACKUP
set local-preference 50
set metric 200
route-map COMPLEX_POLICY permit 30
match ip address prefix-list CUSTOMER_PREFIXES
set community 65001:100 additive
set local-preference 200
route-map COMPLEX_POLICY permit 40
! catch-all permit
A route-map with no catch-all at the end implicitly denies everything that doesn’t match — a common production outage cause after policy changes.
BGP Blackhole Communities (RTBH)
One of the most operationally valuable community uses: remotely triggered blackholing (RTBH). Under a DDoS attack, tag the victim prefix with a well-known blackhole community (typically 65535:666 or your provider’s equivalent), and your upstream drops traffic at their edge before it consumes your bandwidth.
! Configure the blackhole next-hop
ip route 192.0.2.1 255.255.255.255 Null0
route-map RTBH_OUT permit 10
match ip address prefix-list BLACKHOLE_PREFIXES
set community 65002:666 additive
set origin igp
set local-preference 200
set ip next-hop 192.0.2.1
router bgp 65001
neighbor 203.0.113.1 route-map RTBH_OUT out
To activate a blackhole, add the victim prefix to BLACKHOLE_PREFIXES and clear the outbound BGP session. Your upstream matches the community, applies their drop policy, and the traffic never reaches your edge.
Verifying Community Configuration
Here’s what the relevant show commands look like on a live IOS-XE router:
Router# show bgp ipv4 unicast 198.51.100.0/24
BGP routing table entry for 198.51.100.0/24, version 42
Paths: (2 available, best #1, table default)
Refresh Epoch 1
65002
203.0.113.1 from 203.0.113.1 (203.0.113.1)
Origin IGP, metric 0, localpref 200, valid, external, best
Community: 65001:100 65002:50
Refresh Epoch 1
65002 65003
203.0.113.2 from 203.0.113.2 (203.0.113.2)
Origin IGP, metric 0, localpref 50, valid, external
Community: 65001:500 65002:200
Router# show bgp ipv4 unicast community 65001:100
Network Next Hop Metric LocPrf Weight Path
*> 198.51.100.0/24 203.0.113.1 0 200 0 65002 i
*> 198.51.101.0/24 203.0.113.1 0 200 0 65002 i
To check what communities you’re sending to a peer:
Router# show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes | include Community
Community: 65001:100 65002:50
Router# show ip community-list
Standard community list COM_PRIMARY
permit 65001:100
Standard community list COM_BACKUP
permit 65001:500
Large Communities (RFC 8092)
As BGP deployments grow, the 16-bit value field in standard communities becomes a constraint — especially in 32-bit ASN space. Large communities solve this with a 12-byte format: GlobalAdministrator:LocalData1:LocalData2, where GlobalAdministrator is the full 32-bit ASN.
route-map SET_LARGE_COMMUNITY permit 10
set large-community 131072:200:1 additive
router bgp 131072
neighbor 203.0.113.1 send-community large
IOS-XE 16.6+ supports large communities. Verify your version first:
Router# show version | include IOS-XE Software
Cisco IOS XE Software, Version 17.09.04a
Matching on large communities:
ip large-community-list standard LC_BACKUP permit 131072:200:1
route-map MATCH_LARGE_COMM permit 10
match large-community LC_BACKUP
set local-preference 50
Combining Communities with MED for Traffic Engineering
MED lets you influence how traffic enters your AS from a specific peer. Communities let you signal your preferred MED to your provider rather than fighting over routing decisions out-of-band:
route-map SET_MED_PRIMARY permit 10
match ip address prefix-list PRIMARY_PREFIXES
set metric 100
set community 65002:100 additive
route-map SET_MED_BACKUP permit 10
match ip address prefix-list BACKUP_PREFIXES
set metric 500
set community 65002:500 additive
Lower MED is preferred. Your upstream prefers the link advertising MED 100 for inbound traffic to your prefixes. You control egress with local-preference, ingress with MED — subject to your provider actually honoring it, which you should verify. For a broader view of traffic prioritization within your AS, the Cisco QoS guide covers DSCP marking and queuing end-to-end.
Production Best Practices
Document your community scheme before you deploy a single value. Create a table: ASN, community value, policy effect. Share it with every team that touches BGP. Undocumented communities become landmines during incidents.
Strip communities from untrusted customers on inbound. A customer should not be able to set no-export on their routes and inadvertently affect your backbone routing:
route-map CUSTOMER_IN permit 10
set community none
set community 65001:customer additive
Use soft-clear after policy changes. After modifying a route-map or community-list, use soft in or soft out instead of a hard reset:
Router# clear ip bgp 203.0.113.1 soft out
Soft resets re-advertise outbound routes with updated policy without dropping the session or re-exchanging the full table.
Automate community tagging at scale. In larger networks, manual community management doesn’t hold up. The Python automation guide covers Netmiko and NAPALM for pulling BGP table data and pushing route-map changes programmatically — critical for RTBH automation where response time matters.
Troubleshooting Checklist
When communities aren’t behaving as expected, work through these in order:
- Is
send-communityconfigured? —show bgp neighbors 203.0.113.1 | include Community - Is the route-map applied to the neighbor? —
show bgp neighbors 203.0.113.1 | include route map - Does the route match the community-list or prefix-list? —
show bgp ipv4 unicast 198.51.100.0/24and verify the community is in the path attributes - Are communities being stripped by an inbound policy on the peer side? — Ask your peer; they may be running
set community none - Is the route-map missing a catch-all? — A missing final permit silently drops anything that didn’t match
Router# debug ip bgp 203.0.113.1 updates
*May 18 09:15:32.451: BGP(0): 203.0.113.1 rcvd UPDATE w/ attr: nexthop 203.0.113.1,
origin i, metric 0, path 65002, community 65001:100 65002:50
*May 18 09:15:32.452: BGP(0): 203.0.113.1 rcvd 198.51.100.0/24
Apply BGP debug with a neighbor filter in production — debug ip bgp 203.0.113.1 updates rather than globally — to avoid flooding your log buffer on a high-traffic session.
Wrapping Up
BGP communities give you a clean, scalable way to carry policy intent alongside your routes. Tag once, match everywhere — whether you’re traffic-engineering with MED, protecting yourself with RTBH, or keeping backup routes properly de-preferred. The configs here are production-ready starting points; adapt the community values and prefix-lists to your actual ASN and addressing plan.
If you’re newer to BGP, revisit the BGP fundamentals post before going deeper here. Next up: MPLS/L3VPN on IOS-XE, where communities and route-targets converge to build actual multi-tenant VPNs.
