BGP Communities and Route Filtering on Cisco IOS-XE: Traffic Engineering the Right Way
Networking Technology

BGP Communities and Route Filtering on Cisco IOS-XE: Traffic Engineering the Right Way

Sarah Chen
10 min read

BGP Communities and Route Filtering on Cisco IOS-XE: Traffic Engineering the Right Way

BGP is the protocol that glues the internet together — but raw BGP without communities and route filtering is a liability. Communities let you tag routes with meaning, filter them at scale, and engineer traffic without managing thousands of individual prefix-lists. Route filtering gives you the policy enforcement to make sure only the right routes go to the right places.

This guide covers BGP communities in depth — standard, extended, and large — plus practical route filtering with prefix-lists, AS-path filters, and route-maps, all on Cisco IOS-XE with real show command output. If you’re managing an ISP edge, a multi-homed enterprise, or just want full control over your BGP topology, this is the playbook.

If you’re new to BGP fundamentals, start with our BGP deep dive first, then come back here.

What Are BGP Communities?

A BGP community is a 32-bit tag attached to a route advertisement. Communities are transitive attributes — they travel with the route from peer to peer — and routers can act on them via route-maps. Think of them as labels: “this route is for customers only,” “don’t re-advertise this upstream,” “send this over the backup link.”

Standard communities use the format AA:NN where AA is the AS number and NN is a locally defined value. Extended communities add a 64-bit space for more granular tags (widely used with MPLS VPNs). Large communities, defined in RFC 8092, give you a 96-bit space (ASN:LocalData1:LocalData2) — ideal for multi-AS environments.

Well-Known Communities

Four communities are defined in RFC 1997 and recognized universally:

  • NO_EXPORT (0xFFFFFF01) — Don’t advertise beyond the local AS or confederation boundary
  • NO_ADVERTISE (0xFFFFFF02) — Don’t advertise to any BGP peer
  • LOCAL_AS (0xFFFFFF03) — Don’t export outside the local sub-AS (confederation use)
  • INTERNET (0x00000000) — Advertise to the entire internet (default implied behavior)

Enabling BGP Community Propagation

Communities are stripped by default on eBGP sessions unless you explicitly enable them. Miss this and your communities disappear the moment a route leaves your AS.

! Always enable this on eBGP peers that should carry community attributes
router bgp 65000
 neighbor 203.0.113.1 send-community both
 neighbor 203.0.113.1 send-community extended

The both keyword sends standard and extended communities. If you’re using large communities, add:

router bgp 65000
 neighbor 203.0.113.1 send-community large

Verify community propagation is configured:

Router# show bgp neighbors 203.0.113.1 | include Community
  Community attribute sent to this neighbor(standard & extended)

Setting Communities with Route-Maps

Route-maps are the engine. They match routes (by prefix, AS-path, community, etc.) and set attributes — including communities — before the route is advertised or after it’s received.

Tagging Customer Routes

A common pattern: tag all routes learned from customer peers with a community your entire AS understands.

! Define the route-map applied to customer inbound
route-map CUST-IN permit 10
 match ip address prefix-list CUST-PREFIXES
 set community 65000:100 additive

route-map CUST-IN permit 20
 ! Permit everything else without modification

! Apply to the customer neighbor
router bgp 65000
 neighbor 192.168.10.1 route-map CUST-IN in

The additive keyword appends the community to existing communities instead of replacing them — critical when routes already carry tags from downstream peers.

Setting NO_EXPORT on Transit Routes

! Prevent a specific prefix from leaking to upstream ISPs
route-map SET-NO-EXPORT permit 10
 match ip address prefix-list INTERNAL-AGGREGATE
 set community no-export

route-map SET-NO-EXPORT permit 20

router bgp 65000
 neighbor 10.0.0.1 route-map SET-NO-EXPORT out

Verify the community is set:

Router# show bgp 192.0.2.0/24 detail
BGP routing table entry for 192.0.2.0/24, version 42
Paths: (1 available, best #1, table default, not advertised to eBGP peer)
  Not advertised to any peer
  Local
    0.0.0.0 from 0.0.0.0 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      Community: no-export

Route Filtering with Prefix-Lists

Prefix-lists are faster and more readable than access-lists for BGP filtering. They match on network address and prefix length, with support for ge (greater-than-or-equal) and le (less-than-or-equal) operators.

Block Bogon Routes (RFC 5735)

! Deny private/bogon prefixes from any eBGP peer
ip prefix-list BOGONS seq 5 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS seq 10 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS seq 15 deny 100.64.0.0/10 le 32
ip prefix-list BOGONS seq 20 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS seq 25 deny 169.254.0.0/16 le 32
ip prefix-list BOGONS seq 30 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS seq 35 deny 192.0.2.0/24 le 32
ip prefix-list BOGONS seq 40 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS seq 45 deny 198.18.0.0/15 le 32
ip prefix-list BOGONS seq 50 deny 198.51.100.0/24 le 32
ip prefix-list BOGONS seq 55 deny 203.0.113.0/24 le 32
ip prefix-list BOGONS seq 60 deny 240.0.0.0/4 le 32
ip prefix-list BOGONS seq 65 deny 0.0.0.0/0 ge 25
ip prefix-list BOGONS seq 100 permit 0.0.0.0/0 le 24

router bgp 65000
 neighbor 203.0.113.1 prefix-list BOGONS in

The final seq 65 denies any prefix longer than /24 from being accepted — a best practice to prevent route hijacks via /25 or longer deaggregates from peers who shouldn’t be sourcing them.

Allow Only Your Own Prefixes Outbound

! Lock down what we advertise to upstream — only our assigned space
ip prefix-list MY-PREFIXES seq 10 permit 203.0.113.0/24
ip prefix-list MY-PREFIXES seq 20 permit 203.0.114.0/23

router bgp 65000
 neighbor 198.51.100.1 prefix-list MY-PREFIXES out

Verify what’s being sent:

Router# show bgp neighbor 198.51.100.1 advertised-routes | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 203.0.113.0/24   0.0.0.0                            32768 i
*> 203.0.114.0/23   0.0.0.0                            32768 i

Total number of prefixes 2

AS-Path Filtering

AS-path access-lists let you filter routes based on the AS_PATH attribute using regular expressions. They’re powerful for blocking routes that transit through specific ASes or that originated in unexpected places.

! Deny routes with an AS-path longer than 5 hops (anti-route-leak)
ip as-path access-list 10 deny _[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_
ip as-path access-list 10 permit .*

! Only accept routes originated by our direct customer (AS 65100)
ip as-path access-list 20 permit ^65100$
ip as-path access-list 20 deny .*

router bgp 65000
 neighbor 192.168.10.1 filter-list 20 in

The regex ^65100$ means the path must start and end with 65100 — originated by the customer’s AS, not merely transiting through it.

Common AS-path regex patterns:

Pattern Matches
^$ Routes originated locally (empty path)
^65100$ Originated by AS 65100, no transit
_65100_ Path contains AS 65100 anywhere
^65100_ First AS in path is 65100
_65100$ Originated by AS 65100 (any path to it)

Community-Based Route Filtering

Community-lists let you match route-map conditions against community values — this is where BGP policy becomes truly scalable.

! Match routes tagged with our "customer" community
ip community-list standard CUSTOMERS permit 65000:100

! Match routes tagged as "backup path" by upstream
ip community-list standard BACKUP-PATH permit 65001:200

! Route-map: set lower local-preference for backup routes
route-map UPSTREAM-IN permit 10
 match community BACKUP-PATH
 set local-preference 80

route-map UPSTREAM-IN permit 20
 set local-preference 100

router bgp 65000
 neighbor 198.51.100.1 route-map UPSTREAM-IN in

Extended Community Lists for MPLS VPNs

If you’re running MPLS L3VPNs, route targets use extended communities — they are the mechanism that binds a VRF on a PE router to the correct set of advertised prefixes:

! Match VPN routes with a specific route-target
ip extcommunity-list standard VPN-CUST permit rt 65000:1000

route-map VPN-IN permit 10
 match extcommunity VPN-CUST
 set local-preference 150

route-map VPN-IN deny 20

Traffic Engineering with Communities

One of the most practical uses of communities is influencing how your upstream ISPs route traffic back to you — without touching their configs. Most ISPs publish a community schema in their looking glass or IRR records.

Common ISP Community Schemes

Typical patterns from major carriers (always check your ISP’s documentation):

  • ISPASSN:100 — Advertise to all peers
  • ISPASSN:200 — Advertise to customers only
  • ISPASSN:300 — Set local-pref 50 (deprioritize)
  • ISPASSN:400 — Prepend 3x before advertising

Influencing Inbound Traffic via AS-PATH Prepending

! Prepend our AS on the secondary link to make primary preferred
route-map SECONDARY-OUT permit 10
 match ip address prefix-list MY-PREFIXES
 set as-path prepend 65000 65000 65000

router bgp 65000
 neighbor 203.0.113.5 route-map SECONDARY-OUT out

Selective Prepend with Communities

A cleaner approach: use community tagging so you can drive prepending logic from a single route-map, matched against community values that your network operations team can set on individual routes:

! Tag routes for 2x prepend
ip community-list standard PREPEND-2X permit 65000:201
! Tag routes for 3x prepend
ip community-list standard PREPEND-3X permit 65000:202

route-map PEER-OUT permit 10
 match community PREPEND-3X
 set as-path prepend 65000 65000 65000

route-map PEER-OUT permit 20
 match community PREPEND-2X
 set as-path prepend 65000 65000

route-map PEER-OUT permit 30
 ! All other routes, no prepend

router bgp 65000
 neighbor 198.51.100.1 route-map PEER-OUT out

Conditional Advertisement with Community Matching

IOS-XE supports advertise-map / non-exist-map conditional advertisements — advertise a prefix only when another prefix exists in the BGP table:

! Only advertise the summary if both component routes exist
route-map SUMMARY-ADV permit 10
 match ip address prefix-list SUMMARY-ROUTE

route-map COMPONENT-CHECK permit 10
 match ip address prefix-list COMPONENT-ROUTES

router bgp 65000
 neighbor 198.51.100.1 advertise-map SUMMARY-ADV exist-map COMPONENT-CHECK

Troubleshooting BGP Communities and Filters

Check Routes Received from a Peer

Router# show bgp neighbors 203.0.113.1 received-routes | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*  10.0.0.0/24      203.0.113.1              0             0 65100 i
*  192.0.2.0/24     203.0.113.1              0             0 65100 65200 i

Note: received-routes requires neighbor X.X.X.X soft-reconfiguration inbound to be configured, or use show bgp neighbors X.X.X.X routes (post-policy view). The same adjacency troubleshooting discipline applies to OSPF — see our OSPF troubleshooting guide for complementary techniques when your IGP is misbehaving underneath BGP.

Check Community on a Specific Prefix

Router# show bgp 203.0.113.0/24
BGP routing table entry for 203.0.113.0/24, version 88
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1          2
  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:201
      rx pathid: 0, tx pathid: 0x0

Verify Prefix-List Hits

Router# show ip prefix-list BOGONS
ip prefix-list BOGONS: 13 entries
   seq 5 deny 0.0.0.0/8 le 32 (hit count: 0, refcount: 1)
   seq 10 deny 10.0.0.0/8 le 32 (hit count: 3, refcount: 1)
   seq 15 deny 100.64.0.0/10 le 32 (hit count: 0, refcount: 1)
   ...
   seq 100 permit 0.0.0.0/0 le 24 (hit count: 847, refcount: 1)

Debug Route Policy (Use Carefully in Production)

! Enable only for a specific neighbor, brief window
Router# debug ip bgp 203.0.113.1 updates

! Better: use route-map debugs on IOS-XE 16.9+
Router# debug ip bgp policy

Soft Reset Without Dropping the Session

! Inbound soft reset (requires soft-reconfiguration inbound)
Router# clear ip bgp 203.0.113.1 soft in

! Outbound soft reset (no extra config needed)
Router# clear ip bgp 203.0.113.1 soft out

! Reset all peers without dropping sessions
Router# clear ip bgp * soft

Production Checklist

  • Enable send-community on all eBGP peers that should carry community attributes — it’s off by default and the most common oversight
  • Filter bogons inbound on all eBGP sessions. No exceptions.
  • Whitelist your own prefixes outbound — explicit permit only what you originate
  • Document your community schema in your IRR/RPSL records and internal wiki
  • Use additive when setting communities in inbound route-maps to preserve upstream tags
  • Audit with show bgp X prefix detail after any policy change before triggering a soft reset
  • Stage policy changes against a lab session using neighbor X.X.X.X shutdown + no shutdown if soft-reconfiguration isn’t enabled

For teams that manage multiple routers, consider automating these policy templates with Python and Netmiko — see our Python network automation guide for a repeatable workflow.

Final Thoughts

BGP communities and route filtering are where network engineering gets surgical. Standard communities give you coarse signaling — NO_EXPORT, traffic engineering hints. Extended and large communities let you encode intent at scale across an entire provider network. And prefix-lists with AS-path filters are the enforcement layer that keeps your routing table clean and your announcements honest.

The biggest mistake engineers make is skipping the send-community knob on new eBGP sessions and wondering why their policy tags disappeared downstream. The second biggest is filtering only on outbound — inbound filtering is just as critical to prevent your table from being poisoned with bogons or /32 deaggregates.

Get these building blocks right and you’ll have a BGP policy framework you can extend without touching a hundred neighbor statements. Communities do the heavy lifting — you just write the route-maps once.

For a broader look at how Cisco IOS-XE compares to IOS and IOS-XR in terms of feature availability, see our Cisco IOS vs IOS-XE vs IOS-XR comparison.

Enjoying this post?

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