BGP Communities: The Feature Everyone Ignores
BGP communities ship on every router. Most operators use three of them. Large communities, RFC 8092, selective announcement, RTBH signaling — the full feature set sits untouched in most networks.
BGP communities have existed since RFC 1997 in 1996. They ship in every BGP implementation on every router from every vendor. The median operator uses: NO_EXPORT (0xFFFFFF01), NO_ADVERTISE (0xFFFFFF02), and maybe one or two provider communities for traffic engineering. 30 years available, most networks use 5% of the feature.
A community is a 32-bit tag attached to a BGP route. The tag travels with the route — every AS that receives the route also receives its community tags. Operators define the meaning. Routers enforce policy based on those values at import and export filters.
Standard communities: 32 bits total, formatted as ASN:value (65000:100). Maximum 16-bit ASN means values above 65535 require extended communities. If your ASN is four bytes (32-bit), you can't represent it correctly in standard communities — which is why large communities exist.
RFC 8092 (2017) defines large communities: three 32-bit fields, formatted as ASN:LocalDataPart1:LocalDataPart2. Your 32-bit ASN fits in the first field. Two 32-bit data fields for meaning. Vastly larger semantic space than standard communities.
Adoption is low despite universal support in modern implementations (Cisco IOS/XE from 15.3S, Juniper JUNOS from 16.1, FRR from 2.0). The limiting factor is documentation and operator awareness — most network teams inherit standard community policies and never revisit them.
Standard approach: maintain separate prefix-lists per peer. Scalability ceiling: every new peer requires updating every affected prefix-list. Community approach: tag each prefix at origin, enforce at export filter.
Adding a new peer: configure the export filter to match the community scheme. No prefix-list updates. The policy lives in the prefix tag, not in per-peer configuration.
Remote Triggered Black Hole uses communities to signal upstream providers to drop traffic destined for a specific prefix at their edge, before it reaches your network. During a DDoS against 192.0.2.1/32, announce that /32 with the blackhole community (typically 65535:666 or a provider-specific value). The upstream drops all traffic at their POP.
Requires: pre-agreement with upstreams on the blackhole community value, and a static route to Null0 for the announced prefix on your edge. Without the Null0 route, your router forwards the traffic even after announcing the blackhole — defeating the purpose.
Tag every route at origin with its source type: 65000:1001 for datacenter prefixes, 65000:1002 for customer allocations, 65000:1003 for management networks. Security teams can verify that no management prefix (65000:1003) appears externally by querying route collectors for your ASN's community tags. PeerCortex does exactly this — flags prefixes either missing expected community tags or carrying unexpected ones.
The barrier to better community usage is documentation, not capability. Most schemes are implemented by one engineer, documented nowhere, and understood by nobody else. When that engineer leaves, the community scheme becomes configuration archaeology.
The fix: a community registry in your NMS or Git repo documenting every community value, its meaning, which routers enforce it, and when it was added. Communities without documentation are technical debt — they're policy that nobody can verify is correct.