BGP Communities — Tags for Traffic Engineering + Well-Known Values
How BGP communities tag prefixes with metadata that policy uses across ASes. Standard vs extended communities, the four well-known values (no-export, no-advertise, no-export-subconfed, internet), and typical ISP tag patterns.
- **Communities** are 32-bit tags you attach to prefixes. Policy on other routers matches communities to make decisions (accept, deny, adjust preference, blackhole). They travel with the prefix — locally set, remotely acted on.
- **Well-known communities**: `no-export` (don't advertise beyond current AS), `no-advertise` (don't advertise to any peer), `no-export-subconfed` (confederation-scoped), `internet` (send to all).
- **Extended communities** carry more data (route targets for MPLS L3VPN, site-of-origin) and are the workhorse for MP-BGP applications.
The one-sentence mental model
Communities are metadata glued to prefixes. You don’t have to install a new attribute type or extend BGP — you just tag a prefix with a value that has meaning to a downstream router’s policy. It’s how ISPs let customers signal “prepend AS 3 times” or “don’t advertise to peer X” without needing a per-customer route-map on the ISP side.
The two flavors
Standard community (RFC 1997)
- 32 bits, usually written as
<AS>:<value>(e.g.,65001:100). - Attached to any prefix in a route-map with
set community. - Preserved across AS boundaries unless a filter strips them.
Extended community (RFC 4360)
- 64 bits, more type space, carries structured data.
- Route Target (RT) — used in MPLS L3VPN to identify which VRF a prefix belongs in.
- Site-of-Origin (SoO) — prevents route loops in complex multi-homed VPN sites.
- Also used for encoding OSPF domain-id, link bandwidth, etc.
The four well-known standard communities
| Community | Meaning |
|---|---|
no-export (0xFFFFFF01) | Do NOT advertise this prefix outside the current AS. Common when a customer says “keep this internal”. |
no-advertise (0xFFFFFF02) | Do NOT advertise to ANY neighbor (iBGP or eBGP). Effectively “install locally only”. |
no-export-subconfed (0xFFFFFF03) | In BGP confederations, don’t advertise outside the sub-AS. Rare. |
internet (0x00000000) | Explicit “send everywhere” — the absence of a filter, formalized. |
Setting communities
By default, communities are NOT sent to iBGP peers. You must enable it per neighbor:
router bgp 65001
neighbor 203.0.113.1 send-community
neighbor 10.10.10.2 send-community both ! send std AND extended
Then set a community with a route-map:
ip community-list 10 permit no-export
!
route-map TAG-INTERNAL permit 10
set community 65001:100 no-export
!
router bgp 65001
neighbor 10.10.10.2 route-map TAG-INTERNAL out
Prefixes advertised to 10.10.10.2 will carry community 65001:100 + no-export.
Matching communities
Match communities with an inbound route-map to adjust attributes:
ip community-list 20 permit 65001:100
!
route-map TREAT-INTERNAL permit 10
match community 20
set local-preference 200
!
route-map TREAT-INTERNAL permit 20
! all others — normal treatment
Prefixes tagged with 65001:100 get elevated local-pref to 200.
Real-world ISP community patterns
Big transit providers publish community-based traffic-engineering menus. Typical patterns (each ISP has its own values, published in their community guide):
| Community | Effect |
|---|---|
<ISP-AS>:100 | Don’t advertise to any peer |
<ISP-AS>:200 | Don’t advertise to peer AS 1234 |
<ISP-AS>:301 | Prepend 1x to all peers |
<ISP-AS>:302 | Prepend 2x to all peers |
<ISP-AS>:303 | Prepend 3x to all peers |
<ISP-AS>:400 | Set MED = 10 to peers |
<ISP-AS>:666 | Blackhole (RTBH) — drop this prefix at ISP edge |
The blackhole community is critical for DDoS response. If your /32 is under attack, tag it <ISP>:666 and the ISP null-routes it upstream so the pipe stays clean.
Extended communities — Route Target for L3VPN
In MPLS L3VPN, VRFs on a PE router import and export routes based on Route Targets:
vrf definition CUSTOMER-A
rd 65001:100
address-family ipv4
route-target export 65001:100
route-target import 65001:100
!
Prefixes exported from CUSTOMER-A’s VRF carry RT:65001:100. Any PE that imports 65001:100 installs them into its matching VRF. That’s how one MP-BGP session distributes routes across all customer VRFs while keeping them isolated.
Common exam / real-world mistakes
- Not enabling
send-communityon the neighbor. Default OFF. Set the community all you want — it’s stripped on advertise until this is on. Bit gotcha. - Forgetting
send-community bothwhen the design needs extended communities (e.g., L3VPN). Standard vs extended are enabled independently. - Matching by community with an ACL instead of a community-list. Communities need
ip community-list, not regular ACLs. - Adding communities without
additivekeyword.set community XREPLACES existing communities. Useset community X additiveto append. - Assuming all providers preserve communities. Some strip customer communities at ingress. Test.
Cheat strip
Standard community 32-bit tag "<AS>:<value>"
Extended community 64-bit, includes RT + SoO + more
Well-known:
no-export don't leave current AS
no-advertise don't send to ANY peer
internet explicit "send everywhere"
Enable send:
neighbor X send-community (standard only)
neighbor X send-community both (std + ext)
Set:
set community X:Y [additive] (additive appends, not replaces)
Match:
ip community-list N permit X:Y
route-map MAP → match community N
ISP patterns:
<AS>:100 no-peer | <AS>:301-303 prepend Nx | <AS>:666 blackhole
L3VPN RT export/import in VRF config
Practice — quick check
A scenario each round. Take your time — there's a Next button whether you're right or wrong.
IP Multicast Basics — Groups, IGMP, PIM Sparse Mode, RP
The multicast fundamentals CCNP ENCOR expects — multicast group addresses, IGMP for host-router join, PIM Sparse Mode for router-router distribution, Rendezvous Point (RP) design, and IGMP snooping on switches.
BGP Route Reflectors — Scaling iBGP Beyond Full-Mesh
How Route Reflectors break the iBGP full-mesh requirement, letting one router re-advertise iBGP routes to clients. Cluster-id, hierarchical RRs, redundant RR design, and the loop-prevention attributes ORIGINATOR_ID and CLUSTER_LIST.
Want this drilled into reflex?
1:1 weekly sessions, live feedback on your labs, and US interview prep — built around the CCNP® exam blueprint. Free first session. No card on file until you decide.
Related topics
BGP Basics
Definitive CCNP-level BGP guide — autonomous systems, eBGP vs iBGP, path-vector routing, neighbor states, full best-path selection process, attributes deep dive (AS_PATH, LOCAL_PREF, MED, communities), route reflectors, RPKI, 8 worked scenarios, and the BGP debug workflow.
IP ConnectivityBGP Best-Path Selection — The Full 13-Step Order
The complete BGP path-selection algorithm CCNP ENCOR expects you to recite. Every step in order, with the tie-breaker mnemonic and a worked example for the top three most-common decision points.
IP ConnectivityMPLS Basics
Multi-Protocol Label Switching demystified — labels instead of IP lookups, label distribution (LDP), the P/PE/CE model, MPLS L3VPN, and why MPLS still dominates the WAN backbone.
Get the free CCNA 12-week roadmap
You're already reading up on BGP Communities — Tags for Traffic Engineering + Well-Known Values. The roadmap is the order I recommend studying every CCNA topic in — with what to lab each week and where BGP Communities — Tags for Traffic Engineering + Well-Known Values fits. A written personal reply, not an autoresponder. Expect it within one business day.
Personal reply from a senior network engineer. No third-party tracking. Unsubscribe any time.
