Understanding BGP Communities for Traffic Engineering

Border Gateway Protocol (BGP) is the routing protocol that underpins the global internet, enabling autonomous systems (ASes) to exchange reachability information. While most network engineers understand BGP at the route-advertisement level, BGP communities remain a frequently misunderstood mechanism — yet they are among the most powerful levers available for traffic engineering in multi-homed and carrier environments.

What Are BGP Communities?

A BGP community is an optional transitive path attribute (type code 8, defined in RFC 1997) that can be attached to route prefixes. Communities are 32-bit values typically expressed in the format AS:value (e.g., 65000:100). Routers and route policies can match on these tags to make forwarding and preference decisions, without needing to inspect the prefix itself.

Communities travel with the route advertisement and are preserved across AS boundaries — unless a network explicitly strips them. This makes them ideal for signalling intent across peering relationships: 'treat this prefix as a low-preference backup path', or 'do not advertise this prefix to peers in region X'.

Standard vs. Extended vs. Large Communities

Standard Communities (RFC 1997)

Standard communities are 32 bits, split into two 16-bit fields: the high 16 bits represent the originating ASN, and the low 16 bits carry the local value. This is sufficient for networks with 2-byte ASNs (< 65536). Well-known communities such as NO_EXPORT (0xFFFFFF65) and NO_ADVERTISE (0xFFFFFF66) have standardised semantics:

• NO_EXPORT — do not advertise to any EBGP peer (stays within the AS confederation)
• NO_ADVERTISE — do not advertise to any peer at all
• NOPEER / NO_PEER (RFC 3765) — do not advertise to bilateral peers

Extended Communities (RFC 4360)

Extended communities extend the attribute to 64 bits, providing both a type field and a larger value space. They are widely used in MPLS VPN environments (the Route Target and Route Distinguisher attributes are extended communities), as well as for QoS marking and traffic colouring in carrier networks. The type byte allows for distinct namespaces, preventing value collisions between vendors and use-cases.

Large Communities (RFC 8092)

Introduced to address the limitation that standard communities cannot encode 4-byte ASNs in the high field, large communities use a 96-bit structure: Global Administrator (4 bytes, the ASN), Local Data Part 1 (4 bytes), and Local Data Part 2 (4 bytes). They are expressed as AS:LD1:LD2, e.g., 201683:100:10. Networks with 4-byte ASNs — the vast majority of new assignments today — should prefer large communities for any custom traffic engineering signalling.

Practical Traffic Engineering with Communities

Consider a network (AS 64500) multi-homed to two upstream transit providers, Provider A (AS 1111) and Provider B (AS 2222). The network wants to use Provider A as the primary path for all prefixes, with Provider B as a cold-standby. Rather than adjusting MED or local-pref on the customer side alone, the operator can use communities to instruct the transit providers directly.

Example: Prepend Control via Communities

Provider A publishes a community scheme allowing customers to request AS-path prepending when advertising the customer's prefixes to Provider A's peers:

! Provider A community scheme (published in their PeeringDB / NOC docs)
! 1111:101 = prepend AS 1x to all Provider A peers
! 1111:102 = prepend AS 2x to all Provider A peers
! 1111:200 = do not advertise to Provider A's peers in Region EU

! On AS 64500's router (Cisco IOS-XR example):
route-policy SET-COMMUNITIES-TO-PROVIDER-A
  set community (1111:101) additive   ! request 1x prepend -> makes us less preferred
end-policy

neighbor 203.0.113.1
 address-family ipv4 unicast
  route-policy SET-COMMUNITIES-TO-PROVIDER-A out

This instructs Provider A to prepend AS 64500 once when re-advertising the prefix outbound, making the path appear longer and thus less preferred by Provider A's peers compared to the same prefix received via Provider B. The result: inbound traffic from Provider A's peer networks shifts toward Provider B — traffic engineering achieved without touching local-pref on the customer's own routers.

Example: Blackhole Community (RFC 7999)

RFC 7999 standardised community 65535:666 as the BLACKHOLE community. When a customer tags a /32 host route with this community and advertises it upstream, compliant transit providers will forward packets destined for that IP to a null interface — dropping DDoS traffic at the provider edge rather than forwarding it into the customer network. This is Remotely Triggered Black Hole (RTBH) filtering.

! RTBH example — blackhole 192.0.2.1/32 upstream
ip route 192.0.2.1 255.255.255.255 Null0

router bgp 64500
 network 192.0.2.1 mask 255.255.255.255 route-map SET-BLACKHOLE-COMMUNITY

route-map SET-BLACKHOLE-COMMUNITY permit 10
 set community 65535:666 no-export

Community Filtering Best Practices

• Strip all incoming communities from customers by default; only honour communities your NOC team explicitly documents and supports
• Apply inbound community filtering at EBGP boundaries to prevent customers from manipulating peer relationships
• Document your community scheme in PeeringDB and your NOC's public information — this significantly eases peering relationship management
• Use large communities (RFC 8092) for all new deployments; retain standard communities only for backward compatibility with older peers
• Test community-based policies in a staging environment or with a test prefix — a misconfigured policy can cause widespread route leaks

Summary

BGP communities are an elegant and scalable mechanism for distributed traffic engineering across provider boundaries. Standard communities serve well-known purposes like NO_EXPORT; extended communities power MPLS VPN constructs; large communities are the modern standard for custom 4-byte AS traffic engineering. A well-documented community scheme, consistently applied and filtered at AS edges, allows network operators to shape traffic flows, implement DDoS mitigation, and provide fine-grained customer controls — all without requiring out-of-band coordination for every policy change.