skip to content

What does the BGP COMMUNITIES attribute carry, and how do the well-known communities NO_EXPORT and NO_ADVERTISE limit a route's spread?

level: middleimportance: should knowfreq 22%

answer

  1. a tag, not a metric
  2. four octets, ASN first
  3. optional transitive, type 8
  4. own AS versus no peer at all

basics

~20 s

COMMUNITIES is an optional transitive attribute holding a set of 32-bit tags whose meaning operators agree on. A route tagged NO_EXPORT must not be advertised outside the receiving AS or confederation; one tagged NO_ADVERTISE must not be advertised to any peer.

solid answer

~40 s

RFC 1997 defines `COMMUNITIES` (type code 8) as an **optional transitive** attribute: a set of four-octet values, each one a tag saying the route belongs to that group. By convention the first two octets hold an AS number and the last two a value that AS defines, written `64496:100`. Most values mean whatever the defining AS publishes; a few are **well-known** and every community-aware speaker must act on them. `NO_EXPORT` (`0xFFFFFF01`): the receiving AS may give the route to its internal peers but must not advertise it outside the AS, or outside the confederation. `NO_ADVERTISE` (`0xFFFFFF02`): the receiver must not advertise the route to **any** peer, internal ones included. Because the convention reserves only two octets for the AS, four-octet AS numbers need RFC 8092's 12-octet large communities.

go deeper

for a junior

Recall that a community is a tag on a route and that NO_EXPORT keeps a route inside the AS that receives it.

for a middle

Explain the four-octet ASN:value layout, the optional transitive category and the exact scope of NO_EXPORT, NO_ADVERTISE and NO_EXPORT_SUBCONFED.

for a senior

Show what transit does to tags: scrubbing your own range, keeping customers' tags and NO_EXPORT, the union on aggregation, and treat-as-withdraw on a malformed attribute.

for a principal

Decide which community scheme your AS publishes and accepts, including whether to move to large communities for four-octet AS numbers.

## What a community is A **BGP community** is a label attached to a route. It changes nothing on its own: it tells routers, in this AS or another, that the route belongs to a group, so their policy can treat it accordingly. RFC 1997 carries communities in the **`COMMUNITIES`** path attribute: - **type code 8**, **optional transitive**, variable length; - a **set** of **four-octet** values, each one community; - every route that carries the attribute belongs to every community listed. Because it is optional transitive, a speaker that does not recognise `COMMUNITIES` still passes it on. A speaker that does recognise it may **add** the attribute to a route that lacked it and **modify** it by local policy. ## How values are laid out RFC 1997 treats a community as a 32-bit number but makes an administrative convention: | Range | Use | |---|---| | `0x00000000`-`0x0000FFFF` | reserved | | `0xFFFF0000`-`0xFFFFFFFF` | reserved; the well-known communities live here | | everything else | first two octets = an AS number, last two = a value that AS defines | So `64496:100` means "value 100, as AS 64496 defines it". What 100 *does* is up to AS 64496's published policy; how routers act on such tags is routing policy, a separate subject. ## The well-known communities These have global meaning, and RFC 1997 says every community-aware speaker shall implement them. | Community | Value | Receiver must not advertise the route | |---|---|---| | `NO_EXPORT` | `0xFFFFFF01` | outside its AS, or outside its confederation if it is in one | | `NO_ADVERTISE` | `0xFFFFFF02` | to any BGP peer at all | | `NO_EXPORT_SUBCONFED` | `0xFFFFFF03` | to any external peer, including other member ASes of its confederation | Take AS 64496 sending a route for 203.0.113.0/24 to its provider AS 64500 with `NO_EXPORT`: 1. AS 64500's border accepts the route and uses it. 2. It passes the route to its **iBGP** peers, so every router in AS 64500 can reach the prefix. 3. No AS 64500 router advertises it to **AS 64510** or any other external neighbour. With `NO_ADVERTISE` instead, step 2 stops too: only the router that received the route uses it. RFC 1997 counts a stand-alone AS as its own confederation, which is why `NO_EXPORT` means "not outside this AS" for most networks. ## What "transitive" does not promise - **Communities can be changed in transit.** Any AS may add, alter or remove values by policy. - **Operational guidance limits that.** RFC 7454 says operators **SHOULD** scrub inbound communities carrying their **own** AS number in the high-order bits, keeping only those customers may use for signalling, and **SHOULD NOT** remove other communities, generally including `NO_EXPORT`. - **Aggregation merges them.** RFC 1997 says an aggregate formed without `ATOMIC_AGGREGATE` should carry all the communities of the routes it covers. - **Errors withdraw the route.** RFC 7606 treats a `COMMUNITIES` attribute whose length is not a non-zero multiple of 4 as malformed and handles the UPDATE as *treat-as-withdraw*. ## Misreadings that cause outages - **Reading `NO_EXPORT` as "do not send to me".** The tag restricts what the **receiver** advertises onward; the receiver still installs and uses the route. - **Confusing `NO_EXPORT` with `NO_ADVERTISE`.** A route tagged `NO_ADVERTISE` stays on the one router that received it. If other routers in that AS need it, they never get it, and traffic entering the AS elsewhere may have no path to the prefix. - **Expecting an unknown community to do something.** An ordinary value has no effect unless the AS that receives it has published and configured a meaning for it; an unrecognised tag is simply carried. - **Assuming the tag survives every hop.** Any AS may remove communities; a tag that crosses several ASes arrives only if each of them kept it. ## Larger relatives The two-octet AS field cannot hold a four-octet AS number (RFC 6793). Two later attributes fill the gap: - **Large communities** (RFC 8092, type 32, optional transitive): 12-octet values made of a four-octet **Global Administrator**, normally an AS number, and two four-octet operator-defined parts, written `65536:1:2`. - **Extended communities** (RFC 4360, type 16, optional transitive): eight-octet values with a type field. They carry structured tags such as the **Route Target** that VPN services use to decide which routes belong to which customer.

  • An operator with AS number 65540 wants to publish community values for its customers. Why can't it use classic communities in the ASN:value form?
    RFC 1997's convention puts the AS number in the first two octets, so it holds at most 65535. AS 65540 is a four-octet number and does not fit. RFC 8092 large communities solve that with a four-octet Global Administrator and two four-octet local parts, written `65540:1:2`.
  • A customer tags its route NO_EXPORT toward its provider. Can the provider's own customers reach the prefix?
    Within the provider's AS, yes: `NO_EXPORT` lets the provider pass the route to all of its iBGP peers, so its own routers forward to it. The provider must not advertise the route to any external neighbour, so other ASes, including the provider's customers that run BGP with it, do not learn this route from the provider.

saying these in an interview costs you the question

  • NO_EXPORT stops the route from being sent even to iBGP peers in the receiving AS.
  • Communities are well-known mandatory, so every route carries at least one.
  • A community value changes the route's metric directly, like MED.
  • Classic four-octet communities can encode any four-octet AS number.
  • Because COMMUNITIES is transitive, no AS on the path may change it.
  • NO_ADVERTISE allows advertising to internal peers but not external ones.