BGP Communities: Signaling Between Networks

What Are BGP Communities?

A BGP community is a 32-bit tag attached to a route that carries metadata about how the route should be treated. Think of it as a label that says "handle this route according to policy X."

Communities enable networks to communicate routing intent without direct coordination. An upstream ISP can publish a set of community values, and customers tag their routes accordingly.

Community Format

Standard communities are written as ASN:value (two 16-bit integers):

65000:100    -- ASN 65000, value 100
174:70       -- Cogent, action community

Well-Known Communities

RFC 1997 defines several well-known communities that all BGP implementations should recognize:

ISP Action Communities

Large transit providers publish community guides that let customers control routing. Common patterns:

# Example: Transit provider AS 174 (Cogent)
174:70    -- Set local preference to 70 (lower = less preferred)
174:120   -- Set local preference to 120
174:990   -- Prepend 1x when advertising to peers
174:991   -- Prepend 2x when advertising to peers
174:992   -- Prepend 3x when advertising to peers

By tagging your announcement with 174:70, you tell Cogent to deprioritize that route compared to routes from your other transit providers.

Practical Example: Traffic Engineering

You have two transit providers (AS 174 and AS 3356) and want inbound traffic to prefer AS 174:

# On AS 3356 session: prepend your AS to make path longer
route-map TO-LUMEN permit 10
  set as-path prepend 65000 65000
  set community 3356:90   # Lower local-pref at Lumen

# On AS 174 session: no prepending, high preference
route-map TO-COGENT permit 10
  set community 174:120   # Higher local-pref at Cogent

Informational Communities

Use communities to tag routes by origin for internal policy:

65000:1000  -- Learned from transit provider A
65000:2000  -- Learned from transit provider B
65000:3000  -- Learned from IXP peers
65000:4000  -- Learned from private peers
65000:5000  -- Customer routes

Your internal routers can then apply policy based on these tags:

# Prefer customer routes over transit
route-map IMPORT-POLICY permit 10
  match community CUSTOMER-ROUTES
  set local-preference 200
route-map IMPORT-POLICY permit 20
  match community PEER-ROUTES
  set local-preference 150
route-map IMPORT-POLICY permit 30
  match community TRANSIT-ROUTES
  set local-preference 100

Community Best Practices

• Document your community scheme -- Publish it in your PeeringDB page and IRR remarks.
• Strip inbound communities -- Remove customer-set communities that could manipulate your policy.
• Use informational communities liberally -- They cost nothing and make troubleshooting easier.
• Check upstream community guides -- Most tier-1 providers publish detailed community documentation.