Designing BGP Policy with Communities: A Practical Framework

Most networks use BGP communities the way most people use a junk drawer: things get put in, nobody agrees what they mean, and after two years nobody dares throw anything away. That is a shame, because a well-designed community scheme is the single highest-leverage thing you can build in a BGP network. It turns policy from a pile of per-neighbour route-maps into a signalling system that scales.

This article builds a real community framework end to end, implements it on Cisco IOS XE, and proves each behaviour with lab output - including a working remote-triggered black hole (RTBH) and one platform behaviour that will absolutely catch you out. For the fundamentals, see the complete BGP guide.

What a community actually is

A BGP community is a 32-bit tag attached to a route as an optional transitive attribute. That is the whole specification. BGP itself assigns no meaning to any value (with four well-known exceptions). The meaning is a convention that you and your peers agree on.

The universal convention is to write them as ASN:value. AS 65001's community 101 is written 65001:101. The first half identifies who defined the meaning; the second half is theirs to allocate.

The well-known ones, which every implementation honours without configuration:

Everything else is yours to define.

First, turn on new-format

Before anything else, on every router in the design:

ip bgp-community new-format

Without it, IOS displays communities as raw 32-bit integers - Community: 6554600 4259905637 - and show ip bgp community 65001:666 is rejected as invalid input. It is enabled by default on most modern images but not all, and it costs nothing to be explicit. It is a display and parsing setting only; the wire format never changes.

Designing the scheme

A community scheme is an addressing plan for policy. Like an addressing plan, the value is in the structure, not the individual numbers. Allocate ranges by purpose, and leave gaps.

Here is the scheme used in the lab, which is a realistic small-enterprise pattern:

Three rules make a scheme survive contact with reality:

1. One community, one meaning. Never overload a value. If you need to express two things, use two communities - they are cheap and a route can carry many.
2. Set at the edge, act at the edge. Origin communities are set where the route enters BGP. Scope communities are consumed where the route leaves your AS. The middle of your network should be a dumb pipe that preserves them.
3. Document it in one place, and version it. A community scheme with no document is a scheme that will be reverse-engineered from route-maps by a stranger at 3 a.m.

Implementation: tagging on origination

R1 is the AS 65001 edge toward ISP-A. It originates 10.10.10.0/24 (a normal site prefix) and 10.10.10.66/32 (a host under attack that we want black-holed). Both get tagged on the way out:

ip prefix-list SITE-A seq 5 permit 10.10.10.0/24
ip prefix-list SITE-A seq 10 permit 1.1.1.1/32
ip prefix-list BLACKHOLE-PFX seq 5 permit 10.10.10.66/32

route-map ISPA-OUT permit 10
 match ip address prefix-list BLACKHOLE-PFX
 set community 65001:101 65001:666
route-map ISPA-OUT permit 20
 match ip address prefix-list SITE-A
 set community 65001:101 65001:210
route-map ISPA-OUT permit 30

router bgp 65001
 address-family ipv4
  neighbor 10.0.13.2 send-community both
  neighbor 10.0.13.2 route-map ISPA-OUT out

Two details that are easy to get wrong:

• send-community is not on by default. Without it, IOS strips communities on egress and your entire scheme silently evaporates. both sends standard and extended communities.
• The empty permit 30 at the end is load-bearing. A route-map has an implicit deny. Without a bare permit clause, every prefix that does not match sequences 10 or 20 is dropped. This one line is responsible for a substantial fraction of all BGP outages.

Implementation: acting on communities

ISP-A (R3) is where the policy is enforced. It matches the blackhole community, rewrites the next-hop to a discard address, drops the local preference, and adds no-export so the black-holed route never leaves AS 100:

ip route 192.0.2.1 255.255.255.255 Null0
interface Loopback254
 description RTBH discard next-hop lives here
 ip address 192.0.2.254 255.255.255.0

ip community-list standard CUST-BLACKHOLE permit 65001:666

route-map CUST-IN permit 10
 match community CUST-BLACKHOLE
 set ip next-hop 192.0.2.1
 set local-preference 50
 set community no-export additive
route-map CUST-IN permit 20
 set community 100:1000 additive

router bgp 100
 address-family ipv4
  neighbor 10.0.13.1 route-map CUST-IN in

additive is the keyword to memorise. Without it, set community replaces every community on the route. With it, the new value is appended and the customer's origin tag survives. Getting this wrong destroys other people's policy silently.

The RTBH, working

R3#show ip bgp 10.10.10.66/32
BGP routing table entry for 10.10.10.66/32
Paths: (2 available, best #2, table default, not advertised to EBGP peer)
  65001
    192.0.2.1 from 10.0.13.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 50, valid, external, best
      Community: 65001:101 65001:666 no-export

R3#show ip cef 10.10.10.66 255.255.255.255
10.10.10.66/32
  nexthop 192.0.2.1 Null0

Read that carefully, because there is a lot in it:

• The customer's origin tag 65001:101 survived (that is additive doing its job).
• no-export is present, and IOS explicitly says not advertised to EBGP peer. The black hole stays inside AS 100.
• CEF resolves the prefix to Null0. Traffic destined for the victim is dropped at the provider edge, which is exactly the point - the attack traffic never reaches the customer's circuit.

The platform trap: a Null0 static is not enough

The textbook RTBH recipe is "set the next-hop to a discard address and add ip route 192.0.2.1 255.255.255.255 Null0". On IOS XE 17.18 that does not work on its own. Verified both ways in the lab:

! With ONLY the Null0 static, no connected route covering 192.0.2.0/24:
R3#show ip bgp 10.10.10.66/32
Paths: (2 available, no best path)
    192.0.2.1 (inaccessible) from 10.0.113.1 (1.1.1.1)
    192.0.2.1 (inaccessible) from 10.0.13.1 (1.1.1.1)

R3#show ip cef 10.10.10.66 255.255.255.255
%Prefix not found

BGP's next-hop validation refuses to accept a next-hop whose only resolution is a Null0 static. The path is valid but the next-hop is (inaccessible), so it never becomes best and never reaches the RIB. Your black hole does nothing.

The fix is to give the discard address a connected route to live in. A loopback carrying 192.0.2.254/24 makes 192.0.2.0/24 a connected network, which satisfies next-hop validation - while the more specific /32 Null0 static still wins in CEF and does the actual dropping:

interface Loopback254
 ip address 192.0.2.254 255.255.255.0
ip route 192.0.2.1 255.255.255.255 Null0

We removed the loopback and re-tested to confirm the causality, and the route went straight back to (inaccessible). This is not a lab artefact. If your RTBH silently does nothing, check show ip cef before you check anything else.

Implementation: the inbound side

ISP-A tags what it sends you, and you act on it. Its own routes get preferential treatment; the transit routes it learned from someone else do not:

ip community-list standard ISPA-OWN permit 100:110

route-map ISPA-IN permit 10
 match community ISPA-OWN
 set local-preference 200
route-map ISPA-IN permit 20

And the result, which is the whole scheme working in miniature:

R1#show ip bgp 100.100.100.0/24
  100
    10.0.13.2 from 10.0.13.2 (3.3.3.3)
      Origin IGP, metric 0, localpref 200, valid, external, multipath, best
      Community: 100:110

R1#show ip bgp 6.6.60.0/24 | include Community|localpref
      Origin IGP, localpref 100, valid, external, multipath, best
      Community: 100:120

ISP-A's own network gets local-pref 200. Everything it merely transits stays at 100. Not one prefix was named in a route-map. Add a thousand more prefixes tomorrow and the policy still holds, because the policy is expressed in tags, not addresses. That is the payoff.

Standard, extended, and large communities

If you have a 4-byte AS number, standard communities cannot encode it and you should be designing with large communities from day one. IOS XE supports them, and the CLI mirrors the standard-community commands (set large-community, ip large-community-list, send-community both covers them).

Troubleshooting checklist

1. Communities not arriving? send-community is missing on the sender. This is the number one cause, every time.
2. Communities arriving but the previous tags are gone? Somebody used set community without additive.
3. show ip bgp community 65001:666 rejected? ip bgp-community new-format is not on.
4. Route-map matching nothing? Community-lists are matched as a set, and a standard community-list with multiple values on one line requires all of them to be present. Use separate permit lines for OR logic.
5. Random prefixes disappearing after you added a route-map? The implicit deny at the end. Add a bare permit clause.
6. RTBH tagged correctly but traffic still flowing? Check show ip cef <prefix>. If the BGP entry says (inaccessible), your discard next-hop needs a connected route (see above).

Key takeaways

• Communities carry no built-in meaning. They are a signalling convention, and their value comes entirely from having a structure and sticking to it.
• Allocate ranges by purpose - origin, scope, action - and leave gaps. Document it once, and treat that document as the contract.
• Set tags at origination, act on them at the edge, and let the middle of your network preserve them untouched.
• send-community both on every neighbour, and additive on every set community that is not deliberately replacing the whole set.
• The empty permit at the end of an outbound route-map is not optional.
• RTBH is a community scheme's killer app: one tag, and your provider drops the attack traffic before it reaches your circuit. On IOS XE 17.x the discard next-hop needs a connected route to survive BGP next-hop validation.
• 4-byte ASN? Use large communities (RFC 8092), not standard.

Next: BGP multipath and load sharing, and a next-hop behaviour that hides a classic misconfiguration completely. The full cluster index lives on the BGP pillar guide.