An unfiltered BGP session is a loaded weapon. Accept everything and a peer's mistake becomes your outage (or you become a transit provider by accident); advertise everything and you can announce someone else's address space to the world — route leaks that make the news are exactly this. Policy control is therefore not an advanced topic in BGP; it is table stakes, and it hangs off three tools applied per neighbour, per direction.
The three filters
- Prefix lists — match on the prefix and mask length: ip prefix-list CUST permit 10.20.0.0/16 le 24 matches 10.20.0.0/16 and everything inside it down to /24. The ge/le operators make them the precise, readable default for route filtering.
- AS-path access lists — regex over the AS-path: ^$ matches locally originated routes only (the classic 'never be transit' outbound filter), ^65002_ matches routes learned directly from AS 65002, _64500$ matches routes originated by 64500.
- Route maps — the policy engine that ties it together: ordered permit/deny sequences that match on prefix lists, AS-path lists or communities, and set attributes — local preference, MED, communities, next hop. Applied with neighbor x.x.x.x route-map NAME in|out.
ip as-path access-list 10 permit ^$route-map TO-ISP permit 10 match as-path 10router bgp 65001 neighbor 203.0.113.2 route-map TO-ISP out
Communities: routing policy as metadata
A community is a 32-bit tag, written AS:value (65001:100), attached to routes and carried wherever you let it travel. Communities do nothing by themselves — they are labels that route maps match on — and that is their power: the sender classifies routes once, and every downstream policy keys off the classification instead of re-matching prefixes. Providers publish community menus: tag your announcement 65010:80 and they set local preference 80; tag 65010:666 and they blackhole the prefix (remote-triggered blackholing, the standard DDoS response).
Three well-known communities are honoured by every implementation: no-export (advertise within this AS, but not to eBGP peers), no-advertise (advertise to nobody at all), and local-AS (keep within the confederation sub-AS). Sending communities to a neighbour is opt-in on Cisco — neighbor x.x.x.x send-community — and forgetting it is a classic silent policy failure.
route-map FROM-CUSTOMER permit 10 set community 65001:100 additiveroute-map TO-UPSTREAM deny 10 match community BLOCK-LISTroute-map TO-UPSTREAM permit 20ip community-list standard BLOCK-LIST permit 65001:666
The edge checklist
- Inbound from any eBGP peer: drop bogons and your own prefixes, cap prefix count with maximum-prefix, and filter to what the peer should legitimately send (customers: their registered prefixes; peers: their cone; upstreams: often everything, or default-only).
- Outbound to every eBGP peer: advertise only your own and your customers' prefixes — the ^$ or community-based filter that guarantees you never leak transit.
- Tag on ingress, filter on egress: classify every route with communities where it enters your network, and let every exit policy match communities instead of maintaining prefix lists in two places.
- After changing inbound policy, refresh without bouncing the session: clear bgp ipv4 unicast 203.0.113.2 soft in.
Policy is where BGP stops being a protocol you configure and becomes a system you design. The final chapter turns to the other axis of BGP at scale: what happens when the table is huge, the peers are many, and convergence time starts to matter.