🏷️ BGP Communities Explained

How a simple 32-bit tag attached to a route lets networks encode routing policy, control advertisement scope, and coordinate traffic engineering with their neighbors.

✍️ Author: ToolsNovaHub Editorial Team • ✅ Reviewed by: ToolsNovaHub Security & Network Team • 📅 Updated: 14 July 2026 • ⌛ 24 min read

A BGP community is a small, optional tag — typically a 32-bit value — attached to a route that carries no inherent routing meaning on its own, but that networks use by mutual agreement to signal policy: where a route came from, how far it should propagate, or what special handling it should receive. Communities are one of BGP's most powerful and widely used extensibility mechanisms, forming the backbone of everything from leak-proof export filtering to customer-controlled traffic engineering.

This guide explains the different community formats, how they're actually used in practice, and how to read and apply the community conventions a network publishes for its customers and peers.

⚡ Quick Answer

A BGP community is an optional numeric tag attached to a route that networks use, by mutual agreement, to signal information or trigger specific handling — such as which type of neighbor a route came from, how widely it should be propagated, or requests like "don't announce this to a specific peer." Communities don't affect BGP's core route selection directly; their meaning is entirely defined by policy configured on the receiving network's routers.

⭐ ToolsNovaHub Pro Tip

Before configuring communities on a session with a transit provider or IXP route server, always check their published community documentation (usually on their website or in their PeeringDB entry's notes) rather than guessing values from a generic reference — community numbering conventions vary significantly between networks and using the wrong value can silently produce unintended routing behavior.

⚠️ Common Beginner Mistake

Assuming a specific community value has universal meaning across all networks. Aside from a handful of well-known, standardized communities (like NO-EXPORT and NO-ADVERTISE), the vast majority of community values are defined locally by each network — the same numeric value can mean completely different things on two different providers' networks.

🎯 Key Takeaways

Communities are optional route tags whose meaning is defined by local or mutually agreed-upon policy, not the BGP protocol itself.
Standard communities are 32 bits; extended and large communities extend the format for more structured, larger-scale use cases.
A small set of well-known communities (NO-EXPORT, NO-ADVERTISE, NO-PEER) have standardized, universal meaning.
Most communities are used for one of three purposes: informational tagging, filtering/scoping, or traffic engineering.
Transit providers commonly publish customer-usable communities that let customers influence their own route's local preference or propagation scope.
Community-based export policy is the standard mechanism for preventing route leaks at scale.

🔍 What Are BGP Communities?

A BGP community is an optional transitive attribute that can be attached to a route, consisting of a numeric value that carries whatever meaning the networks using it choose to assign. Unlike core BGP attributes like AS-PATH or NEXT-HOP, which have fixed, protocol-defined behavior, a community's effect entirely depends on policy explicitly configured on a receiving router — the community itself is inert until something is configured to act on it.

The original (and still widely used) community format, defined in RFC 1997, is a 32-bit value conventionally written as two 16-bit numbers separated by a colon, such as 65000:100, where the first number is typically the AS number of the network defining the community's meaning, and the second number is a locally-assigned code for a specific policy action within that network's scheme.

This "AS:value" convention is a widely followed best practice, not a protocol requirement, but it serves an important practical purpose: it immediately tells anyone looking at a route's communities which network's documentation to consult to understand what that specific value means, since community meanings are defined per-network rather than globally (aside from the small set of standardized well-known communities).

Two extended formats address limitations of the original 32-bit community. Extended communities (RFC 4360) use a 64-bit value with a structured type field, commonly used for more complex applications like VPN route targets in MPLS networks. Large communities (RFC 8092) use three 32-bit fields instead of two 16-bit ones, specifically introduced to accommodate 4-byte ASNs (which became common as the original 2-byte ASN space filled up) that don't fit cleanly into the original 16-bit community format.

🎯 Why Communities Matter

Communities are the primary mechanism that makes sophisticated, maintainable BGP policy possible at scale. Without them, implementing something like "only advertise customer routes to Provider A, but advertise customer and peer routes to Provider B" would require manually maintaining and updating explicit prefix lists for every export policy — a brittle, error-prone approach that scales poorly as a network's customer base changes constantly.

With communities, a network instead tags every route once, at the point it's learned (customer route gets a "customer" community, peer route gets a "peer" community, and so on), and then writes export policy declaratively based on those tags: "advertise routes tagged customer or peer to Provider B, but only customer-tagged routes to Provider A." This policy remains correct automatically as the underlying customer base changes, since new customer routes get tagged consistently without any manual list maintenance — a foundational technique for preventing the kind of route leaks covered in ToolsNovaHub's Route Leaks guide.

Communities also enable a powerful form of indirect control: many transit providers and large networks publish specific "customer-settable" communities that let customers influence how their own routes are treated or propagated — requesting a lower local preference on a specific link, asking that a route not be advertised to a specific peer, or requesting regional-only propagation — all without needing direct configuration access to the provider's own routers. This effectively turns communities into a limited, safe remote-control interface for traffic engineering across an organizational boundary.

Beyond policy and traffic engineering, communities serve an important informational role: they let operators (and increasingly, automated tooling) understand at a glance where a given route came from and how it's being treated, which is invaluable both for day-to-day troubleshooting and for auditing routing policy correctness after the fact.

Communities also underpin much of the automation and tooling that has grown up around modern network operations. Configuration generation systems, route analysis tools, and monitoring dashboards increasingly rely on consistent community tagging to programmatically understand and visualize a network's routing policy, rather than requiring engineers to manually trace through raw prefix lists. This makes a well-designed community scheme not just a policy convenience but a genuine enabler of broader network automation maturity.

⚙️ How Communities Are Actually Used

Tagging on route receipt

As routes are learned from customers, peers, or transit providers, a network's import policy attaches a community reflecting that route's origin type.

Policy decisions based on tags

Export filters, local preference assignment, and other routing decisions are then written to key off these community tags rather than manually maintained prefix lists.

Customer-triggered actions via well-known values

Customers wanting specific handling for their own routes (like reduced propagation) attach a documented, provider-specific community before advertising the route to that provider.

Well-known communities applied for universal behavior

Standardized communities like NO-EXPORT are used when a route should never leave a specific administrative boundary, regardless of which network is handling it.

Communities stripped or preserved at network boundaries

Networks typically strip communities intended only for their own internal use before advertising routes onward, while preserving communities meant for downstream consumption.

🏗️ Architecture & Community Types

Standard (32-bit) communities remain the most widely used format for general-purpose policy tagging and are supported by essentially every BGP implementation in existence, making them the safe default choice for most use cases. Their limitation is capacity: with only two 16-bit fields, encoding rich, multi-dimensional policy information (like a specific action plus a specific geographic region plus a specific AS) can require multiple separate community values rather than one compact encoding.

Extended communities address this by using a 64-bit value with an explicit type field that structures the remaining bits differently depending on the use case — most commonly seen in MPLS VPN route target and route origin applications, where the extra structure and capacity are genuinely needed, though they see comparatively limited use in general internet routing policy outside that context.

Large communities, the newest format, were introduced specifically to solve a real, growing problem: since the original 16-bit ASN space became exhausted and 4-byte ASNs became common, many networks with 4-byte ASNs couldn't cleanly represent "my ASN:my value" in the original 16-bit-field format. Large communities use three full 32-bit fields, comfortably accommodating a full 4-byte ASN in the first field alongside two additional 32-bit fields for function and parameter values, and have seen rapid adoption specifically among networks with 4-byte ASNs needing customer-facing traffic engineering communities.

A handful of well-known communities have standardized, universal meaning recognized by virtually every BGP implementation regardless of network: NO-EXPORT (65535:65281) prevents a route from being advertised outside the local confederation or AS boundary; NO-ADVERTISE (65535:65282) prevents the route from being advertised to any BGP neighbor at all; and NO-EXPORT-SUBCONFED restricts propagation within a confederation specifically. These require no bilateral agreement to use correctly since their behavior is standardized.

🔧 Step-by-Step: Designing a Community Scheme

Define your tagging categories

Decide what distinctions matter for your policy — typically at minimum customer/peer/transit origin, and possibly geographic region or service tier.

Choose a community format

Select standard communities for simplicity, or large communities if your ASN is a 4-byte number or you need richer structured encoding.

Reserve a documented value range

Assign specific numeric ranges to specific meanings (e.g., 100–199 for origin type, 200–299 for customer-requested actions) and document this scheme.

Implement tagging on ingress

Configure import policy on every session to apply the appropriate community as routes are received.

Build export policy from tags

Write export filters that key off community values rather than manually maintained prefix lists.

Publish customer-facing communities

If offering customer-controlled traffic engineering, clearly document which communities customers can set and exactly what effect each one has.

Strip internal-only communities at the border

Ensure communities meant only for internal policy don't leak out to external neighbors where they carry no meaning (or worse, an unintended one).

🔄 Flow: A Route's Community Journey

Route received from customer → Tagged with "customer-origin" community → Export policy checks tag → Advertised to all peers and transit providers (per policy) → Downstream network sees the community → Downstream network may apply its own policy based on that tag, or strip it before further propagation

💡 Practical Examples

A transit provider tags every customer route with community 65000:100 (customer-origin) on ingress. Its export policy then simply says "advertise anything tagged customer-origin, peer-origin, or transit-origin to other customers; advertise only customer-origin and peer-origin to peers; advertise only customer-origin to other transit providers" — a compact, maintainable three-line policy that correctly scopes propagation regardless of how many thousands of individual customer prefixes exist underneath it.

A large ISP publishes a documented set of customer-usable communities, including 65000:1000 ("don't advertise this route to peers, transit-only") and 65000:2000 through 65000:2099 ("set local preference to 50 through 149 respectively"), letting business customers with specific traffic engineering needs influence how their own advertised routes are treated without needing any direct configuration access to the ISP's own routers.

A network operating a 4-byte ASN adopts large communities specifically to implement a customer-facing "reduce local preference by region" scheme, since the original standard community format couldn't cleanly encode their full ASN value alongside the additional parameters needed for the region-specific behavior.

🎯 Scenario Walkthrough: Communities in Action

Scenario 1 — A transit provider's internal scheme. A mid-sized transit provider tags every route on ingress with an origin community, then writes export policy entirely in terms of those tags. When it onboards a new customer, no export filter changes are needed anywhere in the network — the new customer's routes are automatically tagged and correctly scoped the moment they're received.

Scenario 2 — A customer requesting traffic engineering. A business customer of that same transit provider notices asymmetric routing causing higher latency on inbound traffic via one of the provider's upstream links. Rather than filing a support ticket and waiting for manual configuration changes, the customer consults the provider's published community documentation and attaches a specific community to its own route announcement, requesting reduced local preference on that link — the change takes effect automatically on the provider's side.

Scenario 3 — Migrating to large communities. A network operating a 4-byte ASN that had been using a workaround encoding in standard communities migrates its entire scheme to large communities, cleanly representing its full ASN alongside richer parameter encoding, and updates its public documentation so customers and peers can transition to the new values.

These scenarios illustrate the three main ways communities create value: internal policy simplification, external customer self-service, and clean technical encoding as network requirements evolve.

🎯 Real-World Use Cases

Route leak prevention — origin tagging that enables declarative, maintainable export policy.
Customer traffic engineering — provider-published communities letting customers influence local preference or propagation scope.
Regional/geographic scoping — large networks controlling which routes propagate to which geographic regions of their infrastructure.
Blackholing (DDoS mitigation) — a widely used community convention that triggers automatic null-routing of a specific prefix across a provider's network.
Route server policy at IXPs — communities controlling which participants receive a given route through the shared route server.

✅ Advantages

Enables declarative, maintainable routing policy that scales without manual prefix list upkeep.
Lets customers influence provider-side routing behavior without direct router access.
Provides a standardized, widely-supported extensibility mechanism recognized across virtually all BGP implementations.
Large communities cleanly solve the 4-byte ASN encoding limitation of the original format.
Well-known communities offer universal, no-negotiation-needed behavior for common scoping needs.

⚠️ Disadvantages & Limitations

Meaning is entirely network-specific outside the small set of well-known communities, requiring documentation lookup for each network.
Misapplied or misunderstood community values can produce unintended, sometimes hard-to-diagnose routing behavior.
Not all BGP implementations support extended and large communities equally well, occasionally complicating multi-vendor environments.
Poorly documented internal community schemes become difficult to maintain as an organization's network team changes over time.

🏆 Best Practices

Follow the "AS:value" convention for any community you define, so its origin is immediately clear to anyone inspecting a route.
Document your full community scheme internally and, for any customer-facing communities, publish clear external documentation.
Strip internally-scoped communities at your network's external border to avoid unintended leakage of internal policy signals.
Use large communities if your ASN is a 4-byte number, to avoid encoding ambiguity in the original 16-bit format.
Regularly audit that export policy correctly reflects your documented community scheme, especially after configuration changes.

🔒 Security Considerations

Community-based export policy is a core defense against route leaks — ensure it's actually enforced, not just documented.
Validate that customer-settable communities can't be abused to trigger unintended behavior, such as an inappropriate blackholing request affecting unrelated traffic.
Be cautious about honoring communities from untrusted or unauthenticated sources, since a malicious neighbor could attempt to manipulate your routing behavior via crafted community values if your policy isn't sufficiently scoped.
Strip sensitive internal communities before routes leave your network, since they may reveal internal topology or policy details.

⚡ Performance Considerations

Community processing adds negligible per-route overhead on modern router hardware.
Well-designed, tag-based policy is typically more efficient to evaluate and maintain than large, manually-managed prefix lists.
Excessive community proliferation (dozens of overlapping, poorly documented values) can slow down troubleshooting even if it doesn't measurably affect router performance.

❌ Common Problems

Problem	Typical Cause
Customer-requested traffic engineering not taking effect	Incorrect community value used, or provider not honoring that specific community on the session in question
Internal community values leaking to external neighbors	Missing strip policy at the network's external border
Export policy not scoping correctly	Routes not being tagged consistently on ingress across all sessions
Confusion interpreting a received route's communities	Assuming universal meaning for a value that's actually specific to the originating network

🔧 Troubleshooting

A requested community-based action isn't working: Double-check the exact community value against the provider's published documentation, and confirm the route is actually being advertised with that community attached (visible via a route inspection command on your own router).

Unexpected communities appearing on routes you receive: Consult the originating network's or an intermediate network's published community documentation to understand the intended meaning, since the same numeric value can mean different things on different networks.

Export policy not scoping propagation as expected: Verify that routes are being tagged consistently at ingress on every relevant session, since a gap in tagging on even one session can cause inconsistent downstream behavior.

✅ Implementation Checklist

Use this checklist when designing or auditing a BGP community scheme for your network.

Tagging categories defined — at minimum customer/peer/transit origin, expanded as needed for your policy.
Community format chosen deliberately — standard for simplicity, large communities if you hold a 4-byte ASN.
Numeric value ranges documented — reserved and recorded so the scheme stays legible as it grows.
Ingress tagging implemented consistently — applied on every relevant session, with no gaps.
Export policy built from tags — not manually maintained, hard-to-audit prefix lists.
Well-known communities used where appropriate — NO-EXPORT and NO-ADVERTISE for universal, no-negotiation-needed scoping.
Customer-facing communities documented publicly — if offering customer-controlled traffic engineering.
Internal-only communities stripped at the border — verified not to leak to external neighbors.
Scheme documented internally — so the design remains maintainable as network team membership changes.
Policy audited periodically — confirming export/import behavior still matches the documented scheme after configuration changes.

💡 Expert Tips

When researching a transit provider or peer, check their website for a dedicated "communities" or "BGP community values" documentation page before assuming any specific value's behavior.
Adopt large communities early if you're a 4-byte ASN network building any kind of customer-facing traffic engineering scheme, to avoid a painful migration later.
Use consistent, well-documented value ranges (e.g., reserving specific blocks for origin tags vs action tags) to keep your scheme legible as it grows.

❌ Beginner Mistakes

Assuming a community value seen on one network's routes means the same thing on a different network.
Forgetting to strip internal-only communities before routes are advertised externally.
Using standard (32-bit) communities with a 4-byte ASN in a way that causes ambiguous or truncated encoding.
Not documenting an internal community scheme, making it difficult for anyone besides the original author to maintain or extend.

📊 Comparison Tables

Community Format Comparison

Format	Size	Typical Use Case
Standard Community	32-bit (two 16-bit fields)	General-purpose policy tagging, widest support
Extended Community	64-bit (typed)	MPLS VPN route targets/origins, structured use cases
Large Community	96-bit (three 32-bit fields)	4-byte ASN networks, rich customer-facing schemes

Well-Known Communities

Community	Value	Effect
NO-EXPORT	65535:65281	Not advertised outside the local AS or confederation
NO-ADVERTISE	65535:65282	Not advertised to any BGP neighbor at all
NO-EXPORT-SUBCONFED	65535:65283	Restricted within a confederation sub-AS boundary

📋 Feature Table

Feature	BGP Communities
Defining RFCs	RFC 1997 (standard), RFC 4360 (extended), RFC 8092 (large)
Effect on route selection	None directly — meaning defined entirely by configured policy
Common naming convention	AS:value
Primary use cases	Filtering, traffic engineering, informational tagging

📚 Key Terms Glossary

Standard community: The original 32-bit BGP community format defined in RFC 1997, conventionally written as two 16-bit numbers separated by a colon, such as 65000:100.
Extended community: A 64-bit, typed community format defined in RFC 4360, most commonly used for structured applications like MPLS VPN route targets and route origins.
Large community: A community format using three 32-bit fields, defined in RFC 8092 specifically to accommodate 4-byte ASNs that don't fit cleanly into the original 16-bit field format.
Well-known community: A small set of standardized community values, like NO-EXPORT and NO-ADVERTISE, with universal meaning recognized across virtually all BGP implementations without needing bilateral agreement.
4-byte ASN: An Autonomous System Number from the expanded 32-bit numbering space, introduced once the original 16-bit ASN space became exhausted, requiring large communities for clean encoding.
Blackholing: A traffic engineering technique, commonly triggered via a specific community, that causes a provider to automatically null-route a specified prefix across its network, often used for DDoS mitigation.
Origin tagging: The practice of attaching a community to a route as it's learned, reflecting whether it came from a customer, peer, or transit provider, forming the basis of declarative export policy.
Transitive attribute: A BGP attribute, including most commonly used communities, that a router propagates onward to its neighbors by default, as opposed to non-transitive attributes that are dropped.

❓ FAQs

What is a BGP community? +

A BGP community is an optional numeric tag attached to a route that networks use, by mutual agreement, to signal information or trigger specific policy handling — its meaning is defined by configured policy, not the BGP protocol itself.

What format do standard BGP communities use? +

Standard communities are 32-bit values conventionally written as two 16-bit numbers separated by a colon, such as 65000:100, typically with the first number being the defining network's ASN.

What are large BGP communities? +

Large communities (RFC 8092) use three 32-bit fields instead of the original format's two 16-bit fields, specifically introduced to cleanly accommodate 4-byte ASNs and richer parameter encoding.

What is the NO-EXPORT community? +

NO-EXPORT (65535:65281) is a well-known, standardized community that prevents a route from being advertised outside the local AS or confederation boundary, recognized universally across BGP implementations.

Do all networks assign the same meaning to a given community value? +

No — outside a small set of well-known communities, meaning is defined locally by each network, so the same numeric value can mean completely different things on different networks.

What are extended communities used for? +

Extended communities use a 64-bit typed format most commonly associated with MPLS VPN applications like route targets and route origins, seeing more limited use in general internet routing policy.

How do communities help prevent route leaks? +

Tagging routes by origin (customer/peer/transit) lets networks build declarative export policy based on those tags, correctly scoping propagation without needing to manually maintain prefix lists — see ToolsNovaHub's Route Leaks guide.

Can customers influence their own route's treatment using communities? +

Yes — many transit providers publish specific customer-settable communities that let customers request things like reduced propagation scope or adjusted local preference without needing direct router access.

What is community-based blackholing? +

Blackholing is a widely used community convention where attaching a specific community to a route triggers automatic null-routing of that prefix across a provider's network, commonly used as a DDoS mitigation technique.

Do communities affect BGP's best path selection directly? +

Not inherently — communities only affect route selection or propagation if a network has explicitly configured policy that reads and acts on specific community values.

Why would I choose large communities over standard communities? +

Large communities are preferred if your network has a 4-byte ASN that can't be cleanly represented in the original 16-bit community field format, or if you need more structured, multi-parameter encoding.

What does the 'AS:value' naming convention mean? +

It's a widely followed best practice (not a protocol requirement) where the first number in a community is the defining network's ASN, making it immediately clear which network's documentation to consult for that value's meaning.

Should communities be stripped at network boundaries? +

Internally-scoped communities meant only for a network's own internal policy should generally be stripped before routes are advertised externally, to avoid unintended leakage of internal signaling.

How can I find a provider's published community list? +

Most major transit providers and large networks publish their community documentation on their corporate or network operations website, often linked from their PeeringDB entry as well.

What happens if I use an undocumented or incorrect community value? +

Typically nothing happens if no policy is configured to act on that value — the community is simply carried along inertly, though using an incorrect value when you intended a specific action means that action won't take effect.

Are BGP communities transitive? +

Standard, extended, and large communities as originally defined can be either transitive (propagated onward by default) or non-transitive depending on type and configuration; most commonly used community applications are transitive.

What is a route server community at an IXP? +

Many Internet Exchange Point route servers define specific communities that let members control which other exchange participants receive a given route, offering fine-grained control despite using shared route server infrastructure.

Can communities be used for geographic traffic engineering? +

Yes — many large, geographically distributed networks define communities that control whether a route propagates to specific regions of their internal or external network.

How many communities can a single route carry? +

There's no strict protocol-defined limit, though in practice routers and network designs typically keep the number of communities on any single route reasonably small for clarity and manageability.

Is there a standard registry of BGP community values? +

No global registry exists for locally-defined communities (aside from the small set of IANA-registered well-known communities), which is why consulting each specific network's own published documentation is necessary.

Do all router vendors support large communities? +

Support has become widespread across major router platforms since RFC 8092 was published, though it's still worth confirming support on any older or less common equipment before designing a scheme around them.

Can communities be combined with AS-PATH filtering? +

Yes — many networks use communities and AS-PATH-based filtering together, with communities handling origin-based scoping and AS-PATH filters catching anomalies like unexpectedly long or suspicious paths.

What happens to communities when a route is aggregated? +

Behavior depends on router configuration; by default some communities may be lost during aggregation unless explicitly configured to be preserved, which is an important detail to verify in networks that aggregate routes.

How do I test that my community-based policy works as intended? +

Use a lab or staging environment to inject test routes with specific communities and verify the resulting export/import behavior matches your documented policy before deploying changes to production.

Can communities be used to signal geographic origin? +

Yes — many large, geographically distributed networks define communities specifically to tag routes by their region of origin, enabling region-aware export and traffic engineering policy.

What's the risk of an overly complex community scheme? +

An excessively complex, poorly documented scheme becomes difficult to audit and maintain over time, increasing the chance of policy drift or mistakes as the team responsible for it changes.

Do communities interact with BGP confederations? +

Yes — the well-known NO-EXPORT-SUBCONFED community specifically restricts propagation within a confederation sub-AS boundary, a scenario unique to networks using BGP confederations for internal structuring.

📋 Conclusion

BGP communities turn what would otherwise be rigid, hard-to-maintain routing policy into a flexible, tag-based system that scales cleanly as a network's customer base and relationships grow. From preventing route leaks to letting customers remotely influence their own traffic engineering, communities are one of the most practically important extensibility mechanisms in the entire BGP protocol.

For related context, see ToolsNovaHub's guides on Route Leaks (where community tagging is the primary defense), BGP Peering, and Internet Exchange Points (where route server communities control propagation scope), and use the ASN Lookup tool to research any network's registered footprint.

If you're implementing communities for the first time, start simple: tag routes by origin type (customer/peer/transit), build export policy from those tags, and only move on to more advanced customer-facing traffic engineering communities once that foundational scheme is solid and well documented.

🔗 Continue exploring: ASN Peering · Transit vs Peering · Internet Exchanges · Route Leaks · ASN Lookup Guide · ASN Lookup Tool

Explore All ToolsNovaHub Tools

🏠 Go to Homepage