BGP Communities: Well-Known Values and Cisco Configuration

BGP communities are the tagging system that makes policy scalable: instead of matching hundreds of individual prefixes with ACLs or regexes, you attach a community to a route and let neighbors (or your own route-maps) act on the tag. Some communities are well-known with standardized meaning; most are operator-defined conventions like "set local-pref 110 toward this upstream". This guide covers well-known values, enabling community exchange, and the Cisco IOS route-map workflow for setting and matching communities.

Well-Known Community Values

A standard community is a 32-bit value, conventionally written AS:value (e.g. 65001:100). Extended communities (64-bit, RFC 4360) add structure - Route Targets (rt:) drive MPLS L3VPN import/export, and Site of Origin (soo:) prevents loops in multi-homed VPN sites.

Standard, Extended and Large Communities

BGP communities come in three wire formats, and mixing them up is the fastest way to write a policy that silently does nothing:

• Standard (32-bit, RFC 1997). The classic AS:value pair, each half 16 bits. Well-known values live in the reserved AS 65535 range. Cheap to carry, universally understood, and still the workhorse for traffic engineering and RTBH.
• Extended (64-bit, RFC 4360). Structured as type:subtype:value. Route Targets (rt:) and Site of Origin (soo:) are the two you meet constantly in MPLS L3VPN and EVPN designs. They are not interchangeable with standard communities even when the numbers look similar.
• Large (96-bit, RFC 8092). Three 32-bit fields, normally written global_admin:local1:local2. Designed because a 32-bit standard community cannot encode a 32-bit ASN plus a meaningful operator value - with the 4-byte ASN space in production use, AS:value simply cannot express "which customer" and "which policy" at the same time.

On Cisco IOS, the three types have separate commands: set community / match community, set extcommunity, and set large-community / match large-community. The send-community knob then decides which of them actually leave the box - send-community both covers standard and extended, and large communities are sent with send-community large (platform support varies, so verify with a capture before you depend on it).

Community Lists: Standard vs Expanded and Regex Crafting

A community list is just the match primitive, and it comes in two flavours whose naming confuses everyone at least once. A standard community list matches exact numeric values. An expanded community list matches a regular expression against the textual community string, which is why it can match a whole block of values in one line:

! exact matches only
ip community-list standard CUST-100 permit 65001:100
ip community-list standard CUST-200 permit 65001:200

! regex over the community string - one line covers 65001:100-199
ip community-list expanded CUST-1XX permit ^65001:1[0-9][0-9]$

! blackhole and graceful shutdown, the two operational values you need most
ip community-list standard BLACKHOLE permit 65535:666
ip community-list standard GRACEFUL permit 65535:0

Two traps in that snippet. First, the anchors: without ^ and $ a regex like 65001:10 also matches 65001:100, 65001:1000 and anything else that starts with the same digits, so you accidentally apply a customer's policy to half the table. Second, numbering: standard and expanded lists share one namespace, so you cannot have ip community-list standard 10 and ip community-list expanded 10 at the same time - name your lists on modern IOS, it is far easier to audit.

Community lists are also the one match primitive where a deny statement behaves in a way that surprises people: a community list used inside a route-map clause denies routes that carry a community matching an explicit deny entry (that part is obvious), but a route that carries no communities at all never matches a community list, so it slides straight through. That is usually what you want for a filter applied only to tagged customer routes, and exactly the wrong thing if you intended "drop everything I did not explicitly permit".

Large Communities in Configuration

If your network uses 4-byte ASNs, or if you want to carry both a customer identifier and a policy identifier, large communities are the correct tool. The syntax mirrors the standard workflow:

ip large-community-list standard LC-CUST permit 4200000001:100:10
ip large-community-list expanded LC-PREF permit ^4200000001:100:[0-9]+$

route-map TAG-LARGE permit 10
 match ip address prefix-list LAB-PREFIXES
 set large-community 4200000001:100:10 additive
!
router bgp 65001
 neighbor 203.0.113.2 send-community large
 neighbor 203.0.113.2 route-map TAG-LARGE out

Internally, the same value is written in the route announcement as large:4200000001:100:10. Note that additive matters even more here than with standard communities: replacements silently strip a customer's inbound tags when the route is re-advertised, and that is very hard to see after the fact.

Step 1: Enable Community Exchange

Cisco IOS does not send communities to neighbors unless told to:

router bgp 65001
 neighbor 203.0.113.2 send-community
 neighbor 10.10.10.2 send-community both   ! standard + extended

Without send-community, tags silently never leave the router - the most common "my communities do nothing" cause.

Step 2: Set Communities with a Route-Map

ip prefix-list LAB-PREFIXES permit 10.10.0.0/16 le 24

route-map TAG-INTERNAL permit 10
 match ip address prefix-list LAB-PREFIXES
 set community 65001:100 no-export additive
!
router bgp 65001
 neighbor 10.10.10.2 route-map TAG-INTERNAL out

additive appends to any existing communities; without it, the set replaces them all. The well-known names (no-export, no-advertise) are accepted directly in set community.

Step 3: Match Communities for Filtering or Policy

ip community-list standard CUST-100 permit 65001:100
ip community-list expanded CUST-1XX permit ^65001:1[0-9][0-9]$

route-map FILTER-BY-COMMUNITY deny 10
 match community CUST-100
route-map FILTER-BY-COMMUNITY permit 20
!
router bgp 65001
 neighbor 203.0.113.2 route-map FILTER-BY-COMMUNITY in

Standard community lists match exact values; expanded lists use regex over the community string. Route-maps then act on matches - typical actions are set local-preference, set as-path prepend, or deny (filtering).

Real-World Conventions

• Traffic engineering with upstreams: <ISP-AS>:90/100/110 tells the ISP to set local-pref 90 (less preferred), 100 (normal) or 110 (preferred); <ISP-AS>:302/303 asks for 2x/3x prepend.
• RTBH: tag an attacked /32 with the blackhole community (e.g. 65535:666); the upstream null-routes it at the edge.
• Regional scoping: e.g. 65000:1000 = US-only, 65000:2000 = EU-only, combined with no-export so the route never leaves the region.
• MPLS L3VPN: VRFs import/export via route-target extended communities, and SoO prevents a site's routes from being reflected back.

Designing Your Own Scheme: A Workable Numbering Plan

Real deployments rarely get to invent a clean sheet - but if you do, or if you are consolidating three inherited tagging conventions, a plan with fixed fields beats ad-hoc numbers. A widely used pattern keeps the origin AS in the left half and reserves blocks in the right half:

Two rules make a plan like this survivable. First, write it down in a table that engineers can find, and keep the table in the same repository as the route-map templates so policy and documentation change together. Second, reserve a block for future use and say so explicitly - the value of a plan is not that it is clever, it is that two engineers on different teams invent the same tag for the same job.

Verification: Prove the Community Actually Left the Router

Communities are invisible in a plain show ip bgp unless you ask for them, which is why so many community bugs survive until someone does a packet capture. Three commands do the work:

show ip bgp 10.10.1.0/24
show ip bgp community 65001:100
show ip bgp community-list CUST-1XX
show ip bgp neighbors 203.0.113.2 advertised-routes | include 65001

For outbound verification, remember that advertised-routes shows what the local router would send, not what the neighbour accepted. If the local view looks right but the far end does not act on the tag, check the far end's inbound policy for a route-map that requires a specific match ip address or that terminates with an implicit deny. A change in inbound policy also needs clear ip bgp 203.0.113.2 soft in before the new policy is evaluated, and outbound changes need clear ip bgp 203.0.113.2 soft out; the soft variants avoid tearing down the session and re-converging the whole table.

Regex problems are the other classic verification failure. Expanded community lists are evaluated against the community string as IOS renders it, so a value learned as 65001:100 inside an AS-path list context may be shown differently in a route reflector's output. When a regex does not behave, mirror the exact output of show ip bgp <prefix> into a scratch list and test it before touching production policy.

Common Mistakes to Avoid

• Forgetting send-community. The route-map is perfect, the tags never leave the box, and the neighbour sees untagged routes. Also check this on iBGP sessions - route reflectors strip nothing by default, but plenty of templates disable community propagation for "cleanliness" and then wonder why VPN route targets stopped working.
• Replacing instead of appending. set community 65001:100 without additive wipes existing tags on that route. Multi-vendor designs that layer tags (region + customer + policy) break the moment one hop replaces rather than appends.
• Assuming well-known values are enforced across an AS boundary as written. no-export means "do not advertise to an eBGP peer"; a confederation or a route server design changes what counts as eBGP. Test it in the lab before relying on it to contain a prefix.
• Tagging without a documented convention. A scheme where 65001:100 is "customer A" in one template and "prefer this upstream" in another is worse than no communities at all. Write the numbering plan down, including the reserved ranges, and keep it in the same repo as your route-map templates.
• Using communities for something in-band instead of the blackhole route itself. RTBH only works when the upstream has a static route pointing at an iBGP advertisement of the tagged host route. The community carries the signal; the route carries the action.

Where Communities Sit in the Policy Chain

Communities do not act on their own - they are inputs to the decision chain. The match happens in a route-map, the resulting action (local-preference, AS-path prepend, metric, next-hop) feeds into the best-path decision, and prefix hygiene tools like flap damping clean up the aftermath when an upstream misbehaves. That ordering is worth keeping in mind when a tag "does not work": usually the community is present and correct, and the route-map that was supposed to consume it is applied in the wrong direction, or a later clause in the same sequence overwrites the action.

Communities interact with the rest of BGP policy machinery: route-maps and prefix-lists for matching (see our prefix-list and route-map guide), the best-path algorithm that applies local-pref early in the decision, and route dampening (penalty and reuse limits) for flapping-prefix hygiene.

For the vendor-specific variants of these patterns on other platforms, see the Arista EOS BGP configuration guide and the FRRouting BGP walkthrough on Linux. If you use communities to steer traffic out of a dual-homed site, the best-external and add-path guide covers the path-advertisement side of the same problem.

原文链接：https://awjunaid.com/cisco/how-to-configure-bgp-communities-on-cisco-routers-complete-guide-with-examples