BGP communities — the optional transitive attribute, the AA:NN format, and well-known communities

A BGP community is a 32-bit tag that an operator can attach to a route and that travels with the route as it traverses the Internet. The community is just a number; the meaning is in the contract between the operator who sets it and the operator who reads it. The four well-known communities — no-export, no-advertise, no-export-subconfed, and no-peer — are special: the meaning is in the BGP specification itself, not in a private contract, and every conforming BGP speaker must act on them without further configuration.

This lesson is the foundation for the rest of Part XXIX. vyos-xxix-02-community-config writes the configuration that manipulates communities, vyos-xxix-03-large-communities and vyos-xxix-04-extended-communities extend the format, vyos-xxix-05-community-routing builds policy on top, and vyos-xxix-06-community-troubleshoot walks the failure modes.

Where the community lives in the BGP UPDATE

A BGP UPDATE carries a list of path attributes between the withdrawn routes and the NLRI. The community attribute is Path Attribute code 8, type Optional Transitive. The wire format is one or more 4-octet values, each one a 32-bit tag.

flowchart LR
  subgraph UPDATE["BGP UPDATE message"]
    W["Withdrawn Routes"]
    PA["Path Attributes"]
    NLRI["NLRI (announced prefixes)"]
  end
  subgraph PA["Path Attributes block"]
    ORIGIN["ORIGIN (code 1)"]
    ASPATH["AS_PATH (code 2)"]
    NH["NEXT_HOP (code 3)"]
    MED["MED (code 4)"]
    LOC["LOCAL_PREF (code 5)"]
    COMM["COMMUNITY (code 8)"]
    OTH["others..."]
  end
  COMM -->|"AA:NN × N"| NLRI

The community attribute is a single Path Attribute that contains N values, all packed back to back. A route can carry zero, one, or many communities. The attribute is Optional Transitive: if a speaker does not understand communities, it must propagate the attribute unchanged; if a speaker does understand communities, it may modify the value list.

The AA:NN format

The 32-bit value is conventionally split into two 16-bit halves. The left half is the Autonomous System number (AA), the right half is a value the operator chooses (NN). The canonical display is AA:NN:

The AA:NN display is purely cosmetic. On the wire it is four bytes. The VyOS and FRR tooling uses the AA:NN notation by default; the raw hex is shown with show ip bgp <prefix> json or with vtysh’s longer-form output.

The AA portion sits in the upper 16 bits, NN in the lower 16. The numerical value of the whole 32-bit field is AA * 65536 + NN. The community 64512:100 is the integer 64512 * 65536 + 100 = 4227858436.

The four well-known communities

RFC 4271 reserves four values in the private AS range 65535. Every conforming BGP speaker must interpret them and act on them without configuration. The reserved values are:

The actions are mandatory. An operator who sets no-export on a route is making a promise that the route will not leave the local AS, regardless of how the inbound policy is configured. The transmission of the value is best-effort in the sense of the Optional Transitive flag — if a peer in the path does not understand communities, the attribute is propagated unchanged — but the action is mandatory where the attribute is understood.

flowchart TD
  R["Route received with community X"]
  R --> Q{"Is X one of the four well-known values?"}
  Q -->|no| N["No action. Propagate per local policy and outbound route-map."]
  Q -->|"yes (no-export)"| NE["Strip on eBGP advertisement. Inside the AS, propagate normally to iBGP peers."]
  Q -->|"yes (no-advertise)"| NA["Strip on any advertisement. Route stays local to the receiving router."]
  Q -->|"yes (no-export-subconfed)"| NS["Strip on eBGP advertisement AND on advertisement across the confederation boundary. Inside the local sub-AS, propagate normally."]
  Q -->|"yes (no-peer)"| NP["Strip on advertisement to peers in the same route-server set. Outside the set, advertise normally."]

The four values are not configurable. The operator cannot redefine no-export to mean “advertise to eBGP but with prepends”. The values are reserved by the protocol.

Reading communities on VyOS 1.5 LTS

The FRR-backed show ip bgp translation on VyOS 1.5 LTS shows the community list inline. The operator who sees the line Community: 64512:100 no-export knows the route carries two communities: the private 64512:100 and the well-known no-export.

vyos@vyos:~$ show ip bgp 198.51.100.0/24
BGP routing table entry for 198.51.100.0/24
Paths: (2 available, best #1)
  Path 1 (best):
    192.0.2.2 from 192.0.2.2 (10.255.0.1)
      Origin IGP, metric 0, localpref 100, weight 0, valid, external
      Community: 64512:100 no-export
      Last update: 2026-08-15 09:14:23+00:00
  Path 2:
    203.0.113.5 from 10.0.0.5 (10.255.0.5)
      Origin IGP, metric 0, localpref 100, weight 0, valid, internal
      Community: 64512:100
      Last update: 2026-08-15 09:14:31+00:00

The well-known value is displayed as no-export rather than as 65535:65281 because FRR recognises the conventional numeric value and substitutes the keyword. The raw numeric value is what is on the wire and what is in the UPDATE Path Attribute.

Propagation rules in detail

The community attribute is Optional Transitive. The two flags interact with the propagation logic:

• Optional — if a speaker does not recognise the attribute, it does not have to act on it. Communities are optional in this sense; an implementation that predates RFC 1997 may treat the attribute as unknown.
• Transitive — if the speaker propagates the route, it must propagate the attribute unchanged. The Partial flag is set if the speaker does not fully understand the attribute.

In practice on a modern router (VyOS 1.5 LTS, FRR 10.x), every speaker in the path understands the community attribute. The propagation rule reduces to: the attribute is passed through verbatim unless the outbound route-map explicitly modifies it.

The difference between no-export and no-advertise is the typical point of confusion. no-export says “do not advertise to eBGP peers, but you may still propagate to iBGP peers inside the AS”. no-advertise says “do not advertise to anyone, including iBGP peers — the route is local to the receiving router only”.

sequenceDiagram
  participant P as Peer A (eBGP, AS 64512)
  participant R1 as Router X (local AS)
  participant R2 as Router Y (local AS)
  participant U as Peer B (eBGP, AS 64513)
  Note over P,R1: P sends 198.51.100.0/24 with no-export
  R1->>R2: iBGP update with no-export
  R2->>R2: Strip on eBGP advertisement
  R2-->>U: 198.51.100.0/24 (without no-export)
  Note over R2,U: no-export respected: route left the AS, but without the no-export marker

The route leaves the AS, but the no-export marker is stripped — the next AS is not bound by it. The marker is only a contract between the original setter and the receivers in the same path.

How the result is validated

The validating commands are:

show ip bgp
show ip bgp <prefix>
show ip bgp community
show ip bgp community <value>
show ip bgp community no-export
show ip bgp community no-advertise
show ip bgp community no-export-subconfed
show ip bgp community no-peer
show ip community-list

The first two show the BGP table. The third lists all unique community values present in the table. The fourth filters to a specific value. The show ip bgp community no-export form is a built-in filter for the well-known values.

For raw wire-format inspection, tcpdump -n -i any -vvv 'port 179' captures the UPDATE and the Path Attribute block, but the BGP plain-text encoding is verbose and the operator should read the table visualisation first.

How it fails

Production failure modes the engineer must recognise:

• The operator sets no-export expecting the route to be hidden from peers. The route is hidden from eBGP peers, but it is still propagated to iBGP peers inside the AS. The mistake is to confuse no-export with no-advertise.
• The peer sends a route with no-export and the operator configures a route-map that strips it on advertisement. The route is now advertised to eBGP peers without the marker. The peer expected the original AS to honour the marker; the operator’s outbound policy broke the contract.
• The route is shown with Community: 64512:100 but the operator expected the well-known keyword. The FRR display substitutes only the four reserved values; everything else is shown in AA:NN form. The operator who sees a numeric value is looking at a private community, not a well-known one.
• The community attribute is silently dropped by an intermediate speaker that does not understand it. The Partial bit is set in transit, and the route arrives without the expected community. The operator must check the partial flag and the ingress of the partial flag.

Rollback

Community changes are configuration changes. The standard rollback path applies:

• compare to see the diff before commit.
• commit-confirm <timeout> for any remote change.
• rollback N; commit; save to revert to the previous configuration.
• load /config/archive/<known-good-file>; commit; save to revert to a specific snapshot.

The operator who changes the community policy must also know how to roll back the change. The community itself is in the BGP table (and therefore in the FIB) and rollback only affects the policy that adds, strips, or matches communities on incoming or outgoing routes.

Production discipline

Cross-course references

The Linux course’s XIX-Linux-NetFoundations covers the FIB. The OPNsense course’s XXX-OPNsense-DynamicRouting covers the equivalent community handling on the firewall side. The BGP lessons vyos-xxvi-02-as-path and vyos-xxvi-05-community cover the path attributes that communities complement; the lesson vyos-xxix-02-community-config writes the configuration that sets and matches communities, and vyos-xxix-06-community-troubleshoot walks the debugging of community propagation failures.

Quiz