17 Communities

A BGP Community is an optional transitive attribute used to tag routes so that policy can be applied to a group of prefixes at once, instead of matching each prefix individually. Communities are one of the most important tools for scalable path control.

The core idea

A Community is a label attached to routes. Routers can match on that label and apply policy (filtering, or setting other attributes) to every route carrying it. This lets an operator classify routes into groups and act on the whole group with a single policy, rather than listing prefixes one by one.

Because Community is optional transitive, a router that does not understand a given community still passes it on to its peers.

Format

A community is a 32-bit value, most often written in the format AS:value (for example 65001:100), where the first part is typically the AS that set it and the second is a locally meaningful number. This is the new-format notation.

Well-known communities

Some community values are standardized and have a fixed meaning across implementations. The most important:

  • no-export: do not advertise this route to eBGP peers (it may still be sent within the AS and to sub-AS confederation peers).
  • no-advertise: do not advertise this route to any peer at all.
  • local-as (also called no-export-subconfed): do not advertise this route outside the local sub-AS in a confederation.
  • internet: advertise the route normally (no restriction).

Why communities matter for design

Communities are the mechanism behind the policy design used by ISPs and large enterprises. Rather than maintaining huge per-prefix policies, an operator tags routes with communities at the edge (for example, “customer route,” “peer route,” “advertise with lower preference”), and then applies policy based on those tags elsewhere. This is what separates knowing what a community is from designing policy with communities.

Extended and large communities

The original community is 32-bit. Two extensions exist for cases where more space or structure is needed:

  • Extended communities (64-bit): used heavily in MPLS VPN (for example the Route Target that controls VPN route import/export).
  • Large communities (96-bit): designed to hold full 32-bit ASNs cleanly, since the original AS:value format cannot fit a 4-byte ASN in its first half.

How communities are applied

  • Setting a community: a route-map matches the target routes and sets the community value.
  • Acting on a community: a community-list matches routes carrying a given community, and a route-map then filters them or modifies their attributes.
  • Propagation must be enabled: by default, Cisco does not send the community attribute to a neighbor unless configured to do so with neighbor <ip> send-community.

Communities are not sent by default

A common mistake is setting a community and expecting the neighbor to see it. Cisco does not advertise the community attribute to a peer unless send-community is enabled for that neighbor.

Self-check

Q1 — What is a BGP Community used for?

A) Preventing loops between AS
B) Tagging routes so policy can be applied to a group of prefixes at once
C) Setting the next-hop for iBGP routes
D) Negotiating session timers

Q2 — What does the well-known community no-export do?

A) Blocks the route from all peers, internal and external
B) Prevents the route from being advertised to eBGP peers
C) Advertises the route normally with no restriction
D) Removes the route from the BGP table

Q3 — What class of attribute is a Community?

A) Well-known mandatory
B) Optional transitive
C) Optional non-transitive
D) Cisco-proprietary and local

Q4 — Why might a neighbor not see a community you set?

A) Communities expire after 60 seconds
B) Cisco does not send the community attribute unless send-community is enabled for that neighbor
C) Communities only work on iBGP
D) The community was stripped by AS-PATH