Shikanoko Networks (SKNK)
Back to blog

SKNK Technical Guide

What Are BGP Communities? How Networks Control Route Policy

A BGP Community is a policy signal attached to a route, not a command. How standard, large, extended, and provider-defined communities differ, what NO_EXPORT, NO_ADVERTISE, and BLACKHOLE actually do, and how to verify a community before your traffic depends on it.

Say you run your own AS with two upstreams. Both BGP sessions are Established, your prefix is announced on both, and traffic arrives through each in whatever proportion the rest of the Internet finds convenient. You want one upstream to carry most of your inbound traffic. Or you want a specific prefix visible only in one region. Or you want one path made less attractive without touching your own configuration twice.

Your router cannot do this alone. Once a route leaves your network, every other network decides for itself how to reach you. The standard mechanism for expressing a preference is to attach a BGP Community to the announcement — and the first thing to understand about it is what it is not:

  • It does not create a route.
  • It does not replace your ASN, a ROA, or an IRR route object.
  • It does not guarantee any particular propagation.
  • It produces an effect only when the receiving network has a policy configured to look for that label.

RFC 1997 defines the community attribute as a way to group destinations that share a property, carried as an optional transitive path attribute on BGP announcements. (RFC 1997)

Definition Box: A BGP Community is an optional route attribute that carries policy information with a BGP announcement. Its meaning depends on the receiving network's documented routing policy.

White-Face Xiaolu attaches a small tag to a route card and holds it out toward an upstream gatekeeper, who has not yet decided whether to act on it.

What leaves your network is a labeled request. The gatekeeper decides what to do with it.

A Signal, Not a Command

Four facts frame everything else in this guide:

  1. It is a tag attached to a route. The announcement itself — prefix, origin ASN, AS_PATH — travels exactly as before. The community rides along as an attribute.
  2. The tag can express origin, purpose, or a requested action. "This route came in at Frankfurt." "Prefer this path." "Only show this to peers."
  3. An upstream can react to the tag. Common reactions: adjust local preference, restrict where the route is re-advertised, prepend AS_PATH before passing it on.
  4. The receiver always has the last word. A network can keep the attribute, rewrite it, strip it, or ignore it entirely.

To place the attribute among the building blocks you already know:

Concept The question it answers
IP prefix Which address range is being announced
ASN Which network originates it
BGP How networks exchange routes
Community How the sender would like the route to be handled
ROA Which ASN the address holder authorized to originate the prefix
IRR route object Which ASN records the intent to announce the prefix

The same layering runs through BGP Basics: the prefix and origin identify the route, while the community talks to the policy engine on the receiving side. What you send is a policy request. It is not a write access into someone else's router.

Why Prefixes and AS_PATH Alone Don't Get You There

You could object: my upstream already filters my prefixes and reads my AS_PATH. Why add another attribute?

Because neither of those can carry intent. A prefix list says whether a route is allowed in. AS_PATH records which networks the announcement traversed. Neither can say "don't show this one to your transit peers" or "treat this customer as backup, not primary." Without an attribute for that, every per-center, per-peer, per-region exception has to be hand-configured on the provider side — prefix by prefix, neighbor by neighbor.

Communities let the sender classify a route once, and let the operator apply policy to everything carrying that label:

Customer route
   ↓
Community attached
   ↓
Upstream recognizes the label
   ↓
Upstream's local policy
   ↓
Propagation, preference, or AS_PATH decision

The chain breaks at any arrow. If the label is stripped before the policy ever sees it, or the policy was never configured, nothing happens — silently.

The Community Formats You Will Encounter

Category Basic form What matters
Standard Community 32-bit value, usually written ASN:value The classic attribute from RFC 1997. Both halves are 16-bit, so a 4-byte ASN does not fit cleanly
Large Community ASN:value1:value2, three 32-bit fields Built for 4-byte ASNs; the modern preference (RFC 8092)
Extended Community 8 octets A separate attribute used for route targets and VPN scenarios — related name, different mechanism (RFC 4360)
Provider-defined policy semantics Usually carried in a Standard or Large Community; exact value is provider-specific The ones that matter operationally — this is where real traffic engineering happens

This table puts three attribute formats beside one operational category because that is how upstream documentation is usually written. Provider-defined is a policy layer, not a fourth wire format.

Two distinctions do most of the work here.

Standard vs Large. A standard community is two 16-bit numbers. Your ASN, if it is 4-byte, simply does not fit in the first half. Large communities carry three 32-bit values — global administrator, then two fields the operator defines — precisely so a 32-bit ASN can appear intact. Large communities are not a new version of the old attribute that you must migrate to; both are in production, and which one to use is decided by what your upstream documents.

Communities vs Extended Communities. Extended communities are a different path attribute with their own format and purpose — route targets in VPNs being the familiar case. Sharing a word in the name does not make them interchangeable, and a tool or policy that handles one does not automatically handle the other.

The rule that follows from the table: identical format does not mean identical meaning. 64500:70 means nothing by itself — it means whatever the network that documented it says it means, and only on the sessions where that network applies it. (AS numbers in the 64496–64511 range are reserved for documentation; nothing above should be read as a real provider value.)

Four Well-Known Communities to Know

This article focuses on four commonly encountered standardized communities. Their base semantics are defined in RFCs; other well-known communities exist for other purposes and are outside this article's scope:

Community Meaning
NO_EXPORT Do not advertise outside a BGP confederation — in a non-confederation AS, normally not beyond the next external eBGP boundary
NO_ADVERTISE Do not advertise to any BGP peer, internal or external
NO_EXPORT_SUBCONFED Do not advertise to external peers, including other members of a confederation
BLACKHOLE Request that the receiver discard traffic destined to this prefix

The first three trace back to RFC 1997 (RFC 1997); the BLACKHOLE community is specified in RFC 7999 (RFC 7999).

Two caveats keep these out of wishful-thinking territory.

Well-known does not mean universally honored as you imagine it. RFC 8642 exists precisely because implementations and operator policies differ in how they treat these attributes — whether they act on them, whether they pass them on, whether they strip them (RFC 8642). Before relying on a well-known value against a specific neighbor, confirm that neighbor's behavior.

BLACKHOLE is not automatic DDoS protection. It is a request to drop traffic toward a prefix — usually a more-specific of a prefix you are already authorized to announce. Whether the request is honored at all depends on the receiving network: many accept it only for authorized prefixes, only up to a maximum prefix length, and only after the service has been enabled on your session. And when it works, the traffic is discarded, not cleaned. The prefix is unreachable for the duration; that is the point, and also the cost.

Provider-Defined Communities: The Part That Actually Matters

Well-known values cover edge cases. The day-to-day work — steering inbound traffic, scoping propagation, backing off a path — is done with communities each provider defines and documents itself:

Business goal Capability an upstream may offer What actually changes
Make one upstream prefer your route Upstream raises its local preference for the route How that upstream's network sends traffic toward you
Limit where a prefix is seen Regional propagation control Propagation across parts of the provider's footprint
Keep a prefix away from certain neighbors Peer / transit export control What the upstream re-advertises, and to whom
Make a path less preferred Upstream prepends AS_PATH for you How distant networks compare your announced paths
Shed attack traffic BLACKHOLE / remotely triggered black hole Traffic to the prefix is discarded inside the receiver

Three layers need to be kept apart, because marketing copy routinely merges them:

  • Local preference is decided inside the receiving AS. When your upstream raises it for your route, their network prefers your direct link when sending traffic toward you — your inbound traffic through them grows. It changes nothing for networks beyond that upstream.
  • AS_PATH prepending changes how third parties compare paths toward you, since shorter paths win. You can prepend on your own transmissions, or have an upstream do it on re-advertisement via a community — same idea, different point of application.
  • The community itself does neither. It is the trigger; the upstream's configuration is the mechanism.

So the honest version of the sales pitch reads: if the upstream supports this community, it may apply the documented policy; every other network on the Internet still routes according to its own policy. Any phrasing stronger than that is promising something BGP cannot deliver.

Communities in Practice: One Network, Two Upstreams

                ┌── Upstream A
Your network ───┤
                └── Upstream B

Four scenarios cover most real deployments. Assume both sessions announce the same prefix unless stated otherwise — the mechanics of the sessions themselves are covered in Transit vs Peering.

Scenario 1: A should be primary. Attach the upstream's "raise local preference" community on session A. Their network now prefers your link when reaching you. Optionally, also make your own announcement toward B less attractive — by prepending on the B session yourself, or by using B's documented prepend community.

Scenario 2: B should only serve one region. Use B's regional scope community so they re-advertise your prefix only within, say, their European footprint. Outside that footprint, your route simply does not exist as far as B's customers are concerned.

Scenario 3: a prefix only for peers. Attach the provider's peer-only export community — the route reaches their peering partners but not their transit providers. Note that plain NO_EXPORT is usually too blunt here: it stops at the first eBGP boundary, which may be exactly one hop short of what you wanted.

Scenario 4: an attack targets one prefix. Announce a more-specific of the attacked prefix carrying the BLACKHOLE community to a participating upstream. Traffic headed for that specific prefix is dropped at their edge; the covering prefix stays reachable. This is the What Is Multihoming? architecture earning its keep — the second upstream keeps you online while the burning prefix is sacrificed.

White-Face Xiaolu stands at a junction of two conveyor paths, raising a signal flag on the preferred track while a gate slows the other.

Preference, regional scope, peer-only export, blackhole: four requests, two sessions, one mechanism — labels plus documented policy.

How to Verify a Community Actually Did Something

A community visible in your own routing table proves nothing about the upstream. An upstream that acted on it proves nothing about the rest of the Internet. Verification is a ladder, and each rung answers a different question:

Step 1  Your router          Is the community attached to the correct prefix?
                            Did it survive your outbound policy and leave in Adj-RIB-Out?

Step 2  Your upstream        Did they receive it on the right session?
                            Does their documented policy match it to an action?

Step 3  Looking glasses      Did the expected paths actually change?
                            Is the community still present on the observed route?

Step 4  Multiple vantage     Do different regions see different paths, as intended?
        points               Any unexpected blackholes or stale paths?

White-Face Xiaolu climbs a four-step ladder holding a spyglass, checking the same tagged route card from each height.

Verification is a ladder, not a checkbox: each rung answers a different question about the same tagged route.

Step 1 is on you: outbound policy is a common silent killer — a route-map or a rewrite that drops attributes before they ever leave. Step 2 is a conversation: the honest answer to "did you apply it" is a looking glass, not a reassurance. Step 3 introduces third-party observation; route servers and public looking glasses show whether paths moved and, when a vantage point exposes communities, whether the attribute survived. Step 4 closes the loop across regions, because community-triggered policy is exactly the kind of thing that works in Amsterdam and does nothing in Singapore.

Three habits keep the results honest:

  • A looking glass is one vantage point, not the Internet. Collect several, across regions.
  • Record when and where you checked. Community-driven policy can be changed or withdrawn upstream at any time; an observation is a timestamped fact, not a permanent property.
  • Pair routing observation with origin validation. RPKI vs IRR covers the authorization side; our RPKI & BGP Status Lookup shows the state of your announcement in public data.

Communities, IRR, and RPKI: Different Questions

Every one of these systems answers a different question, and none of them substitutes for another:

System The question it answers
BGP Community How would the sender like this route handled?
IRR Which ASN records the intent to announce which prefix?
RPKI / ROA Which ASN did the address holder authorize to originate the prefix?
Looking glass What does one network currently see?
BGP session Do two routers have a control-plane connection?

The cross-implications are where misconceptions live:

  • A community cannot fix a wrong origin ASN. If your ROA says one AS and you announce from another, no label makes that valid — that is the territory of What Happens After You Get an ASN?.
  • An IRR route object does not carry a community's meaning, and a community does not register your intent in any database a filter builder reads.
  • RPKI Valid says nothing about whether an upstream honored your community — authorization and policy are separate layers.
  • A BGP session in Established state says nothing about whether traffic flows; reachability is decided downstream, prefix by prefix.

Before You Sign: What to Ask an Upstream

This is the checklist to run before committing to a transit provider or BGP-capable host. It matters more than the unit price, because every item on it is something you cannot fix later from your side:

  • Which community types are supported and passed through: Standard, Large, Extended?
  • The exact community values and their documented meaning
  • Which sessions, peers, or regions each community affects
  • Whether any community changes local preference, and by how much
  • Whether the upstream prepends AS_PATH on request, and how many times
  • Whether communities are stripped or rewritten, inbound or outbound
  • What happens when multiple communities appear on the same route
  • Whether BLACKHOLE requires prior arrangement, and its prefix-length limits
  • Whether IRR, ROA, and prefix-length conditions still apply on top
  • Whether a looking glass or test window is available for verification
  • How to withdraw the policy and restore normal propagation

The compressed version: do not ask "do you support BGP communities?" Ask which communities, on which sessions, with what documented effect, how you verify it, and how you undo it. A provider who cannot answer in writing is telling you something.

One boundary note on our own services: SKNK provides ASN sponsorship and IPv6 PA /48 allocations. It does not sell transit or managed BGP — so these questions belong with whoever carries your traffic, not with the LIR that registered your resources. The launch sequence around ROA, IRR, and first announcements is covered in How to Announce an IPv6 /48 via BGP.

FAQ

Are BGP communities universal — does every network honor them?

No. Every network decides independently what to do with received attributes: act on them, pass them on, rewrite them, or drop them. Well-known values have standardized base semantics, but networks still handle them inconsistently enough that RFC 8642 had to be written.

Can a community guarantee my traffic enters through a specific upstream?

No. It can influence any network that honors it — most directly the upstream you send it to. Networks further away select paths by their own criteria. "Steering" with communities is influence, not control.

What is the difference between NO_EXPORT and NO_ADVERTISE?

NO_ADVERTISE is stricter: the route may remain in the receiving router's local RIB, but it must not be passed to any BGP peer. NO_EXPORT allows propagation inside the receiving AS (or confederation), but in a normal non-confederation AS it does not cross the next external eBGP boundary. One keeps the route local; the other keeps it inside the provider's network.

Is the BLACKHOLE community a DDoS protection service?

No. It is a standardized request to discard traffic toward a prefix. Whether it is honored depends on the receiving network's policy, prior arrangement, and your authorization for that prefix. When it works, the traffic is dropped — the prefix is intentionally unreachable, which stops an attack by removing the target.

Can communities replace ROA or IRR records?

No. They operate on different layers. A ROA answers who is authorized to originate a prefix; an IRR route object records routing intent for filter builders; a community asks for handling once the route is already accepted. None of them covers another's job.

Why does my community show locally, but the upstream ignores it?

Check in order: was it attached to the right prefix and the right session; did your outbound policy strip it before Adj-RIB-Out; does the upstream's documentation actually define that value; does the policy need to be enabled per customer. Silent dropping is normal BGP behavior, not an error.

Do ordinary VPS products support BGP communities?

Only products that give you an actual BGP session — and even then it varies. If the product is a tunnel, a bound address, or provider-announced space, there is no BGP announcement of your own, and communities are not in play at all. Where a session exists, run the pre-purchase checklist above.

Should I use Large Communities or standard ones?

Use what your upstream documents as supported. Large communities are the better fit for 4-byte ASNs and modern networks, but a community your provider does not read is decoration. Many networks send both for the same intent.

Conclusion

Communities are the difference between announcing a route and communicating with the networks that carry it. Standard, Large, and Extended are formats; well-known values are edge cases; provider-defined labels are where preference, scope, and blackholing actually happen.

None of it is magic. The attribute carries a request, the provider's documented policy decides what happens, and the effect you can rely on is exactly the effect you have verified — on your router, at the upstream, through looking glasses, and from multiple vantage points.

In One Sentence

A BGP Community is a policy label attached to a route: it can ask the receiving network to change propagation, preference, or path handling — but it is a request, not a global command, and its real effect is whatever the receiver's documented policy, configuration, and your own verification confirm.

References

Continue Reading