BGP Communities Explained: Standard, Extended and Large

2026年10月4日 LOG admin

BGP communities are the mechanism that lets one autonomous system tell another what to do with a route without inventing a new protocol for every request. They are 32-bit tags in the basic form, 64-bit in extended form, and 96-bit in large form, and the difference between those three is not academic — it decides whether you can encode an AS number and a 32-bit value together, and whether the community can carry a full 4-byte ASN. This guide covers what each type is for, how they are matched and set, and the well-known values worth memorising.

Three Types, Three Use Cases

Type	Size	Format	Typical use
Standard	32-bit	`ASN:value` (16-bit pairs) or a well-known name	Route tagging, no-export, customer vs peer vs transit
Extended	64-bit	Type + value, e.g. route target `ASN:nn`	MPLS L3VPN route targets, flow spec, bandwidth
Large	96-bit	`ASN:value1:value2`	Anything needing a 32-bit ASN plus two 32-bit values

The 32-bit limitation of standard communities is why 4-byte ASNs use the asdot representation and why some operators still cannot express their own ASN in a standard community. Large communities were standardised precisely to fix that.

Well-Known Standard Communities

NO_EXPORT              (0xFFFFFF01)  do not advertise outside the AS
NO_ADVERTISE           (0xFFFFFF02)  do not advertise to any peer
NO_EXPORT_SUBCONFED    (0xFFFFFF03)  do not advertise outside the confederation
BLACKHOLE              (0xFFFF029A)  discard traffic to this prefix
NO_PEER                (RFC 3765)    do not advertise to peers

BLACKHOLE is the one that earns its keep in production: a customer under DDoS announces their /32 with the blackhole community and the upstream drops the traffic at the edge, preserving the rest of the customer's address space.

The Common Operational Language

65000:100   customer route
65000:200   peer route
65000:300   transit route
65000:911   blackhole this prefix
65000:1001  prepend once toward AS 64500
65000:1002  prepend twice toward AS 64500
65000:0     do not advertise to anyone

This numbering is a convention, not a standard. Its value is that it is documented and consistent: every neighbour policy matches on the same tags, and adding a new behaviour means allocating a new number rather than editing twenty filters.

Setting Communities on Junos

policy-options {
    community CUST-ROUTES members [ 65000:100 65000:1000 ];
    community BLACKHOLE members 65000:911;
    policy-statement TAG-IN {
        term customer {
            from protocol bgp;
            then {
                community add CUST-ROUTES;
                local-preference 200;
                accept;
            }
        }
    }
    policy-statement BLACKHOLE-ACTION {
        term bh {
            from community BLACKHOLE;
            then {
                next-hop discard;
                accept;
            }
        }
    }
}

Setting Communities on Cisco IOS/IOS-XE

ip community-list standard CUST permit 65000:100
ip community-list standard BH permit 65000:911
!
route-map SET-CUST permit 10
 match ip address prefix-list PL-CUST
 set community 65000:100 65000:1000 additive
 set local-preference 200
!
route-map FROM-CUST in
 set community 65000:100 additive
!
router bgp 65000
 neighbor 10.0.0.1 route-map FROM-CUST in

The additive keyword is the most commonly forgotten token in this whole topic. Without it, set community replaces every community already on the route, silently destroying upstream tags and breaking blackhole and traffic-engineering policies end to end.

Matching Extended and Large Communities

# Cisco IOS-XE: extended community list for a route target
ip extcommunity-list standard RT-100 permit rt 65000:100
# And in a route-map
route-map RT-FILTER permit 10
 match extcommunity RT-100

# Junos: large community
policy-options community LC-TE members 65000:1:100

Extended communities are matched by type — route target, route origin, bandwidth, link bandwidth — not just by number, so a list that permits rt 65000:100 will not match a bandwidth extended community with the same numeric value. This is a feature: it stops one policy from accidentally matching another's semantics.

Verification

show ip bgp 192.0.2.0/24
show ip bgp community 65000:911
show ip bgp community-list CUST
show bgp neighbor 10.0.0.1 advertised-routes
show route 192.0.2.0/24 detail   # Junos: shows communities per path

Always verify in both directions — communities you send and communities you receive. The classic escalation is “we tagged it, you did not act on it” resolved by discovering the upstream's inbound policy stripped all communities because a single clause was added without additive.

Design Rules

Document your community plan in a file that ships with the configuration. Undocumented communities are worse than none.
Allocate per-behaviour, not per-policy: one number for “blackhole”, one for “prepend to AS x”.
Use large communities for anything involving a 4-byte ASN, and stop abusing asdot notation in standard communities.
Always use additive unless you specifically intend to wipe the existing set, and write a test that proves it.