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

What Are BGP Communities — and Why Should You Care?

If you’ve been working with BGP for a while, you’ve probably heard the term “communities” thrown around in conversations about traffic engineering and inter-AS policy. But if you’ve never actually sat down and configured them end-to-end, they can feel a bit abstract. This guide cuts through that: we’ll cover what BGP communities actually are, the three flavors Cisco IOS-XE supports, and how to use them to build real route filtering and traffic engineering policies that actually work in production.

If you’re newer to BGP in general, start with our BGP fundamentals guide first — this post assumes you understand iBGP/eBGP peer relationships, route reflectors, and basic attribute manipulation.

BGP Community Types: Standard, Extended, and Large

Cisco IOS-XE supports three community formats. Each has different use cases and compatibility considerations.

Standard Communities (RFC 1997)

Standard communities are 32-bit values, typically written as AA:NN where AA is the AS number and NN is a locally defined number. For example, a community of 65100:200 tagged on a route might mean “this prefix came from a customer in region 200.”

There are four well-known standard communities defined in RFC 1997:

• internet (0x00000000) — Advertise to all BGP peers. This is the default.
• no-advertise (0xFFFFFF02) — Don’t advertise this route to any BGP peer.
• no-export (0xFFFFFF01) — Don’t advertise outside the local AS (or confederation).
• local-AS (0xFFFFFF03) — Don’t advertise outside the local confederation sub-AS.

Extended Communities (RFC 4360)

Extended communities are 64-bit values and are primarily used for VPNs (Route Targets and Route Distinguishers in MPLS/VRF deployments) and QoS marking. If you’re running L3VPN, you’re already using them whether you know it or not.

Large Communities (RFC 8092)

Large communities are 96-bit values written as ASN:function:value (three 32-bit integers). They were introduced because standard communities break when ASNs are 32-bit (4-byte). If your ASN is above 65535, large communities are the way to go for community-based policies.

For this guide we’ll focus on standard communities — they cover 90% of real-world use cases in enterprise and service provider environments.

Enabling Community Propagation on IOS-XE

The first thing most engineers get wrong: BGP communities are not sent to peers by default. You have to explicitly enable it per neighbor. Without this, you’ll tag routes with communities and wonder why nothing is matching on the other end.

router bgp 65100
 neighbor 192.168.1.2 remote-as 65200
 neighbor 192.168.1.2 send-community both

The both keyword sends both standard and extended communities. Use standard or extended if you only need one type. For large communities:

neighbor 192.168.1.2 send-community large

Check what you’re sending with:

show bgp neighbors 192.168.1.2 | include community

Sample output:

  Community attribute sent to this neighbor(both)
  Extended-community attribute sent to this neighbor(both)

Setting BGP Communities with Route Maps

Communities are set using route maps — either on outbound advertisements or on inbound learned routes. Let’s walk through both scenarios.

Scenario 1: Tag Outbound Prefixes for an Upstream Provider

Suppose you have two upstream ISPs (AS 100 and AS 200) and you want ISP-A to see your prefixes with a community that tells them to prefer your link for certain traffic. You tag specific prefixes before sending them out.

! Define which prefixes to tag
ip prefix-list CUSTOMER-PREFIXES seq 10 permit 10.0.0.0/8 le 24

! Build the route map
route-map SET-COMMUNITY-TO-ISP-A permit 10
 match ip address prefix-list CUSTOMER-PREFIXES
 set community 100:666 additive

route-map SET-COMMUNITY-TO-ISP-A permit 20
 ! Everything else passes unchanged

! Apply outbound to the ISP-A peer
router bgp 65100
 neighbor 203.0.113.1 remote-as 100
 neighbor 203.0.113.1 send-community both
 neighbor 203.0.113.1 route-map SET-COMMUNITY-TO-ISP-A out

The additive keyword appends the community rather than replacing existing ones. Without it, you wipe all existing communities on the prefix — a common gotcha.

Scenario 2: Tag Inbound Routes by Peer Type

This is extremely useful for policy. Tag every route you receive from a peer with a community that identifies where it came from, then use that tag downstream for local preference or filtering decisions.

! Tag all routes from transit ISP with community 65100:100
route-map TAG-TRANSIT-IN permit 10
 set community 65100:100 additive
 set local-preference 100

! Tag all routes from a peering partner with community 65100:200
route-map TAG-PEER-IN permit 10
 set community 65100:200 additive
 set local-preference 150

! Tag customer routes with community 65100:300
route-map TAG-CUSTOMER-IN permit 10
 set community 65100:300 additive
 set local-preference 200

router bgp 65100
 neighbor 198.51.100.1 remote-as 100
 neighbor 198.51.100.1 route-map TAG-TRANSIT-IN in
 neighbor 198.51.100.1 send-community both

 neighbor 203.0.113.5 remote-as 200
 neighbor 203.0.113.5 route-map TAG-PEER-IN in
 neighbor 203.0.113.5 send-community both

Now anywhere inside your network, you can match on 65100:300 to know a route came from a customer, without needing to remember which peer addresses are customers vs. transit — the community carries that context.

Filtering Routes with Community Lists

Once routes are tagged, you match on them using community lists. These work like ACLs but for BGP communities.

Standard Community Lists

! Match a specific community
ip community-list standard TRANSIT-ROUTES permit 65100:100

! Match any peering route
ip community-list standard PEER-ROUTES permit 65100:200

! Match customer routes
ip community-list standard CUSTOMER-ROUTES permit 65100:300

Expanded Community Lists (Regex)

For more flexible matching, expanded community lists support regular expressions:

! Match all communities with our ASN
ip community-list expanded OUR-ROUTES permit 65100:.*

! Match communities ending in :666 (blackhole marker, for example)
ip community-list expanded BLACKHOLE permit .*:666

Using Community Lists in Route Maps

! Block all transit routes from being redistributed into OSPF
route-map NO-TRANSIT-INTO-OSPF deny 10
 match community TRANSIT-ROUTES

route-map NO-TRANSIT-INTO-OSPF permit 20

! Apply to redistribution
router ospf 1
 redistribute bgp 65100 subnets route-map NO-TRANSIT-INTO-OSPF

For pure BGP-to-BGP filtering, use the community list in a route map applied to a neighbor:

! Only advertise customer routes to peers (not transit or peer routes)
route-map PEER-EXPORT-FILTER permit 10
 match community CUSTOMER-ROUTES

! Apply outbound to peering sessions
router bgp 65100
 neighbor 203.0.113.5 route-map PEER-EXPORT-FILTER out

This is a classic service provider pattern: customers get full tables, peers only get your customer prefixes, transit providers get your prefixes plus customers. Communities make this clean and maintainable.

Traffic Engineering with Communities

AS Path Prepending via Community (Upstream-Controlled)

Many upstream ISPs honor specific communities from their customers to influence how they route traffic. For example, a provider might document:

• 100:10 — Prepend AS path once when advertising to peers
• 100:20 — Prepend AS path twice when advertising to peers
• 100:99 — Don’t advertise this prefix to any peer

When you tag your outbound routes with these communities, you’re telling the provider to adjust their outbound advertisement policy for you — without you needing direct access to their routers. This is the entire point of communities in the transit/peering world.

Local Preference via Community for iBGP

Within your AS, use communities received from peers to drive local preference decisions automatically:

! Match community from our WAN router and set local-pref
route-map SET-LOCAL-PREF-FROM-COMMUNITY permit 10
 match community CUSTOMER-ROUTES
 set local-preference 200

route-map SET-LOCAL-PREF-FROM-COMMUNITY permit 20
 match community PEER-ROUTES
 set local-preference 150

route-map SET-LOCAL-PREF-FROM-COMMUNITY permit 30
 match community TRANSIT-ROUTES
 set local-preference 100

route-map SET-LOCAL-PREF-FROM-COMMUNITY permit 40

! Apply to iBGP peers (route reflector clients, etc.)
router bgp 65100
 neighbor 10.0.0.2 route-map SET-LOCAL-PREF-FROM-COMMUNITY in

This ensures all routers in your AS consistently prefer customer routes over peer routes over transit routes, driven by the community tag set at the edge.

Remote Triggered Black Hole (RTBH) with Communities

RTBH is a DDoS mitigation technique where you advertise a /32 host route with a specific community, causing upstream providers (or your own network) to null-route traffic destined for that IP — dropping attack traffic at the edge before it hits your infrastructure.

! Create a blackhole route map
route-map BLACKHOLE-TAG permit 10
 set community no-export 65535:666
 set local-preference 50
 set origin incomplete

! Static route to Null0 as the source
ip route 192.0.2.1 255.255.255.255 Null0

! Redistribute into BGP with the blackhole tag
router bgp 65100
 redistribute static route-map BLACKHOLE-TAG

When you need to blackhole an IP under attack, you simply add the static route to Null0 and the BGP redistribution does the rest. Your upstream peers that honor 65535:666 will null-route the traffic at their edge. Remove the static route when the attack subsides.

Stripping Communities on the Way Out

Sometimes you want to remove communities before sending routes to certain peers — to prevent leaking internal policy markers to the outside world:

! Remove all communities when advertising to transit
route-map STRIP-COMMUNITIES-TRANSIT permit 10
 set community none

router bgp 65100
 neighbor 198.51.100.1 remote-as 100
 neighbor 198.51.100.1 route-map STRIP-COMMUNITIES-TRANSIT out

Or strip only specific communities:

! Remove only internal-use communities before advertising
route-map STRIP-INTERNAL-COMMUNITIES permit 10
 set comm-list OUR-ROUTES delete

The set comm-list ... delete syntax removes communities matching the specified list while leaving others intact. This is useful when you receive communities from customers and want to strip them before re-advertising upstream.

Verification and Troubleshooting

A few essential show commands for debugging community issues:

! See all BGP routes and their communities
show bgp ipv4 unicast community 65100:200

! Check a specific prefix for communities
show bgp ipv4 unicast 10.0.5.0/24

! Sample output:
BGP routing table entry for 10.0.5.0/24, version 42
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 3
  65200 65300
    192.168.1.2 from 192.168.1.2 (192.168.1.2)
      Origin IGP, metric 0, localpref 150, valid, external, best
      Community: 65100:200
      Last update: 00:03:22 ago

! Check which communities you're sending to a neighbor
show bgp neighbors 192.168.1.2 advertised-routes | begin 10.0.5.0

! Debug community matching (use with care in production)
debug ip bgp 192.168.1.2 updates

If communities aren’t propagating, the first thing to check is whether send-community is configured on the peer. The second thing: verify the route map sequence ordering — a permit 10 matching everything will prevent permit 20 from ever being evaluated.

You can also use our Python automation guide with Netmiko to script community auditing across multiple routers — especially useful if you’re managing a large peer set and want to confirm communities are being sent correctly on every session.

Communities in a Real Lab: Putting It All Together

Here’s a condensed, complete config for a dual-homed edge router implementing the patterns from this guide:

! Community Lists
ip community-list standard TRANSIT-ROUTES permit 65100:100
ip community-list standard PEER-ROUTES permit 65100:200
ip community-list standard CUSTOMER-ROUTES permit 65100:300
ip community-list expanded OUR-ROUTES permit 65100:.*

! Tag inbound from transit
route-map TRANSIT-IN permit 10
 set community 65100:100 additive
 set local-preference 100

! Tag inbound from peers
route-map PEER-IN permit 10
 set community 65100:200 additive
 set local-preference 150

! Export filter: only customers to peers
route-map TO-PEER permit 10
 match community CUSTOMER-ROUTES

! Strip internal communities toward transit (don't leak internal policy tags)
route-map TO-TRANSIT permit 10
 set comm-list OUR-ROUTES delete

route-map TO-TRANSIT permit 20

router bgp 65100
 bgp router-id 10.0.0.1
 bgp log-neighbor-changes

 ! Transit ISP
 neighbor 198.51.100.1 remote-as 100
 neighbor 198.51.100.1 description TRANSIT-ISP-A
 neighbor 198.51.100.1 send-community both
 neighbor 198.51.100.1 route-map TRANSIT-IN in
 neighbor 198.51.100.1 route-map TO-TRANSIT out

 ! Peering partner
 neighbor 203.0.113.5 remote-as 200
 neighbor 203.0.113.5 description PEER-PARTNER-B
 neighbor 203.0.113.5 send-community both
 neighbor 203.0.113.5 route-map PEER-IN in
 neighbor 203.0.113.5 route-map TO-PEER out

This gives you a clean, maintainable policy framework: communities track route origin, route maps drive local preference and export filtering, and you have clear visibility into where every prefix came from.

Common Pitfalls

• Forgetting send-community: Communities are stripped by default. Every peer where you need community exchange must have this configured.
• Missing additive: Without it, set community replaces all existing communities rather than appending. Destroys upstream communities your customers may be relying on.
• Route map implicit deny: If you build a route map for community tagging, make sure you have a final permit clause without a match statement to allow unmatched routes through.
• 4-byte ASN communities: Standard community format breaks with 32-bit ASNs. Use large communities if your ASN is above 65535.
• Soft reset after changes: Route map and community list changes don’t take effect automatically on existing sessions. Run clear ip bgp * soft or clear ip bgp neighbor-ip soft in/out to re-evaluate routes without dropping sessions.

For a deeper look at how IOS-XE handles BGP in the context of platform differences across Cisco’s software stack, see our comparison of Cisco IOS vs IOS-XE vs IOS-XR. And if you’re building automation around BGP community verification or policy auditing at scale, our Cisco EEM scripting guide is worth a read for catching community-related issues automatically.

Wrapping Up

BGP communities are one of those features that feel like a “nice to have” until you actually start using them — at which point you wonder how you ever managed route policy without them. Standard communities with well-structured AA:NN numbering give you a clean tagging system that makes routing policy readable, maintainable, and scalable across devices and teams.

The key takeaways: always send-community, always use additive unless you mean to replace, tag at the edge and match in the core, and strip internal markers before handing off to untrusted peers. Get those four habits right and community-based routing policy becomes one of the cleanest parts of your BGP config.