BGP Route Filtering & Prefix Lists

Why Filter BGP Routes?

Without filtering, any BGP peer can announce any prefix. This has led to major incidents:

• Route hijacks — An AS announces someone else's prefix, redirecting traffic.
• Route leaks — A network accidentally re-advertises routes learned from one peer to another.
• Table bloat — Accepting unnecessarily specific prefixes increases routing table size.

Proper filtering is not optional — it is the foundation of BGP security.

Prefix List Filtering

Prefix lists define which networks you accept or advertise:

# Cisco IOS: Only accept customer prefixes
ip prefix-list CUSTOMER-IN permit 203.0.113.0/24
ip prefix-list CUSTOMER-IN deny 0.0.0.0/0 le 32

# Apply to BGP neighbor
router bgp 65000
  neighbor 198.51.100.1 prefix-list CUSTOMER-IN in

Best practices: - Always filter inbound from customers — accept only their registered prefixes. - Filter inbound from peers — reject default route, bogons, your own prefixes. - Filter outbound to peers — advertise only your own and customer prefixes.

AS-Path Filtering

Filter based on the AS path (the sequence of ASNs a route has traversed):

# Accept routes originating from AS 64512
ip as-path access-list 10 permit ^64512$

# Reject routes with suspiciously long paths (>6 hops)
ip as-path access-list 20 deny _([0-9]+)_\1_  # Loop detection
ip as-path access-list 20 deny ^.{50,}$        # Path too long

IRR-Based Filtering

Internet Routing Registries (IRRs) like RADB, RIPE, and ARIN maintain databases of who is authorized to announce which prefixes. Automated tools generate prefix lists from IRR data:

# Generate prefix list from IRR using bgpq4
bgpq4 -4 -l CUSTOMER-IN AS64512
# Output: Cisco-format prefix list based on registered routes

# For BIRD
bgpq4 -4 -b -l CUSTOMER-IN AS64512

RPKI: Cryptographic Validation

Resource Public Key Infrastructure (RPKI) provides cryptographic proof of prefix ownership through Route Origin Authorizations (ROAs):

ROA: AS 64512 is authorized to originate 203.0.113.0/24 (maxLength /24)

Routers validate received routes against ROA data:

Recommended Filter Policy

1. Inbound from customers: Accept only their registered prefixes (IRR + RPKI).
2. Inbound from peers: Reject bogons, default route, your own space. Validate with RPKI.
3. Outbound to everyone: Advertise only your own prefixes and customer prefixes.
4. Max-prefix limits: Set per-session limits to prevent table flooding.