CONCEPT Cited by 1 source
BGP community¶
A BGP community is a 32-bit (or 64-bit for large communities) tag attached to a route that flows alongside the AS path in BGP advertisements. It carries no protocol-defined meaning — communities are purely a signaling mechanism between cooperating ASes, with semantics agreed locally or documented publicly by the AS operator.
Defined in RFC 1997 (standard communities) and RFC 8092 (large communities).
Common uses¶
- Route-origin tagging: mark a route at ingress with "I learned this from a customer" / "a peer" / "a provider". Egress policy then filters by community rather than trying to re-derive origin from AS path.
- Traffic-engineering signals: tell a neighbor "do not advertise this to peer X", "prepend twice to region Y", "set local-pref 200". Most large transit networks publish a "BGP community cheat sheet."
- Blackhole / RTBH: tag a prefix to request remote- triggered blackhole filtering upstream during a DDoS event.
- No-export / no-advertise (RFC 1997 well-known communities): instructions that apply globally across all BGP implementations.
Why they matter for route-leak prevention¶
The cleanest export policy for a network toward its providers / peers is: advertise only routes that (a) match an IRR-derived prefix list and (b) carry the ingress-set "learned from customer" community tag. Property (b) prevents the exact hygiene failure Cloudflare hypothesises for AS8048: a prefix that appears in the customer cone's prefix list but was learned indirectly via a provider will be missing the customer tag and will be filtered out of the export.
This is the customer- community-tag export policy pattern.
Seen in¶
- sources/2026-01-08-cloudflare-a-closer-look-at-a-bgp-anomaly-in-venezuela — Cloudflare's alternative explanation names "if their export policy toward AS52320 only matched on IRR-generated prefix list and not a customer BGP community tag, for example, it would make sense why an indirect path toward AS6762 was leaked back upstream by AS8048."