Abstract

BGP communities are route attributes that carry policy signals alongside prefix advertisements, allowing operators to influence routing decisions across AS boundaries without bilateral configuration changes on every peer. Standard communities (RFC 1997) pack a 32-bit value into two 16-bit fields - ASN and a locally significant tag - and are the workhorse of traffic engineering at IXPs and transit providers. Large communities (RFC 8092) extend this to a 96-bit structure with a 32-bit global administrator field, solving the encoding problem that arose when 4-byte ASNs made the original format too cramped. Together they form the primary signaling mechanism for prepending, blackholing, localpref adjustment, and no-export policies in production networks carrying tens of thousands of prefixes.

Community-Based Blackholing and RTBH

Remotely Triggered Black Hole (RTBH) filtering, documented in RFC 5635, uses BGP communities to signal DDoS mitigation actions across an AS boundary. The customer advertises the victim prefix with a well-known blackhole community (typically 65535:666 or a provider-specific variant), and the upstream router matches the community and drops traffic destined for that prefix at the edge - before it saturates the customer’s link. Unicast RTBH drops all traffic to the destination; flowspec (RFC 5575 / RFC 8955) extends this to match on source prefix, port, and protocol, enabling more surgical filtering. Major transit providers including Lumen, NTT, and RETN support RTBH communities, and the coordination overhead is low enough that DDoS response time-to-mitigation is measured in minutes once the automation is in place.

Localpref and MED Engineering

Operators use communities to request that upstream providers adjust LocalPref on received routes, influencing inbound traffic distribution without touching the upstream’s configuration directly. A common pattern: advertise the same prefix to two transit providers, tag the secondary with a community requesting lower LocalPref, and the upstream shifts inbound traffic to the primary path. The mirror problem - outbound traffic engineering - uses AS-path prepending (also triggered by community) or MED (Multi-Exit Discriminator). MED is compared only between paths from the same AS and only if the upstream does not override it, so its effect is less predictable across providers. Well-documented provider community schemas (Cogent, Hurricane Electric, and Zayo all publish theirs) make this tractable; undocumented communities used by internal tools require careful prefix-list filtering at peering boundaries to prevent leaking internal signals to external peers.

Large Communities and Modern Policy Frameworks

Large communities solve a real problem: a 4-byte ASN leaves no bits for a meaningful tag in the standard 32-bit community format. RFC 8092 large communities use a 4-byte Global Administrator, a 4-byte Local Data Part 1, and a 4-byte Local Data Part 2, giving operators a clean namespace for complex policy encoding. Modern routing policy frameworks including OpenConfig’s BGP model and BIRD 2.x’s filter language handle large communities natively. The operational discipline that matters most is maintaining a community registry - a documented mapping of community values to policy actions - and enforcing it via automated validation in the route policy management system. Without a registry, community soup accumulates over years and route policy debugging becomes archaeology.