BGP Deep Dive Part 7: Communities, BGP's General-Purpose Signaling Channel

COMMUNITY has been on the “covered later” list since Part 3. This is later. Every other attribute in this series carries a specific, protocol-defined meaning, ORIGIN says where a route came from, LOCAL_PREF says how much this AS wants it. COMMUNITY carries nothing intrinsic at all. It’s a tag, and what the tag means is whatever the networks attaching and reading it agree it means.

RFC 1997: an opaque 32-bit value, and three the whole internet agrees on

The original COMMUNITY attribute, optional transitive per Part 3’s categories, is a 32-bit value attached to a route, and a single route can carry several of them at once. By convention rather than protocol requirement, most operators format that 32 bits as two 16-bit halves written AS:value, an AS number and a locally meaningful number, but BGP itself doesn’t parse or enforce that structure. The value is opaque; it means whatever the AS that set it, and the AS reading it, have separately agreed it means, usually documented on the setting AS’s own public BGP communities reference page.

Three values are the exception, reserved from the top of the 32-bit space and understood by every compliant implementation without any prior agreement needed:

• NO_EXPORT: don’t advertise this route outside the local AS, or outside the local confederation if the AS is part of one. It can circulate freely on iBGP and confederation eBGP sessions, but never crosses out to a genuine external peer.
• NO_ADVERTISE: stricter still. Don’t advertise this route to any BGP peer at all, keep it entirely local to the router that received it.
• NO_EXPORT_SUBCONFED: the confederation-specific version from RFC 1997, sometimes called LOCAL_AS: don’t advertise outside the local sub-AS. This one only means anything if the AS is confederated per Part 6, and it’s a direct callback to that post’s sub-AS boundary: a route tagged this way can move within the originating sub-AS but stops at the first confederation eBGP hop.

Being optional transitive means these values, and any other community, would normally survive being forwarded across AS boundaries unless something strips them. In practice, plenty of networks do strip incoming communities from customers or peers by default at the edge, precisely because letting an external party inject arbitrary community values into internal routing policy without review is a real operational risk, not a hypothetical one. Whether communities pass through unmodified is itself a policy decision, not a given.

Why 32 bits stopped being enough: extended and large communities

The AS:value convention works cleanly as long as the AS half fits in 16 bits. Part 2 already covered what happens once it doesn’t: RFC 6793’s 4-byte AS numbers need 32 bits on their own, which leaves nothing for the value half of a standard community if the same AS:value convention is kept. Two separate extensions solved this, for different reasons.

Extended communities, RFC 4360, widen the format to 64 bits and add real internal structure: a type octet, a subtype octet, and a value field, rather than one flat opaque number. That structure is what makes extended communities the mechanism behind Route Target and Route Origin, the attributes that make MPLS L3VPN actually work, a preview for Part 10’s multiprotocol BGP coverage. They’re also used for things like link bandwidth signaling and Cisco’s Site of Origin, cases where a genuinely typed value, not just an opaque tag, is useful.

Large communities, RFC 8092, take the more direct route: three separate 4-byte fields, global administrator, local data part 1, local data part 2, specifically so the global administrator field can hold a full 4-byte ASN without needing extended communities’ more complex typed structure. For an operator who just wants the AS:value convention to keep working now that ASNs can be 4 bytes, large communities are the closer conceptual match to what standard communities always were, just with room for the number that no longer fits.

What communities are actually for, in practice

The theoretical description undersells how much real internet traffic engineering runs through this one mechanism. Providers publish community reference tables the way an API publishes its documentation: attach this value to get prepended by one hop toward this specific peer, attach this one to set a particular LOCAL_PREF tier, attach this one to withdraw the announcement from one specific upstream while keeping it live everywhere else. None of that behavior is built into BGP. It exists because the receiving network wrote a route-map, or its policy-language equivalent, that matches on a specific community value and takes a specific configured action, and published what that value does so customers and peers could use it deliberately.

BLACKHOLE: the second well-known value, and the clearest example of the whole idea

RFC 7999 adds a fourth well-known value, BLACKHOLE, 65535:666, specifically for remote-triggered blackholing: a network under a volumetric attack tags the affected prefix with this community when announcing it to an upstream transit provider or at an internet exchange route server, and the receiving network, if it has configured its own policy to honor the convention, installs a discard route for that prefix. The attack traffic gets dropped at the upstream’s edge, far closer to its source, instead of consuming the target’s own inbound bandwidth all the way to the point of attack.

BLACKHOLE is worth sitting with as the cleanest possible illustration of what this entire post has been building toward: nothing in BGP itself null-routes anything. The community is a 32-bit number. It does exactly nothing on its own. It works only because the network setting it and the network reading it have both configured behavior around that specific value, one to signal, one to act, and because enough of the internet has converged on treating 65535:666 the same way that it functions as a de facto standard rather than a purely bilateral agreement. That’s communities in one example: not a mechanism with built-in meaning, but a channel, and the meaning is whatever the two ends of it have agreed to put there.

Part 8 moves from what gets signaled to how it gets enforced: prefix-lists, AS-path filtering, and the policy-language concepts, kept vendor-neutral here, that actually apply communities, and every other attribute this series has covered, to real routing decisions.