How to Configure BGP Communities on Cisco Routers: Complete Guide with Examples

BGP communities are one of those features that seem optional right up until you’re managing routes across multiple providers, regions, or policy zones — at which point they become indispensable. A community is essentially a tag you attach to a route so that downstream routers, or your own routers further along the path, can make policy decisions without needing to know the specific prefix. This guide covers everything from basic community concepts to well-known communities, extended communities, and real-world route-map based policy design on Cisco routers.

What BGP Communities Actually Are

A BGP community is a 32-bit value (commonly displayed as two 16-bit numbers separated by a colon, e.g., 65001:100) attached to a route as a path attribute. Multiple communities can be attached to a single route. Routers along the path can then match on these community values in route-maps to apply policy — set local preference, filter the route, prepend AS paths, or decide whether to advertise it further.

The power of communities is abstraction: instead of every router in a large network needing an explicit prefix list for every policy decision, you tag routes once at the edge and let downstream policy simply match the tag.

Well-Known Communities

Cisco IOS supports several standard well-known communities out of the box:

• no-export (65535:65281) — route should not be advertised outside the local AS (or confederation).
• no-advertise (65535:65282) — route should not be advertised to any BGP peer at all.
• local-AS (65535:65283) — route stays within the local (sub-)AS in confederation scenarios.
• internet — implicit; the route can be advertised to any peer (this is the default, no explicit tag).

Step 1: Enable Community Support in BGP

By default, Cisco IOS does not send community attributes to peers — you must explicitly enable it per neighbor:

Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 remote-as 65002
Router(config-router)# neighbor 203.0.113.2 send-community

For extended communities (used with VPNv4/MPLS VPN, route-target based policies):

Router(config-router)# neighbor 203.0.113.2 send-community extended

Or both standard and extended:

Router(config-router)# neighbor 203.0.113.2 send-community both

Step 2: Tag Routes With Communities Using Route-Maps

Router(config)# route-map SET-COMMUNITY permit 10
Router(config-route-map)# match ip address prefix-list CUSTOMER-ROUTES
Router(config-route-map)# set community 65001:100

Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 route-map SET-COMMUNITY out

The corresponding prefix-list:

Router(config)# ip prefix-list CUSTOMER-ROUTES seq 10 permit 198.51.100.0/24

Setting Multiple Communities

Router(config)# route-map SET-COMMUNITY permit 10
Router(config-route-map)# set community 65001:100 65001:200 additive

The additive keyword is important — without it, each set community statement replaces any previously set communities rather than adding to them.

Practical Example: Multi-Homed Enterprise Traffic Engineering

Consider an enterprise multi-homed to two ISPs (ISP-A and ISP-B), wanting to prefer ISP-A for inbound traffic on primary prefixes while allowing ISP-B as backup. Rather than relying purely on AS-path prepending (which is coarse), communities let you signal intent more precisely if your providers support community-based policy (many do, and publish documented community values for local preference adjustment, no-export scoping to specific regions, etc.).

route-map TO-ISP-A permit 10
 match ip address prefix-list PRIMARY-PREFIXES
 set community 65001:100
!
route-map TO-ISP-B permit 10
 match ip address prefix-list PRIMARY-PREFIXES
 set community 65001:200
!
router bgp 65001
 neighbor 203.0.113.1 remote-as 64500
 neighbor 203.0.113.1 send-community
 neighbor 203.0.113.1 route-map TO-ISP-A out
 neighbor 198.51.100.1 remote-as 64501
 neighbor 198.51.100.1 send-community
 neighbor 198.51.100.1 route-map TO-ISP-B out

Many transit providers publish community values like 64500:70 to de-preference a route or 64500:80 to prepend — check your specific provider’s published BGP community documentation and apply the equivalent set community statements.

Using no-export and no-advertise

Restricting a route to stay within the local AS:

route-map INTERNAL-ONLY permit 10
 match ip address prefix-list LAB-PREFIXES
 set community no-export

Preventing a route from being advertised to any peer at all, useful for internal-only diagnostic or management prefixes accidentally redistributed into BGP:

route-map BLOCK-ADVERTISEMENT permit 10
 match ip address prefix-list MGMT-PREFIXES
 set community no-advertise

Filtering Routes Based on Community Values

Community lists let you match on community values for filtering, similar to how prefix lists match on prefixes.

Standard Community List

Router(config)# ip community-list standard DENY-BACKUP permit 65001:200

Expanded Community List (Regex-Based)

Router(config)# ip community-list expanded CUSTOMER-COMMS permit ^65001:1[0-9][0-9]$

Applying in a Route-Map for Filtering

route-map FILTER-BACKUP deny 10
 match community DEFAULT-BACKUP
route-map FILTER-BACKUP permit 20
!
router bgp 65001
 neighbor 203.0.113.2 route-map FILTER-BACKUP in

Extended Communities

Extended communities carry more structured information and are heavily used in MPLS L3VPN (route-target, route-origin) but also apply in other contexts:

Router(config)# route-map SET-EXT-COMM permit 10
Router(config-route-map)# set extcommunity rt 65001:100

Verification:

Router# show ip bgp 198.51.100.0/24
BGP routing table entry for 198.51.100.0/24
  Community: 65001:100
  Extended Community: RT:65001:100

Verification Commands

Router# show ip bgp neighbors 203.0.113.2 advertised-routes
Router# show ip bgp community 65001:100
Router# show ip bgp 198.51.100.0/24
Router# show route-map SET-COMMUNITY

Sample output confirming community attachment:

Router# show ip bgp 198.51.100.0/24
BGP routing table entry for 198.51.100.0/24, version 42
Paths: (1 available, best #1, table default)
  65002
    203.0.113.2 from 203.0.113.2 (203.0.113.2)
      Origin IGP, localpref 100, valid, external, best
      Community: 65001:100

Performance Tuning Notes

Community lists, especially expanded (regex-based) ones, are evaluated per-route during route-map processing, so on routers carrying very large BGP tables with complex community-matching policies, regex complexity can measurably affect convergence time during a full table reload or session reset. Where possible, prefer standard community lists with exact-match values over expanded regex lists for high-route-count policies, reserving regex matching for cases that genuinely need pattern flexibility. Tagging routes with communities at the point of origination (rather than re-matching and re-tagging repeatedly at every hop) also reduces redundant route-map processing across a multi-router AS.

Common Configuration Mistakes

• Forgetting send-community — communities won’t reach neighbors at all without this, and there’s no error message warning you; the route simply arrives with no community attribute.
• Forgetting additive when setting multiple communities across multiple route-map sequences — later set community statements silently overwrite earlier ones.
• Using standard community lists when regex matching is actually needed — expanded community lists are required for pattern-based matching.
• Not verifying provider-side community support before relying on it for traffic engineering — always confirm the exact community values and semantics with your upstream provider’s published documentation.
• Mixing up send-community and send-community extended when working with VPNv4 address families, resulting in route-targets not propagating correctly.

Best Practices

1. Establish a documented community numbering scheme across your organization (e.g., ASN:1xx for regional tagging, ASN:2xx for preference signaling) before deploying communities at scale.
2. Always pair set community with additive unless you specifically intend to overwrite existing communities.
3. Use well-known communities (no-export, no-advertise) deliberately and sparingly, documenting exactly why a given prefix is scoped that way.
4. Validate community propagation with show ip bgp neighbors ... advertised-routes after any policy change, rather than assuming the route-map worked as intended.
5. Coordinate community values with upstream/downstream partners in writing, since a misunderstanding here can silently break inbound or outbound traffic engineering.

Troubleshooting Checklist

• Confirm send-community (or send-community both) is configured on the relevant neighbor.
• Confirm the route-map is applied in the correct direction (in vs out).
• Use show route-map NAME to confirm hit counters are incrementing.
• Use show ip bgp community X:Y to confirm which routes actually carry the expected community.
• If a peer isn’t honoring your community-based request, verify with the peer whether they actually support and apply that specific community value.

FAQs

Are BGP communities transitive between autonomous systems? Standard communities are transitive by default unless explicitly filtered — they’ll propagate across AS boundaries unless a router strips them or send-community isn’t configured on a given peer.

Can I use communities purely for internal policy without ever sending them externally? Yes, this is a very common pattern — use communities as internal tags across your own AS for route classification and policy, and simply never enable send-community toward external peers for those specific tags.

What’s the difference between standard and extended communities? Standard communities are a flat 32-bit value; extended communities carry structured type/subtype fields and a larger value space, and are primarily used in MPLS VPN contexts (route-target, route-origin) though they have other uses too.

Do communities affect BGP best-path selection directly? Not directly — communities themselves don’t influence best-path selection. They’re used within route-maps to set attributes (like local preference or AS-path) that do influence best-path selection.

Summary

BGP communities give you a scalable way to tag and classify routes so that policy decisions — whether local preference adjustments, selective advertisement, or provider-requested traffic engineering — can be applied consistently without needing prefix-specific configuration everywhere. The mechanics are straightforward: enable send-community, tag routes via route-maps with set community, and match on those tags elsewhere with community lists. The real value comes from disciplined, documented numbering schemes and careful verification after every policy change.

References

• BGP Community Attribute Configuration: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-16/irg-xe-16-book/bgp-communities.html
• RFC 1997 – BGP Communities Attribute: https://datatracker.ietf.org/doc/html/rfc1997
• RFC 4360 – BGP Extended Communities Attribute: https://datatracker.ietf.org/doc/html/rfc4360