Auto Draft
Networking Technology

BGP Communities and Route Filtering on Cisco IOS-XE: A Practical Engineer’s Guide

Sarah Chen
10 min read

BGP carries the internet’s routing table, but raw prefixes alone aren’t enough for the complex policy decisions that real networks require. BGP communities are the mechanism that lets you attach metadata to routes — tagging them by origin, relationship, or intended treatment — so every router in the path can apply consistent policy without hardcoding lengthy prefix-lists everywhere.

If you’ve ever wondered how a large ISP tells its upstream providers “don’t re-advertise this to other peers,” or how a DDoS mitigation service can signal a blackhole with a single community tag, this post walks through the full picture: community types, IOS-XE configuration, community-list matching, practical use cases, and verification commands.

We’ll assume you already understand the BGP path selection process and neighbor relationships. If you need a refresher, check out our BGP fundamentals deep dive before reading on.

BGP Community Types at a Glance

Three distinct community types exist in the wild today, each solving a slightly different problem:

  • Standard communities (RFC 1997) — 32-bit values displayed as AS:value (e.g., 65000:100). The most common format; well-known communities live in this space.
  • Extended communities (RFC 4360) — 64-bit values used primarily for MPLS VPN route targets (RT:ASN:value) and traffic-engineering use cases.
  • Large communities (RFC 8092) — Three 32-bit fields (GlobalASN:LocalData1:LocalData2), solving the 2-byte ASN limitation and enabling richer semantics. Increasingly common at large ISPs.

Within standard communities, four well-known communities are defined by IANA and understood by all BGP implementations:

Community Numeric Value Behavior
internet 0:0 Advertise to all BGP peers (default)
no-export 65535:65281 Do not advertise outside the AS (or confederation boundary)
no-advertise 65535:65282 Do not advertise to any BGP peer
local-as 65535:65283 Keep within the local sub-AS (confederation sub-AS only)

Enabling Community Propagation on IOS-XE

Communities are not sent by default on Cisco IOS-XE. You must explicitly enable them per neighbor. This is the single most common misconfiguration that causes community tagging to silently fail.

! Enable community propagation to an eBGP peer
router bgp 65000
 neighbor 203.0.113.1 remote-as 65100
 neighbor 203.0.113.1 send-community both
 !
 ! For iBGP sessions, communities propagate by default once send-community is set
 neighbor 10.0.0.2 remote-as 65000
 neighbor 10.0.0.2 send-community both

The both keyword sends both standard and extended communities. Use standard, extended, or large if you need to be selective. Also enable the human-readable community display format:

! IOS-XE: show communities as AA:NN instead of large integers
ip bgp-community new-format

Without this, 65000:100 displays as the raw 32-bit decimal 4259840100 — unreadable.

Setting Communities with Route-Maps

Route-maps are the mechanism for attaching communities to outbound advertisements or to routes received from a peer. Here’s a complete example for an ISP tagging routes by customer relationship:

! Define community values as references
ip community-list standard CUSTOMERS permit 65000:100
ip community-list standard PEERS     permit 65000:200
ip community-list standard TRANSIT   permit 65000:300

! Route-map: tag routes learned from a customer
route-map TAG_CUSTOMER_IN permit 10
 set community 65000:100 additive
!
! Route-map: tag routes learned from a peer
route-map TAG_PEER_IN permit 10
 set community 65000:200 additive
!
! Apply to neighbors
router bgp 65000
 neighbor 198.51.100.5 remote-as 64510
 neighbor 198.51.100.5 route-map TAG_CUSTOMER_IN in
 neighbor 198.51.100.5 send-community both
 !
 neighbor 192.0.2.20 remote-as 64520
 neighbor 192.0.2.20 route-map TAG_PEER_IN in
 neighbor 192.0.2.20 send-community both

The additive keyword is critical: without it, set community replaces any existing communities on the route. With additive, the new value is appended to the existing list. Almost always use additive unless you specifically want to strip and replace.

Matching Communities for Outbound Filtering

The real power comes when you use community tags to drive outbound policy. Here’s a common ISP pattern: customer routes get sent to all peers and upstreams, peer routes don’t get sent to other peers, and transit routes get no-export tagged.

! Match community lists for outbound policy
ip community-list standard CUSTOMERS permit 65000:100
ip community-list standard PEERS     permit 65000:200
ip community-list standard TRANSIT   permit 65000:300

! Outbound route-map applied to all eBGP peers
route-map EXPORT_POLICY permit 10
 ! Always send customer routes
 match community CUSTOMERS
 set community 65000:100 additive
!
route-map EXPORT_POLICY permit 20
 ! Send peer routes only to customers/upstreams, not to other peers
 ! (We'll deny this for peer neighbors via separate route-map)
 match community PEERS
!
route-map EXPORT_POLICY deny 30
 ! Block transit routes from being re-advertised
 match community TRANSIT
!
route-map EXPORT_POLICY permit 100
 ! Permit everything else (our own originated prefixes)

Then apply different route-maps to peer vs. transit neighbors:

router bgp 65000
 ! To an upstream transit provider — send everything
 neighbor 198.51.100.1 remote-as 1299
 neighbor 198.51.100.1 route-map EXPORT_TO_TRANSIT out
 neighbor 198.51.100.1 send-community both
 !
 ! To a peering partner — don't send peer or transit routes
 neighbor 192.0.2.5 remote-as 20965
 neighbor 192.0.2.5 route-map EXPORT_TO_PEER out
 neighbor 192.0.2.5 send-community both

Standard Community List Types: Standard vs. Expanded

IOS-XE supports two community-list types with an important behavioral difference:

! Standard community-list: matches exact community values
ip community-list standard MATCH_EXACT permit 65000:100 65000:200

! Expanded community-list: matches using regular expressions
ip community-list expanded MATCH_65000 permit 65000:.*
ip community-list expanded MATCH_BLACKHOLE permit 65535:666

Standard lists are faster (hash lookup) and preferred when you know the exact values. Expanded lists use regex and are useful for matching ranges — for example, any community where the first field is your own ASN.

Practical Use Case: Remotely Triggered Black Hole (RTBH)

RTBH is one of the most operationally valuable uses of BGP communities. When your network is under a DDoS attack, you signal a community on a /32 prefix to instruct upstream providers (or your own edge routers) to drop all traffic destined to the victim IP at their edge — before it saturates your links.

Here’s a self-contained RTBH implementation for a network operator:

! Step 1: Create a static route pointing to Null0 for the blackhole trigger address
ip route 192.0.2.1 255.255.255.255 Null0

! Step 2: Route-map that sets the RTBH community and redirects next-hop
route-map RTBH_TRIGGER permit 10
 match ip address prefix-list RTBH_PREFIXES
 set ip next-hop 192.0.2.1
 set community no-export 65535:666 additive
 set local-preference 200

! Step 3: Prefix-list for the prefixes that need blackholing
ip prefix-list RTBH_PREFIXES seq 10 permit 203.0.113.55/32

! Step 4: Apply inbound on an iBGP session from a trigger router
router bgp 65000
 neighbor 10.0.0.10 remote-as 65000
 neighbor 10.0.0.10 route-map RTBH_TRIGGER in
 neighbor 10.0.0.10 send-community both

! Step 5: On receiving routers, match the community and null-route
route-map RTBH_RECEIVE permit 10
 match community RTBH
 set ip next-hop 192.0.2.1

ip community-list standard RTBH permit 65535:666
ip route 192.0.2.1 255.255.255.255 Null0 254

The no-export community ensures the blackhole prefix doesn’t leak to your upstream providers unless that’s intentional for upstream RTBH signaling.

Large Communities for 4-Byte ASN Networks

Standard communities use a 16-bit AS field. Networks with 4-byte ASNs (ASNs above 65535) can’t fit their ASN in the standard community format. RFC 8092 large communities solve this with three 32-bit fields:

! Large community: GlobalASN:LocalData1:LocalData2
! Example: ASN 131072 (a 4-byte ASN) tagging customer routes
route-map TAG_LARGE_COMMUNITY permit 10
 set large-community 131072:100:1 additive

! Match on large communities
ip large-community-list standard LC_CUSTOMERS permit 131072:100:1

route-map FILTER_ON_LC permit 10
 match large-community LC_CUSTOMERS

! Verification
show bgp ipv4 unicast large-community 131072:100:1
show bgp ipv4 unicast neighbors 10.0.0.1 advertised-routes

Large communities are also useful for encoding richer semantics: GlobalASN:Action:Parameter where action might be 100 for “set local-pref” and parameter is the actual value.

Verification and Troubleshooting Commands

These are the commands you’ll use most frequently when debugging community policy:

! Show all routes with a specific community
show bgp ipv4 unicast community 65000:100

! Show communities on a specific prefix
show bgp ipv4 unicast 203.0.113.0/24

! Show routes advertised to a specific neighbor (with communities)
show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes

! Show routes received from a neighbor
show bgp ipv4 unicast neighbors 203.0.113.1 received-routes

! Filter routes by community regex (expanded community matching)
show bgp ipv4 unicast community-list MATCH_65000

! Debug community policy application (use sparingly in production)
debug ip bgp 203.0.113.1 updates

Sample output from show bgp ipv4 unicast 198.51.100.0/24:

BGP routing table entry for 198.51.100.0/24, version 412
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     3
  Refresh Epoch 1
  65100
    203.0.113.1 from 203.0.113.1 (203.0.113.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 65000:100 65000:200
      rx pathid: 0, tx pathid: 0x0
  65200 65100
    192.0.2.20 from 192.0.2.20 (192.0.2.20)
      Origin IGP, metric 0, localpref 50, valid, external
      Community: 65000:200
      rx pathid: 0, tx pathid: 0

Common Gotchas

Several community-related issues appear repeatedly in production:

Forgetting send-community — Communities you set in a route-map are silently dropped before the update leaves the router if this is missing. Always verify with show bgp neighbors X.X.X.X | include community.

Using set community without additive — This strips all existing communities and replaces them. Routes that arrived with no-export will lose that tag, potentially causing prefix leaks.

Expanded community-list regex anchoring — The regex operates on the community string representation. 65000:1 would match 65000:10, 65000:100, etc. Anchor with ^65000:1$ when you need exact matches inside expanded lists.

New-format not enabled — If you set 65000:100 but the router was configured before ip bgp-community new-format was enabled, the community may be stored as a decimal integer. Clear BGP sessions and verify display format after enabling.

Route reflectors dropping communities — By default, route reflectors preserve communities. But if a non-RR iBGP router in the path has a route-map that calls set community without additive, communities get wiped. Trace the path hop-by-hop with show bgp on each router.

Putting It All Together: A Complete Policy Example

Here’s a complete, production-style configuration for a dual-homed enterprise with two transit providers and one peering connection. If you’re also running automation to manage your BGP configurations at scale, the Netmiko/NAPALM/Nornir automation guide covers how to template and deploy configurations like this programmatically. For IOS-XE-specific differences from classic IOS, see our IOS vs IOS-XE vs IOS-XR comparison.

ip bgp-community new-format

! Community definitions
ip community-list standard FROM_TRANSIT1  permit 65000:1001
ip community-list standard FROM_TRANSIT2  permit 65000:1002
ip community-list standard FROM_PEER      permit 65000:2001
ip community-list standard BLACKHOLE      permit 65535:666

! Inbound: tag all routes by source
route-map TRANSIT1_IN permit 10
 set community 65000:1001 additive
 set local-preference 80

route-map TRANSIT2_IN permit 10
 set community 65000:1002 additive
 set local-preference 80

route-map PEER_IN permit 10
 set community 65000:2001 additive
 set local-preference 120

! Outbound to transit: send our prefixes only, no learned routes
ip prefix-list OWN_PREFIXES seq 10 permit 198.51.100.0/22 le 24

route-map EXPORT_TO_TRANSIT permit 10
 match ip address prefix-list OWN_PREFIXES
 set community no-export 65000:100 additive

route-map EXPORT_TO_TRANSIT deny 100

! Outbound to peers: send our prefixes + customer routes, not transit
route-map EXPORT_TO_PEER permit 10
 match ip address prefix-list OWN_PREFIXES

route-map EXPORT_TO_PEER deny 20
 match community FROM_TRANSIT1

route-map EXPORT_TO_PEER deny 30
 match community FROM_TRANSIT2

route-map EXPORT_TO_PEER permit 100

! BGP process
router bgp 65000
 bgp router-id 198.51.100.1
 !
 neighbor 203.0.113.1 remote-as 1299
 neighbor 203.0.113.1 description Transit-Provider-1
 neighbor 203.0.113.1 send-community both
 neighbor 203.0.113.1 route-map TRANSIT1_IN in
 neighbor 203.0.113.1 route-map EXPORT_TO_TRANSIT out
 !
 neighbor 203.0.113.5 remote-as 3356
 neighbor 203.0.113.5 description Transit-Provider-2
 neighbor 203.0.113.5 send-community both
 neighbor 203.0.113.5 route-map TRANSIT2_IN in
 neighbor 203.0.113.5 route-map EXPORT_TO_TRANSIT out
 !
 neighbor 192.0.2.1 remote-as 20965
 neighbor 192.0.2.1 description IX-Peer
 neighbor 192.0.2.1 send-community both
 neighbor 192.0.2.1 route-map PEER_IN in
 neighbor 192.0.2.1 route-map EXPORT_TO_PEER out

Final Thoughts

BGP communities are one of those features that look simple on paper but become genuinely powerful once you start using them systematically. The pattern of “tag everything on ingress, filter on egress using community matches” scales well from a two-router enterprise setup to a full-blown ISP with thousands of BGP sessions. Start with inbound tagging, verify communities are propagating correctly with show bgp, and build your outbound policy on top of the tags rather than duplicating prefix-lists everywhere.

The well-known communities — especially no-export — are your safest tools for controlling prefix leakage. RTBH is worth implementing even if you never expect a DDoS, because when you need it, you need it fast. And if you’re running 4-byte ASNs or need richer policy semantics, large communities are the right tool.

Next up: MPLS L3VPN configuration on IOS-XE, where extended communities (route targets) drive the entire forwarding plane.

Enjoying this post?

Get more guides like this delivered straight to your inbox. No spam, just tech and trails.