BGP communities

Numeric tags attached to BGP routes so that networks can group destinations and request how they are treated.

The COMMUNITIES attribute (RFC 1997, August 1996, type code 8) carries four-octet tags; large communities (RFC 8092, February 2017, type code 32) carry twelve-octet ones. The reader meets them in route details and in providers' policies, where a tag can mean learned from a customer or do not export to a given AS.

RFC 1997 defines a community as a group of destinations that share some common property, and the attribute as optional and transitive. By convention a four-octet value holds an AS number in the first two octets and a value defined by that AS in the last two. A speaker may use the tags to control which routing information it accepts, prefers or passes on to other neighbours.

Some values are well known. NO_EXPORT (0xFFFFFF01) keeps a route inside the AS or confederation, NO_ADVERTISE (0xFFFFFF02) keeps it from every BGP peer, and NO_EXPORT_SUBCONFED (0xFFFFFF03) completes the original set. The IANA registry has since added others, among them BLACKHOLE (RFC 7999) and GRACEFUL_SHUTDOWN (RFC 8326).

Four-octet AS numbers broke the convention, because a two-octet field cannot hold a four-octet AS number. Large communities answer with a four-octet global administrator and two four-octet operator-defined fields, written like 64496:4294967295:2. RFC 8195's examples separate tags that inform, such as 64497:3:2 for a route learned from a customer, from tags that request an action, such as 64497:4:64498 for do not export to AS 64498. An action tag is a request: it works only where the receiving AS defines and honours it.

Also known as: bgp community, communities attribute, large communities, large community, no_export, well-known communities

Sources

← All glossary entries