BGP Communities Explained: Standard, Large, and Extended

What are BGP communities?

BGP communities are 32-bit tags attached to route announcements. They carry signaling information between ASes without changing the route itself. A community says "treat this prefix differently" -- lower its preference, prepend the path, drop it entirely, or announce it only to specific peers. Communities are transitive: they propagate across BGP sessions unless explicitly stripped. Three types exist: standard (RFC 1997), extended (RFC 4360), and large (RFC 8092).

Communities solve a coordination problem. Without them, every routing policy decision requires bilateral configuration on both sides of a session. With communities, your upstream or IX route server reads your tags and applies the policy you requested. You tag once, the network acts.

If you need BGP session setup first, see BIRD2 BGP Configuration on Linux or FRR BGP Configuration on Linux.

What are the three types of BGP communities?

They differ in size, encoding, and the problems they solve. Standard communities handle most use cases but break with 4-byte ASNs. Large communities fix that limitation. Extended communities serve specialized control-plane applications.

Property	Standard (RFC 1997)	Large (RFC 8092)	Extended (RFC 4360)
Size	32 bits	96 bits (3 x 32 bits)	64 bits
Format	ASN:value	ASN:value1:value2	type:subtype:value
ASN support	2-byte only	4-byte native	2-byte or 4-byte (depends on type)
BGP attribute	COMMUNITIES (8)	LARGE_COMMUNITIES (32)	EXTENDED COMMUNITIES (16)
Primary use	Upstream signaling, traffic engineering	Same as standard, 4-byte ASN-safe	MPLS VPN, EVPN, route targets
Adoption	Universal	Widespread since ~2018	Protocol-specific

Standard communities (RFC 1997)

Standard communities are 32-bit values written as two 16-bit integers separated by a colon: ASN:value. The high-order 16 bits identify the AS that defines the community's meaning. The low-order 16 bits carry the action or information.

Example: 174:70 means "Cogent: set local preference to 70". Only Cogent defines what value 70 means in the 174 namespace. Every provider publishes their own community definitions.

The 16-bit ASN field limits standard communities to 2-byte ASNs (0-65535). With over 120,000 ASNs allocated as of 2026, most new assignments are 4-byte numbers. Standard communities cannot represent them.

IANA reserves the range 65535:0 through 65535:65535 for well-known communities.

Large communities (RFC 8092)

Large communities use three 32-bit integers: Global Administrator : Local Data 1 : Local Data 2. The global administrator is the ASN of the network that defines the community. Both local data fields are operator-defined.

This format solves the 4-byte ASN problem. An AS with number 398465 can define 398465:100:0 as a valid large community. Standard communities cannot encode this.

The three-field structure also enables richer semantics. A common pattern is ASN:function:parameter -- for example, 35661:1010:174 could mean "prepend once at Frankfurt toward Cogent (AS174)".

Large community support is available in BIRD 1.6.3+, BIRD2, FRR 3.0+, OpenBGPD 6.1+, GoBGP, Cisco IOS-XR 6.2.1+, and Junos 17.3+. If your BGP daemon was released after 2018, it almost certainly supports them.

Extended communities (RFC 4360)

Extended communities are 64-bit values with a type field, subtype field, and value. Unlike standard and large communities, extended communities have structured semantics: the type and subtype define how the value should be interpreted.

You encounter extended communities primarily in:

• MPLS L3VPN: Route targets (rt 65000:100) and route distinguishers control VRF import/export
• EVPN: MAC mobility, ESI labels, and route types
• BGP Flowspec: Traffic rate limiting and redirect actions

For traffic engineering between ASes, standard and large communities are the right tools. Extended communities matter when you run overlay services. This article focuses on standard and large communities for the remaining sections.

What are well-known BGP communities?

IANA defines several well-known community values in the reserved 65535:* range. Every conforming BGP implementation must understand these.

Community	Value	Hex	Behavior	RFC
NO_EXPORT	65535:65281	0xFFFFFF01	Do not advertise outside the local AS confederation	1997
NO_ADVERTISE	65535:65282	0xFFFFFF02	Do not advertise to any BGP peer	1997
NO_EXPORT_SUBCONFED	65535:65283	0xFFFFFF03	Do not advertise outside the local AS	1997
NOPEER	65535:65284	0xFFFFFF04	Do not advertise to bilateral peers	3765
BLACKHOLE	65535:666	0xFFFF029A	Request blackhole of the tagged prefix	7999
GRACEFUL_SHUTDOWN	65535:0	0xFFFF0000	Signal planned session shutdown, set local-pref to 0	8326

NO_EXPORT is the most widely used. Tag a prefix with it and your peer will not re-advertise it beyond their AS boundary. This is how you control route leaks to third parties.

BLACKHOLE and GRACEFUL_SHUTDOWN are covered in detail in the traffic engineering sections below.

How do BGP communities enable traffic engineering?

Communities let you influence routing decisions in networks you do not control. You cannot log into your upstream's routers and change their config. But you can tag your announcements with communities they have agreed to honor. This is BGP traffic engineering via communities.

How does local preference signaling work with communities?

Most transit providers offer communities that set the local preference of your prefix within their network. A higher local preference means "prefer this path". A lower value means "use this only as a backup".

For example, a provider with AS 64500 might define:

Community	Effect
64500:100	Normal preference (default)
64500:90	Lower preference (backup path)
64500:150	Higher preference (preferred path)

By tagging your announcement with 64500:90 when sent to one upstream and leaving the default on another, you bias inbound traffic toward the upstream without the backup community. This works because local preference is evaluated before AS-path length in the BGP decision process.

Check your provider's community documentation. The values above are illustrative. Every provider defines their own scheme.

How does BGP prepending with communities work?

AS-path prepending artificially inflates the path length to make a route less preferred by remote networks. Instead of prepending on your own router (which affects all peers equally), communities let you request prepending selectively.

A typical provider scheme:

Community	Effect
64500:1001	Prepend 1x toward all peers
64500:1002	Prepend 2x toward all peers
64500:1003	Prepend 3x toward all peers

With large communities, the target can be more specific:

Large community	Effect
64500:1:174	Prepend 1x toward Cogent (AS174)
64500:2:174	Prepend 2x toward Cogent (AS174)
64500:3:0	Prepend 3x toward all peers

This granularity is why large communities are replacing standard communities for traffic engineering. The third field encodes the target ASN or peer group.

How does BGP blackholing work with the BLACKHOLE community?

Blackholing tells upstream networks to drop all traffic destined for a tagged prefix. It is a DDoS mitigation tool: when an IP is under attack, you announce it with the BLACKHOLE community and your upstreams null-route the traffic before it reaches your network.

RFC 7999 standardizes the well-known community 65535:666 for this purpose.

Requirements for blackholing to work:

1. Prefix specificity. Announce a /32 (IPv4) or /128 (IPv6) for the target IP. Never blackhole an entire /24.
2. Bilateral agreement. Your upstream must be configured to honor the BLACKHOLE community. This is not automatic. Verify with your provider.
3. NO_EXPORT tagging. Always add NO_EXPORT alongside BLACKHOLE to prevent the blackhole from propagating beyond your immediate upstream.
4. Monitoring. Blackholing drops all traffic, legitimate and malicious. Monitor and withdraw the announcement as soon as the attack stops.

Most IXP route servers also support blackholing via 65535:666. The route server sets the next-hop to a blackhole address and adds NO_EXPORT before redistribution.

How do you use communities for selective announcement?

Selective announcement lets you control which peers or IXPs see your prefix. This is the "do not announce to" or "announce only to" pattern.

Common implementations use a deny/allow model:

Community	Effect
64500:0:0	Do not announce to anyone (global deny)
64500:0:174	Do not announce to Cogent
64500:8:174	Announce only to Cogent (override deny)

With Virtua (AS35661), this uses the location-aware community scheme described in the reference table below.

How does graceful shutdown work with the GRACEFUL_SHUTDOWN community?

RFC 8326 defines the GRACEFUL_SHUTDOWN community (65535:0) for planned maintenance. When you need to take a BGP session down, tagging your routes with this community tells receiving routers to lower the local preference to 0 and start preferring alternate paths before you disconnect.

The sequence:

1. Add GRACEFUL_SHUTDOWN community to all routes sent to the peer being maintained
2. Wait for convergence (routes shift to alternate paths)
3. Shut down the BGP session
4. Perform maintenance
5. Bring the session back up
6. Remove the community

Without graceful shutdown, tearing down a session causes immediate route withdrawal. Traffic drops until BGP converges on the alternate path. With graceful shutdown, traffic shifts gradually before the session goes down.

This ties directly into multi-homing failover strategies.

How do I configure BGP communities in BIRD2?

BIRD2 uses typed community attributes on route objects. The three relevant attributes are:

Attribute	Type	Community type
bgp_community	clist (pair list)	Standard
bgp_large_community	lclist (triplet list)	Large
bgp_ext_community	eclist (extended list)	Extended

Adding communities in BIRD2

Use the .add() method in filter blocks:

filter export_to_upstream {
  # Add standard community
  bgp_community.add((65535, 666));

  # Add large community
  bgp_large_community.add((35661, 1010, 174));

  # Add multiple communities
  bgp_community.add((65535, 65281));  # NO_EXPORT

  accept;
}

Matching communities in BIRD2

Test membership with the ~ operator:

filter import_from_peer {
  # Match a specific standard community
  if (65535, 666) ~ bgp_community then {
    dest = RTD_BLACKHOLE;
    accept;
  }

  # Match a specific large community
  if (35661, 9999, 0) ~ bgp_large_community then {
    reject;
  }

  # Match with wildcards using sets
  # Any community in the 64500:* range
  if bgp_community ~ [(64500, *)] then {
    bgp_local_pref = 50;
  }

  accept;
}

The ~ operator returns true if the left operand is a member of the right operand. For set matching, use pair/triplet patterns with * as a wildcard.

Deleting communities in BIRD2

Strip communities on ingress to prevent unauthorized signaling:

filter scrub_inbound {
  # Remove all communities in our ASN namespace
  bgp_community.delete([(35661, *)]);
  bgp_large_community.delete([(35661, *, *)]);

  # Remove specific well-known community
  bgp_community.delete((65535, 666));

  accept;
}

Graceful shutdown receiver in BIRD2

function honor_graceful_shutdown() {
  if (65535, 0) ~ bgp_community then {
    bgp_local_pref = 0;
  }
}

filter ebgp_inbound {
  honor_graceful_shutdown();
  # ... other import filters
  accept;
}

Apply ebgp_inbound as the import filter on all EBGP sessions. When a peer sends the GRACEFUL_SHUTDOWN community, this sets local preference to 0, causing your router to prefer any alternate path.

Blackhole trigger in BIRD2

protocol static blackhole_triggers {
  ipv4 {
    table master4;
  };
  # Announce 203.0.113.5/32 with BLACKHOLE + NO_EXPORT
  route 203.0.113.5/32 blackhole;
}

filter export_blackhole {
  if dest = RTD_BLACKHOLE then {
    bgp_community.add((65535, 666));    # BLACKHOLE
    bgp_community.add((65535, 65281));  # NO_EXPORT
    # Accept only /32 for blackholes
    if net.len = 32 then accept;
  }
  reject;
}

How do I configure BGP communities in FRR?

FRR uses IOS-style community-list definitions and route-map actions. Communities are matched with match clauses and set with set clauses.

Defining community lists in FRR

! Standard community list - match specific community
bgp community-list standard BLACKHOLE permit 65535:666
bgp community-list standard GRACEFUL_SHUTDOWN permit 65535:0
bgp community-list standard NO_EXPORT permit no-export

! Large community list
bgp large-community-list standard PREPEND_1X permit 35661:1:0
bgp large-community-list standard NO_ANNOUNCE permit 35661:9:0

FRR supports both numbered (1-99 for standard, 100-500 for expanded) and named community lists. Named lists are easier to maintain.

Setting communities in FRR route-maps

route-map EXPORT-TO-UPSTREAM permit 10
 set community 65535:666 no-export additive
!
route-map EXPORT-TO-UPSTREAM permit 20
 set large-community 35661:1010:174 additive

The additive keyword appends communities instead of replacing the existing set. Without it, set community overwrites all existing communities.

Matching communities in FRR route-maps

route-map IMPORT-FROM-PEER permit 10
 match community BLACKHOLE
 set ip next-hop 192.0.2.1
!
route-map IMPORT-FROM-PEER permit 20
 match community GRACEFUL_SHUTDOWN
 set local-preference 0
!
route-map IMPORT-FROM-PEER permit 30
 ! Default: accept everything else

Stripping communities in FRR

route-map SCRUB-INBOUND permit 10
 set comm-list OUR_COMMUNITIES delete
 set large-comm-list OUR_LARGE_COMMUNITIES delete
!
bgp community-list expanded OUR_COMMUNITIES permit 35661:.*
bgp large-community-list expanded OUR_LARGE_COMMUNITIES permit 35661:.*:.*

This removes any communities in your ASN namespace that a peer might inject. Apply this route-map as neighbor <peer> route-map SCRUB-INBOUND in.

Graceful shutdown in FRR

FRR provides a built-in command:

router bgp 35661
 bgp graceful-shutdown

This automatically adds the GRACEFUL_SHUTDOWN community (65535:0) to all routes sent to all EBGP peers. Use it before planned maintenance.

On the receiving side, apply a route-map that matches the community and lowers local preference:

route-map HONOR-GSHUT permit 10
 match community GRACEFUL_SHUTDOWN
 set local-preference 0
!
route-map HONOR-GSHUT permit 20
 ! Accept everything else at normal preference

BIRD2 vs FRR community configuration comparison

Operation	BIRD2	FRR
Add standard community	bgp_community.add((ASN, val))	set community ASN:val additive
Add large community	bgp_large_community.add((ASN, v1, v2))	set large-community ASN:v1:v2 additive
Match standard community	if (ASN, val) ~ bgp_community	match community LIST_NAME
Match large community	if (ASN, v1, v2) ~ bgp_large_community	match large-community LIST_NAME
Delete by pattern	bgp_community.delete([(ASN, *)])	set comm-list LIST_NAME delete
Wildcard match	[(ASN, *)] in set expression	Expanded community-list with regex
Apply filter	import filter name; in protocol	neighbor X route-map NAME in

BIRD2 handles community operations inline within filter functions. FRR separates the definition (community-list) from the action (route-map). Both approaches work. BIRD2's inline syntax is more concise for complex logic with conditionals. FRR's split model is more readable for simple match-and-set policies.

What are Virtua's BGP community values?

Virtua (AS35661) supports both standard and large BGP communities. Large communities follow the format 35661:ACTION_LOCATION:TARGET. The community scheme is location-aware, letting you control announcements per POP, per peer type, or per specific peer ASN.

Location codes

Code	City	Country	POP ID
000	Paris	France	PAR01FR
001	Lille	France	LIL01FR
010	Frankfurt	Germany	FRA01DE
020	Amsterdam	Netherlands	AMS01NL
999	All locations	--	ALL

Action communities

Action	Large community format	Effect
Route origin	35661:0[LOC]:TARGET	Informational: identifies where the route was learned
Prepend 1x	35661:1[LOC]:TARGET	Prepend AS35661 once toward target
Prepend 2x	35661:2[LOC]:TARGET	Prepend AS35661 twice toward target
Prepend 3x	35661:3[LOC]:TARGET	Prepend AS35661 three times toward target
Export only	35661:8[LOC]:TARGET	Override deny: announce only to target
No export	35661:9[LOC]:TARGET	Do not announce to target

Target selectors

Target value	Meaning
0	All peers at the specified location
1	Transit peers only
2	IX peers only
Specific ASN	A single peer (e.g., 174 for Cogent)

Precedence rules

When multiple communities conflict, Virtua evaluates them in this order (highest priority first):

1. 35661:8[LOC]:ASN -- explicit allow for a specific peer
2. 35661:9[LOC]:ASN -- deny for a specific peer
3. 35661:9[LOC]:1 or 35661:9[LOC]:2 -- deny for peer group (transit or IX)
4. 35661:9[LOC]:0 -- deny for all peers at a location
5. 35661:9999:0 -- global deny (do not announce anywhere)

Examples with Virtua communities

Announce everywhere except Cogent at Frankfurt:

# BIRD2
bgp_large_community.add((35661, 9010, 174));

! FRR
route-map EXPORT permit 10
 set large-community 35661:9010:174 additive

Announce only to IX peers at all locations:

# BIRD2
bgp_large_community.add((35661, 9999, 1));  # deny all transit

! FRR
route-map EXPORT permit 10
 set large-community 35661:9999:1 additive

Prepend 2x toward all peers at Paris:

# BIRD2
bgp_large_community.add((35661, 2000, 0));

! FRR
route-map EXPORT permit 10
 set large-community 35661:2000:0 additive

For more on BGP setup with Virtua, see BGP Bring Your Own IP on a VPS.

How do I verify BGP communities on a route?

Verify in BIRD2

birdc show route for 203.0.113.0/24 all

Look for the BGP.community and BGP.large_community attributes in the output:

203.0.113.0/24   unicast [upstream1 2026-03-19] * (100) [AS64500i]
    via 198.51.100.1 on eth0
    Type: BGP univ
    BGP.community: (65535,666) (65535,65281)
    BGP.large_community: (35661,0010,174)
    BGP.as_path: 64500

Verify in FRR

vtysh -c "show ip bgp 203.0.113.0/24"

The output includes a Community: line:

BGP routing table entry for 203.0.113.0/24
  65535:666 no-export
  Large Community: 35661:0010:174

Verify with external tools

You cannot see communities from inside your network alone. Use external looking glasses to verify what the rest of the internet sees:

• bgp.tools: Search your prefix and check the "Communities" tab. Shows communities as seen by multiple collectors worldwide.
• RIPE Stat: The "BGP Looking Glass" widget shows community attributes from RIPE RIS collectors.
• NLNOG Looking Glass: Query from NLNOG RING nodes across multiple ASes.

Always verify from outside. A community might be set correctly on your router but stripped by an intermediate network.

How should I handle community security?

Communities are transitive by default. Any network in the path can read them, add to them, or strip them. This creates security risks if you do not filter properly.

Strip inbound communities in your ASN namespace

If a peer sends you a route tagged with your own communities (e.g., 35661:9999:0), and you do not strip it, your own export filters might honor it. This could cause you to stop announcing the prefix entirely.

Always scrub your own community namespace on import:

# BIRD2 - apply on every EBGP import filter
bgp_community.delete([(35661, *)]);
bgp_large_community.delete([(35661, *, *)]);

! FRR - apply as inbound route-map on every EBGP neighbor
bgp community-list expanded OUR_COMMS permit 35661:.*
bgp large-community-list expanded OUR_LARGE_COMMS permit 35661:.*:.*

route-map SCRUB-IN permit 10
 set comm-list OUR_COMMS delete
 set large-comm-list OUR_LARGE_COMMS delete

Validate blackhole requests

Never blindly honor 65535:666 from any peer. A malicious or misconfigured peer could blackhole your customer prefixes.

Rules for blackhole acceptance:

• Only accept blackhole-tagged routes for prefixes the peer is authorized to originate
• Verify RPKI/ROA validity before honoring the blackhole (see RPKI ROA Setup for BGP)
• Limit accepted prefix length to /32 (IPv4) and /128 (IPv6) for blackholes
• Always add NO_EXPORT to blackhole routes before redistribution

# BIRD2 - safe blackhole acceptance
filter import_with_blackhole {
  if (65535, 666) ~ bgp_community then {
    # Only accept /32 for blackhole
    if net.len != 32 then reject;
    dest = RTD_BLACKHOLE;
    bgp_community.add((65535, 65281));  # NO_EXPORT
    accept;
  }
  # ... normal import policy
  accept;
}

Strip communities on export when appropriate

Before announcing routes to peers, remove communities they should not see or act on:

# BIRD2 - clean export to IX route server
filter export_to_ix {
  # Keep well-known communities, remove internal ones
  bgp_community.delete([(35661, *)]);
  bgp_large_community.delete([(35661, 0, *)]);  # Remove informational
  # Keep action communities the IX needs to see
  accept;
}

Community security is part of a broader route filtering strategy. See BGP Route Filtering and Security for the full picture.

Something went wrong?

Communities not appearing on remote looking glasses. Your upstream might strip them. Check if the community is in a namespace they honor. Some providers strip all third-party communities by default.

Blackhole not working. Verify prefix length (/32 or /128 required). Confirm your upstream supports RFC 7999. Check if NO_EXPORT is being added -- without it, the blackhole may propagate further than intended and get stripped.

Large communities not propagating. Older BGP implementations silently drop unknown attributes. If an intermediate AS runs software that predates RFC 8092 support, large communities will be lost. Check the AS path and identify the network dropping them.

BIRD2 filter syntax errors. Community pairs use parentheses, not colons: (35661, 100) not 35661:100. Large communities are triplets: (35661, 100, 200). The colon notation is for display and CLI only.

FRR community-list not matching. Named community lists must be referenced exactly as defined. Check for typos. Use show bgp community-list to verify the list contents.

Communities overwritten instead of appended in FRR. Missing the additive keyword in set community or set large-community replaces all existing communities. Always use additive unless you intentionally want to overwrite.

Check logs for BGP session issues:

# BIRD2
journalctl -u bird -f

# FRR
journalctl -u frr -f

---

Copyright 2026 Virtua.Cloud. All rights reserved. This content is original work by the Virtua.Cloud team. Reproduction, republication, or redistribution without written permission is prohibited.