How BGP Communities Work: Tagging and Controlling Routes

BGP does more than just carry reachability information across the internet. Through an attribute called communities, BGP allows networks to attach metadata to routes -- invisible tags that signal intent, trigger policy actions, and coordinate behavior between autonomous systems. Communities are the mechanism behind blackholing, traffic engineering, geographic tagging, and much of the routing policy that shapes how traffic flows across the internet.

Without communities, every routing decision would depend solely on the AS path, prefix length, and local preference. Communities add a signaling layer on top of BGP that lets networks communicate why a route should be treated a certain way, not just where it goes.

What is a BGP Community?

A BGP community is an optional transitive attribute (attribute type code 8) attached to a BGP route announcement. It is a label -- a numeric tag -- that carries no inherent meaning to the BGP protocol itself. Instead, its meaning is defined by convention between networks. When a router receives a route with a community attached, it can match on that community value and apply specific routing policies: accept the route, reject it, modify its attributes, or propagate it selectively.

Communities flow with the route as it propagates through the internet. A community attached by the originating AS can be read and acted upon by every AS in the path. Networks can also add, remove, or modify communities as routes pass through their infrastructure.

Standard Communities (RFC 1997)

The original BGP community attribute was defined in RFC 1997 (August 1996). A standard community is a 32-bit integer, conventionally written in ASN:value format -- two 16-bit numbers separated by a colon.

For example, the community 13335:10090 means:

This convention -- using the ASN as the first number -- avoids collisions between different networks' community namespaces. Each AS defines its own set of community values and publishes their meanings (typically in their IRR objects, peering documentation, or NOC pages).

The Structure of a Standard Community

  32 bits total
  +----------------+----------------+
  |   High 16 bits |   Low 16 bits  |
  |   (ASN)        |   (Value)      |
  +----------------+----------------+
  Example: 64496:100 = 0xFBF00064

Because the ASN field is only 16 bits wide, standard communities can only reference 2-byte ASNs (0-65535). This became a significant limitation as 4-byte ASNs (up to 4,294,967,295) were introduced. This limitation was one of the key drivers behind the development of large communities (RFC 8092), discussed later in this article.

Well-Known Communities

RFC 1997 and subsequent RFCs reserve several community values with globally agreed-upon meanings. These well-known communities are recognized and acted upon by any compliant BGP implementation, regardless of which network attached them.

NO_EXPORT (0xFFFFFF01)

A route tagged with NO_EXPORT must not be advertised outside the local AS (or confederation). If Google (AS15169) sends a route to NTT (AS2914) with the NO_EXPORT community, NTT will install the route in its routing table but will not re-advertise it to any of its other eBGP peers. The route stays confined to NTT's network.

This is commonly used when a network wants to influence routing at a direct neighbor without having that influence propagate further. For instance, a customer might announce a backup prefix to a transit provider with NO_EXPORT to ensure it is only used as a last resort -- the transit provider knows the route but does not tell anyone else about it.

NO_ADVERTISE (0xFFFFFF02)

NO_ADVERTISE is stricter than NO_EXPORT. A route tagged with this community must not be advertised to any BGP peer, including iBGP peers within the same AS. The route is used only by the router that receives it. This is rarely used in practice but provides a mechanism for injecting a route into a single router's table without any further propagation.

NO_EXPORT_SUBCONFED (0xFFFFFF03)

Also known as LOCAL_AS, this community restricts the route to the local sub-AS within a BGP confederation. It must not be advertised to external eBGP peers or to other sub-ASes in the confederation. This is relevant only for networks that use BGP confederations to partition a large AS into smaller internal routing domains.

NO_PEER (0xFFFFFF04)

Defined in RFC 3765, NO_PEER advises that a route should not be advertised to bilateral peers. A transit provider receiving a route with NO_PEER should still advertise it to its customers and transit providers, but should not send it to settlement-free peers. This is used to prevent routes from leaking sideways across peering relationships.

BLACKHOLE (0xFFFF029A)

Defined in RFC 7999, the BLACKHOLE community (65535:666) is a standardized signal requesting that the receiving network drop (blackhole) all traffic destined for the tagged prefix. This is the internet's emergency brake for DDoS mitigation, discussed in detail below.

Well-Known BGP Communities NO_EXPORT 0xFFFFFF01 Do not advertise outside local AS NO_ADVERTISE 0xFFFFFF02 Do not advertise to any peer LOCAL_AS 0xFFFFFF03 Do not advertise outside sub-AS NO_PEER 0xFFFFFF04 Do not advertise to bilateral peers BLACKHOLE 65535:666 Drop all traffic to this prefix Scope: eBGP boundary All peers Confederation Peering only DDoS

Extended Communities (RFC 4360)

Standard communities are simple but limited: 32 bits is not enough to encode complex policy information, and there is no type structure -- the semantics of a community value are entirely dependent on external documentation. Extended communities, defined in RFC 4360, address these limitations with a more structured 64-bit format.

An extended community is 8 bytes (64 bits) composed of:

The type field is critical because it tells routers how to parse the remaining bytes. This means extended communities are self-describing -- unlike standard communities, where meaning is entirely by convention.

Route Target (RT)

The most widely used extended community is the Route Target, written as RT:ASN:value. Route targets are essential to MPLS VPNs (RFC 4364) and EVPN. They control which VPN routing tables (VRFs) a route is imported into. When a PE router receives a VPN route, it checks the route target and imports the route only into VRFs configured to accept that RT.

For example, RT:64496:100 might identify all routes belonging to a particular customer's VPN. Every PE router serving that customer imports routes tagged with this RT into the customer's VRF.

Route Origin (Site of Origin)

The Route Origin extended community (SoO:ASN:value) identifies the site from which a route was learned. This is used in multi-homed VPN scenarios to prevent routing loops -- if a PE router sees a route with a Site of Origin matching a locally connected site, it knows the route originated from a site it already serves and should not be re-imported.

Other Extended Community Types

Extended communities are particularly important for service provider networks running MPLS L3VPN, VPLS, or EVPN services. They are less commonly seen in the public internet DFZ (default-free zone) routing table, where standard and large communities dominate.

Large Communities (RFC 8092)

As the internet grew beyond 65,535 autonomous systems and 4-byte ASNs (defined in RFC 6793) became common, standard communities hit a wall: the 16-bit ASN field could not represent ASNs larger than 65535. A network like AS397143 simply could not be encoded in the first half of a standard community.

Large communities, defined in RFC 8092 (February 2017), solve this with a 96-bit (12-byte) format composed of three 32-bit fields:

  96 bits total
  +------------------+------------------+------------------+
  |  Global Admin    |  Local Data 1    |  Local Data 2    |
  |  (32 bits)       |  (32 bits)       |  (32 bits)       |
  +------------------+------------------+------------------+
  Written as: GlobalAdmin:LocalData1:LocalData2
  Example:    397143:100:0

The three-field structure provides a natural namespace: the ASN identifies who defined the community, the first data field identifies the type of action, and the second data field provides a parameter. For example, a network might define:

Large communities are now widely supported by major router vendors (Cisco IOS-XR, Junos, BIRD, OpenBGPd, FRRouting) and are the recommended format for new community-based policy designs.

DDoS Blackholing with Communities

One of the most critical real-world uses of BGP communities is remotely triggered blackholing (RTBH) -- the ability to ask upstream networks to drop traffic destined for a specific IP address that is under DDoS attack.

The mechanism works as follows:

  1. A network detects a volumetric DDoS attack targeting one of its IP addresses, say 203.0.113.1
  2. The network announces a host route (203.0.113.1/32) to its upstream provider with the BLACKHOLE community (65535:666) or the provider's specific blackhole community
  3. The upstream provider receives the tagged route and sets the next-hop to a null interface (discard route) on all its edge routers
  4. Attack traffic is dropped at the upstream provider's network edge, before it can saturate the victim's links

Most tier-1 and tier-2 transit providers support blackhole communities. Common provider-specific blackhole community values include:

The standardized BLACKHOLE community (65535:666) from RFC 7999 was introduced to provide a single, universally recognized value. Networks supporting it will blackhole any route tagged with this community without requiring provider-specific configuration. However, many operators still use their own community values in addition to or instead of the standard one.

The tradeoff of blackholing is significant: it stops the attack traffic but also drops all legitimate traffic to the target IP. The victim IP becomes completely unreachable. For this reason, blackholing is typically a last resort used only when the attack volume threatens to overwhelm the entire network, not just the target.

Traffic Engineering with Communities

Beyond blackholing, communities are the primary tool for traffic engineering -- controlling which paths traffic takes into and out of a network. Transit providers publish community values that their customers can attach to routes to influence how those routes are propagated.

Controlling Announcement Scope

A customer can use communities to control which of a provider's peers see their routes:

For example, if a customer of NTT (AS2914) wants to prevent NTT from announcing a specific prefix to Cogent (AS174), the customer tags the route with the appropriate community. NTT's routers match on this community in their export policy and suppress the announcement to AS174.

AS Path Prepending via Communities

Many providers offer community-based prepending -- instead of the customer doing the AS path prepending themselves, they tag the route with a community that instructs the provider to prepend:

This is more flexible than the customer prepending on their own, because it can be selectively applied per upstream peer. The customer sends a single clean announcement and relies on the provider's policy to apply differential prepending.

Local Preference Manipulation

Some transit providers allow customers to influence the local preference assigned to their routes within the provider's network. A higher local preference makes a route more preferred. This lets customers designate primary and backup transit links without relying solely on AS path length:

Traffic Engineering with BGP Communities Customer AS64496 203.0.113.0/24 Transit A (AS2914) Primary upstream Transit B (AS174) Backup upstream Peer X (AS6939) Receives announcement Peer Y (AS3356) Blocked by community X community: 2914:110 communities: 174:90, 174:0:3356 Primary (LP 110) Backup (LP 90)

Geographic and Informational Tagging

Many networks use communities to tag routes with metadata about where or how the route was learned. This tagging does not directly influence routing decisions but provides valuable information for network operators analyzing their routing table.

Geographic Communities

Networks often tag routes with the geographic location where they were received:

For example, a transit provider might tag a route learned at their Frankfurt IXP connection with ASN:1000:276 (where 276 is the ISO numeric code for Germany). This allows downstream networks to make routing decisions based on geographic proximity -- preferring routes learned in the same region.

Route Type and Relationship Communities

Networks commonly tag routes to indicate how they were learned:

These informational communities are used internally by the network's own routing policy, and are sometimes propagated to customers who can use them for their own traffic engineering decisions.

How ISPs Use Communities: A Real-World Example

To illustrate how communities work in practice, consider a typical scenario involving a mid-size enterprise network (AS64496) connected to two transit providers.

The enterprise announces its prefix 203.0.113.0/24 to both providers but wants the following behavior:

  1. Transit A (AS2914) should be the primary path for inbound traffic
  2. Transit B (AS174) should be the backup, used only if Transit A fails
  3. Transit B should not announce the prefix to one specific peer (AS3356) due to a known routing issue

The enterprise achieves this entirely through communities:

Transit B's routers match on these communities in their import and export policies, automatically applying the requested behavior without any manual configuration by Transit B's operators. The enterprise controls its traffic engineering entirely from its own routers by manipulating community values.

Community-Based Route Filtering

Communities play a central role in route filtering -- the process by which networks decide which routes to accept, reject, or modify. There are several layers of community-based filtering:

Customer-to-Provider Filtering

When a customer sends routes to a transit provider, the provider typically:

  1. Strips all existing communities from the route (to prevent community spoofing)
  2. Applies the customer's authorized community values based on the customer's contract
  3. Tags the route with internal informational communities (customer ID, region, PoP)

Provider-to-Peer Filtering

When a provider sends routes to a peer, it filters based on communities:

  1. Checks for NO_EXPORT and NO_PEER communities -- suppressing routes as requested
  2. Checks for selective announcement communities -- only sending the route if the peer's ASN matches
  3. Applies prepending as directed by the customer's communities
  4. Strips internal communities before sending (to avoid leaking operational metadata)

IXP Route Server Communities

Internet Exchange Points that operate route servers use communities extensively. The route server itself does not forward traffic -- it redistributes BGP routes between IXP participants. Communities control which participants receive which routes:

This allows IXP participants to implement selective peering policies through the route server without establishing bilateral BGP sessions with every other participant.

Community Propagation and Stripping

An important operational detail is how communities propagate -- or are prevented from propagating -- as routes traverse multiple autonomous systems.

Standard communities are defined as a transitive optional attribute, meaning they should be passed along to eBGP peers by default. In practice, however, many networks strip communities that are not relevant to their operation before re-advertising routes. A typical policy is:

This means a community attached by AS64496 might survive one hop to its direct transit provider but will likely be stripped before reaching a second-hop provider. Networks that want communities to propagate further must coordinate with each intermediate AS.

Extended communities have both transitive and non-transitive variants, controlled by the high bit of the type field. Non-transitive extended communities are automatically stripped at eBGP boundaries.

Comparing Community Types

Here is a summary of the three community types and their characteristics:

Standard Extended Large
RFC 1997 4360 8092
Size 32 bits 64 bits 96 bits
Format ASN:value Type:ASN:value ASN:val1:val2
ASN support 2-byte only 2 or 4-byte 4-byte
Typed No Yes No
Primary use Internet policy VPN / MPLS / EVPN Internet policy
DFZ prevalence Very common Rare Growing

Operational Considerations and Best Practices

Community Hygiene

Networks should practice good community hygiene:

Community Limits and Performance

There is no protocol-level limit on how many communities can be attached to a single route, but practical limits exist. Each community consumes memory on every router that processes the route. Routes with hundreds of communities inflate the BGP RIB (Routing Information Base) and slow down route processing. Some router implementations impose soft limits (typically 32 or 64 communities per route) and may truncate or drop communities beyond that threshold.

Security Implications

Communities are a powerful policy tool, which means they are also a potential attack vector. If a network fails to filter inbound communities from customers, a malicious customer could:

Proper inbound filtering -- stripping all communities and only applying authorized ones -- is essential. RPKI validates route origin but does not validate communities; community security depends entirely on each network's policy implementation.

Communities in the Global Routing Table

Studies of the global routing table show that communities are ubiquitous. The vast majority of routes in the DFZ carry at least one community. Research by CAIDA and RIPE NCC has found:

When you look up an IP address or prefix in a BGP looking glass, the communities attached to the route provide valuable context about how the route was learned, where it entered the collector's network, and what policies have been applied to it.

Explore BGP Communities

You can see communities in action by looking up routes in the looking glass. Examine the routing details for well-connected networks to see the community tags attached to their announcements:

Communities are the hidden control plane of the internet -- the signaling layer that lets tens of thousands of independently operated networks coordinate their routing policies without direct human communication. Understanding how they work is essential for anyone operating or troubleshooting internet routing.

See BGP routing data in real time

Open Looking Glass
More Articles
What is BGP? The Internet's Routing Protocol Explained
What is an Autonomous System (AS)?
What is a BGP Looking Glass?
How to Look Up an IP Address's BGP Route
Understanding BGP AS Paths
What is RPKI? Securing BGP Routing