BGP Communities

BGP Communities

BGP communities are optional transitive attributes that attach policy metadata to routes. Routers along the path can read these tags to make forwarding decisions, change attributes, or suppress advertisement—without needing out-of-band coordination. RouterOS 7 supports all three community types: standard (RFC 1997), extended (RFC 4360), and large (RFC 8092).

For filter rule syntax fundamentals, see BGP Route Filtering and Communities. For session setup, see BGP Peering: eBGP and iBGP Configuration.

---

Community Types

Standard Communities (RFC 1997)

Standard communities are 32-bit values encoded as ASN:value, where each field is a 16-bit integer (0–65535). They are the most widely supported type across all BGP implementations.

65000:100     # ASN 65000, local policy value 100
64500:200     # peer ASN 64500 signals value 200
65535:65281   # IANA well-known NO_EXPORT

RouterOS filter property: bgp-communities

Extended Communities (RFC 4360)

Extended communities are 64-bit values that encode a type field alongside the administrator and value. The most common sub-types are Route Target (rt) and Site of Origin (soo), used in MPLS/VPN deployments.

rt:65000:100    # Route Target — import/export tag for VRFs
soo:65000:200   # Site of Origin — loop prevention for multi-homed sites

RouterOS filter property: bgp-ext-communities

Large Communities (RFC 8092)

Large communities are 96-bit values with three 32-bit fields: Global Administrator : Local Data Part 1 : Local Data Part 2. They were designed to support 4-byte ASNs that cannot fit in the 16-bit ASN field of standard communities.

65000:100:1     # Global AS 65000, function 100, parameter 1
4200000001:1:0  # 4-byte ASN, no-export signal

RouterOS filter property: bgp-large-communities

---

Enabling Community Advertisement

By default, RouterOS does not send community attributes to eBGP peers. Enable per-session in the BGP connection or template:

/routing bgp connection
set peer-name send-community=standard

Valid values for send-community:

Value	Effect
no	Do not send any communities (default for eBGP)
standard	Send standard communities only
extended	Send extended communities only
large	Send large communities only
all	Send all three types
yes	Equivalent to all

For iBGP, communities are forwarded by default. For eBGP, always configure send-community explicitly or tagged routes will arrive stripped at the peer.

---

Setting Communities in Routing Filters

Set (Replace)

Replaces the entire community attribute. Use when you want precise control over what is attached and need to remove any previously existing communities:

/routing filter rule
add chain=bgp-out rule="if (dst in 203.0.113.0/24) { set bgp-communities 65000:100; accept }"

To set multiple communities at once, separate with commas:

add chain=bgp-out rule="if (dst == 198.51.100.0/24) { set bgp-communities 65000:100,65000:200; accept }"

Append (Add Without Removing)

Adds communities to the existing attribute without removing current values. Use when building up tags incrementally across multiple rules:

# Tag customer routes with origin community, then add backup signal if needed
add chain=bgp-out-customer rule="if (protocol static) { append bgp-communities 65000:300; accept }"
add chain=bgp-out-customer rule="accept"

Set vs Append

Use set when the route must carry exactly the communities you specify—for example, when sending to an upstream that expects specific tags. Use append when augmenting tags through a chain of rules, or when communities may have been set by an earlier rule.

Extended and Large Community Syntax

# Set a route-target on outbound VPN routes
add chain=bgp-out-vpn rule="if (dst in 10.100.0.0/16) { set bgp-ext-communities rt:65000:100; accept }"

# Append a large community for a 4-byte ASN network
add chain=bgp-out rule="if (dst in 203.0.113.0/24) { append bgp-large-communities 4200000001:1:0; accept }"

---

Matching Communities in Routing Filters

Standard Community Operators

Operator	Matches when…
equal value	Route has exactly these communities (no more, no less)
includes value	Route has all of the listed communities
any value	Route has at least one of the listed communities
subset value	Route’s communities are a subset of the listed values

# Accept routes that include a specific tag, regardless of other communities
add chain=bgp-in rule="if (bgp-communities includes 64500:500) { set bgp-local-pref 250; accept }"

# Accept routes carrying any of several provider tags
add chain=bgp-in rule="if (bgp-communities any 64500:100,64500:200) { set bgp-local-pref 200; accept }"

# Accept only routes tagged with exactly this community (nothing else)
add chain=bgp-in rule="if (bgp-communities equal 65000:100) { accept }"

List-Based Matching

For filters that need to match against a named set of communities, define a community list:

/routing filter community-list
add list=upstream-te communities=64500:100,64500:200,64500:300

/routing filter rule
add chain=bgp-in rule="if (bgp-communities any-list upstream-te) { set bgp-local-pref 200; accept }"

Community lists are useful when the same set is referenced in multiple filter rules, or when you want to update the set without modifying every filter.

The list-based operators are any-list, includes-list, and subset-list—they behave identically to their inline counterparts but reference a named list.

Extended and Large Community Matching

# Match inbound routes with a specific route-target
add chain=bgp-in-vpn rule="if (bgp-ext-communities includes rt:65000:100) { accept }"

# Match routes tagged with a large community
add chain=bgp-in rule="if (bgp-large-communities includes 65000:1:10) { set bgp-local-pref 300; accept }"

Regexp Matching on Standard Communities

Standard communities can be matched with a regular expression against their string representation (ASN:value):

# Match any community from AS 65000
add chain=bgp-in rule="if (bgp-communities regexp \"65000:.*\") { accept }"

# Match communities where the value is between 100 and 199
add chain=bgp-in rule="if (bgp-communities regexp \"65000:1[0-9][0-9]\") { accept }"

---

Deleting Communities

Strip communities before advertising to prevent policy information from leaking to external networks.

Delete Specific Values

# Remove a specific community from the attribute
add chain=bgp-out rule="if (bgp-communities includes 65000:99) { delete bgp-communities 65000:99; accept }"

Delete All Communities Matching a Pattern

# Remove all communities from your own AS before sending to peers
add chain=bgp-sanitize-out rule="delete bgp-communities regexp \"65000:.*\"; accept"

Delete Well-Known Communities

The wk keyword removes all well-known standard communities from the attribute:

# Strip well-known communities (no-export, no-advertise, local-as) at exit
add chain=bgp-out-edge rule="delete bgp-communities wk; accept"

The other keyword removes all non-well-known communities:

# Strip internal policy tags, preserve RFC-mandated communities
add chain=bgp-out-edge rule="delete bgp-communities other; accept"

Delete Extended Communities

# Remove all route-target communities
add chain=bgp-out rule="delete bgp-ext-communities rt; accept"

# Remove a specific route-target
add chain=bgp-out rule="delete bgp-ext-communities rt:65000:100; accept"

---

Well-Known Communities

NO_EXPORT and NO_ADVERTISE

RFC 1997 defines well-known communities that all compliant BGP implementations must honor:

Community	Numeric Value	RouterOS Keyword	Effect
NO_EXPORT	65535:65281	no-export	Do not advertise to eBGP peers
NO_ADVERTISE	65535:65282	no-advertise	Do not advertise to any peer (iBGP or eBGP)
NO_EXPORT_SUBCONFED	65535:65283	local-as	Do not export to sub-confederation eBGP peers

Tagging routes with NO_EXPORT

Attach NO_EXPORT to a more-specific prefix so it is used for internal traffic engineering but never leaked to the global table:

/routing filter rule
# Announce a /25 internally via iBGP but block it from leaving the AS
add chain=bgp-out-ibgp rule="if (dst == 198.51.100.128/25) { append bgp-communities no-export; accept }"

# To external peers: advertise only the aggregate /24
add chain=bgp-out-ebgp rule="if (dst == 198.51.100.0/24) { accept }"
add chain=bgp-out-ebgp rule="reject"

Honoring NO_ADVERTISE from a peer

A route carrying NO_ADVERTISE must not be forwarded. Enforce this on inbound filters to be safe (though RouterOS honors it by default for well-known communities):

add chain=bgp-in rule="if (bgp-communities includes no-advertise) { reject }"

Blackhole Community (RFC 7999)

The IANA blackhole community 65535:666 signals upstream providers to null-route a destination. Use it to request remote-triggered blackholing (RTBH) during a DDoS attack:

/routing filter rule
# Advertise a /32 with blackhole community to upstream for DDoS mitigation
add chain=bgp-out-blackhole rule="if (dst-len == 32 && dst in 198.51.100.0/24) { \
    set bgp-communities 65535:666; accept }"
add chain=bgp-out-blackhole rule="reject"

/routing bgp connection
set to-isp output.filter-chain=bgp-out-blackhole

Many providers require their own community in addition to or instead of 65535:666. Check your provider’s peering policy or NOC documentation for their specific values.

---

Practical Policy Examples

Upstream Traffic Engineering via Provider Communities

Most transit providers publish communities that allow customers to influence route advertisement and AS-path prepending upstream. Apply them outbound toward that provider:

# Example: provider AS 64500 uses 64500:3001 to prepend x1 toward its peers
/routing filter rule
add chain=bgp-out-transit rule="if (dst == 198.51.100.0/24) { \
    append bgp-communities 64500:3001; accept }"
add chain=bgp-out-transit rule="accept"

/routing bgp connection
set to-transit output.filter-chain=bgp-out-transit

Community values and their meanings are provider-specific. Always obtain them from your upstream’s looking glass or NOC documentation.

Selective Advertisement to Specific Peers

Tag routes internally, then use community matching to decide where to advertise:

# On inbound from customers: mark with origin community
/routing filter rule
add chain=bgp-in-customer rule="if (dst-len <= 24) { \
    set bgp-communities 65000:200; set bgp-local-pref 200; accept }"
add chain=bgp-in-customer rule="reject"

# To IX peers: only send routes tagged as customer-originated
add chain=bgp-out-ix rule="if (bgp-communities includes 65000:200) { \
    delete bgp-communities other; accept }"
add chain=bgp-out-ix rule="reject"

# To transit: send everything, strip internal tags
add chain=bgp-out-transit rule="delete bgp-communities other; accept"

Community-Based Local Preference Assignment

ISPs often color routes by type (customer / peer / transit) using communities. Apply consistent local-pref based on community on inbound iBGP:

/routing filter rule
# Customer-learned routes: highest preference
add chain=bgp-in-ibgp rule="if (bgp-communities includes 65000:200) { \
    set bgp-local-pref 300; accept }"

# Peer-learned routes: medium preference
add chain=bgp-in-ibgp rule="if (bgp-communities includes 65000:150) { \
    set bgp-local-pref 200; accept }"

# Transit-learned routes: lowest preference
add chain=bgp-in-ibgp rule="if (bgp-communities includes 65000:100) { \
    set bgp-local-pref 100; accept }"

add chain=bgp-in-ibgp rule="accept"

Sanitizing Communities at AS Boundaries

Strip internal policy communities before advertising to any external neighbor to prevent information leakage:

/routing filter rule
# Remove all private policy communities (65000:*) and preserve well-known
add chain=bgp-sanitize-ebgp rule="delete bgp-communities regexp \"65000:.*\"; accept"

/routing bgp connection
set to-customer output.filter-chain=bgp-sanitize-ebgp
set to-peer output.filter-chain=bgp-sanitize-ebgp
set to-transit output.filter-chain=bgp-sanitize-ebgp

Large Community Policy for 4-Byte ASN Networks

Networks with 4-byte ASNs use large communities because the 16-bit ASN field in standard communities cannot represent them:

/routing filter rule
# Tag routes by region for selective advertisement
add chain=bgp-in-customer rule="if (dst in 203.0.113.0/24) { \
    append bgp-large-communities 4200000001:1:10; accept }"

# Advertise to peers in region 10 only
add chain=bgp-out-peer rule="if (bgp-large-communities includes 4200000001:1:10) { accept }"
add chain=bgp-out-peer rule="reject"

/routing bgp connection
set to-peer output.filter-chain=bgp-out-peer
send-community=large

---

Troubleshooting

Verify Communities on Received Routes

/routing route print detail where bgp

Look for the bgp-communities, bgp-ext-communities, and bgp-large-communities fields in the route detail output.

Verify Communities Not Being Stripped

If communities are missing after sending to a peer, check send-community on the BGP connection:

/routing bgp connection print detail where name=peer-name

Ensure the relevant community type is included (or use send-community=all).

Test Community Matching Without Applying

Use a test chain attached temporarily to a connection and inspect the session counters to confirm how many routes match:

/routing bgp connection set peer-name input.filter-chain=test-community-chain
/routing bgp session print detail where name=peer-name
# Check input-prefixes count

Remove when done:

/routing bgp connection set peer-name input.filter-chain=bgp-in

---

See Also

• BGP Route Filtering and Communities — Filter rule syntax, prefix filtering, MED, local-pref, AS-path filtering
• BGP Peering: eBGP and iBGP Configuration — Session setup, iBGP full-mesh and route reflectors
• Route Selection and Filters — Complete filter language reference