If you've worked with BGP at all, you've heard the word community. It sounds vague — and the BGP community attribute itself doesn't do anything. Communities only matter because providers and operators agree on conventions for what tags mean. Once you understand them, communities become one of the most powerful traffic engineering tools you have.
This guide explains BGP communities from first principles: what they are, the formats you'll see, the most useful "well-known" communities, and concrete examples of how operators use them in production.
What Is a BGP Community?
A BGP community is a 32-bit (or, in extended/large form, longer) tag attached to a route announcement. It's purely informational — it doesn't change routing on its own. But networks that see a community can be configured to take action: prefer the route, depref it, drop it, prepend it, leak it, blackhole it.
You'll see three formats:
- Standard community (32-bit) — written as
ASN:VALUE, e.g.,65000:100. - Extended community — used mostly in MPLS VPNs.
- Large community (12 bytes) — modern format, written as
ASN:FUNCTION:PARAMETER. Critical for 32-bit ASNs.
Well-Known Communities
A small set of communities are reserved by the IETF and behave consistently across all BGP implementations:
NO_EXPORT(65535:65281) — don't export this route to eBGP peers.NO_ADVERTISE(65535:65282) — don't advertise this route to any peer.NO_PEER(65535:65284) — don't advertise to bilateral peers (advertise only to customers/upstreams).BLACKHOLE(65535:666) — drop all traffic to this prefix (RFC 7999).
65535:666 is the most commonly used: standard remotely triggered blackhole.
Provider-Specific Communities
Most useful communities aren't well-known — they're conventions defined by individual transit providers. Each provider publishes a "community list" describing what they accept and what each community does.
Common categories:
Influence Where Routes Are Announced
ASN:0:peer-asn— don't announce to a specific peer.ASN:1:peer-asn— announce to a specific peer.ASN:no-export-region— don't export to a specific geographic region.
AS-Path Prepending Control
ASN:101:peer-asn— prepend once when announcing to that peer.ASN:102:peer-asn— prepend twice.ASN:103:peer-asn— prepend three times.
Local Preference Control
ASN:1xx— set local-pref to a specific value within the provider's network.
Blackholing
ASN:666or65535:666— drop traffic to this /32 (or /128) at the upstream's edge.
DDoS / FlowSpec
- Provider-defined communities to trigger scrubbing diversion or rate limits.
Real-World Examples
Example 1: Selective Outbound Announcement
You're multi-homed to Provider A and Provider B. You want users from Asia to reach you through Provider A and users from Europe through Provider B.
Solution: announce your prefix to both. To Provider A, attach A:no-export-EU. To Provider B, attach B:no-export-AS. Each provider stops propagating your route in the unwanted region, leaving the other path as the only option.
Example 2: AS-Path Prepending Without Touching Your Own AS-path
Instead of prepending your own ASN multiple times (which can affect all peers), you tag your announcement with upstream:103:peer-X. The upstream then prepends your route 3 times when announcing to peer X — but normal everywhere else.
Example 3: Emergency Blackhole
You're under DDoS targeting 198.51.100.42. You announce 198.51.100.42/32 to your upstream with community 65535:666. The upstream installs a discard route, dropping all traffic to that /32. The attack stops; your other IPs keep working.
Example 4: Customer Hairpinning Prevention
You're a small network with two upstreams. To prevent becoming a transit network, you tag all routes you receive with NO_EXPORT. They go into your routing table but never get announced to your other upstreams.
Large Communities and 32-bit ASNs
Standard 32-bit communities have a 16-bit ASN field, which doesn't fit modern 32-bit ASNs (numbers above 65535). Large communities (RFC 8092) solve this with a 12-byte format: ASN:FUNCTION:PARAMETER, where each field is 32 bits.
Example: 65000:101:64500 means "AS65000 wants its peer (AS64500) to prepend once."
If you operate a network with a 32-bit ASN or peer with one, large community support is required. All modern routers support it.
Best Practices for Community Use
- Read your provider's community guide. Each one is different. Bookmark them.
- Document your own communities. If you accept communities from customers, publish what you accept and what each one does.
- Filter inbound communities you don't trust. Don't let customers set your own internal communities or well-known ones like NO_EXPORT.
- Monitor community usage. Surprises in your routing table are usually a community misconfig.
- Use communities instead of more-specific announcements when possible. Communities don't pollute the global routing table.
- Sign your prefixes with RPKI. Communities don't help if your route is RPKI-invalid.
Common Mistakes
- Using a community the upstream doesn't recognize. Nothing happens — your route ships unmodified. Always verify with the provider.
- Stripping communities by accident. Routers default to stripping non-transitive attributes; ensure your config preserves them where needed.
- Letting communities propagate too far. Some communities are meant for one hop only. Filter at appropriate boundaries.
- Forgetting large communities. If you only configure standard, you may break with peers using 32-bit ASNs.
How to Find a Provider's Communities
- Search the provider's site for "BGP community guide" or "community reference."
- Check Hurricane Electric's BGP toolkit (
bgp.he.net) — many providers list theirs. - Ask your account manager.
- For looking-glass providers, communities are often documented alongside session info.
BGP Communities at Noded
Noded publishes a complete community reference for our customers, supporting selective announcements per region, prepending control, blackholing, and DDoS scrubbing diversion. Combined with our IP transit and BYO-IP support, our community framework gives you fine-grained traffic engineering without requiring you to terminate your own BGP sessions everywhere.
Want a copy of our community guide? Talk to our network team — we'll walk you through your traffic engineering options.
Frequently Asked Questions
Are BGP communities standardized?
Only the well-known ones (NO_EXPORT, BLACKHOLE, etc.). Most communities are provider-specific conventions. Always check the provider's community guide.
What's the difference between standard and large communities?
Standard communities have a 16-bit ASN field. Large communities have three 32-bit fields, supporting modern 32-bit ASNs and richer semantics.
Can communities cause routing loops?
Communities themselves don't cause loops, but misconfigured policies driven by communities can. Test changes carefully.
Do communities work with private peering?
Yes — communities are a BGP attribute, so they apply equally to public IXP peering, private peering, and transit.
Are communities visible to everyone on the internet?
Communities propagate by default unless filtered. Many operators strip communities at AS boundaries to avoid leaking internal info.