Networking

BGP Prefix Lists and Route Maps: The Complete Guide to Controlling What You Accept and Advertise

By Travis · May 27, 2025 · 8 min read

#bgp #prefix-list #route-map #cisco #routing-policy #networking

Why BGP Policy Control Matters

BGP without filtering is dangerous. When you establish a BGP session with a peer, you’re trusting them to send you valid routing information — and trusting yourself not to leak routes you shouldn’t be advertising. Without explicit policy:

A customer could accidentally (or intentionally) send you a more-specific route for Google’s address space — and you’d install it
You could accidentally advertise your upstream provider’s routes to another upstream, turning yourself into an unintended transit provider
You could accept a default route from a peer that has no business being your default gateway

Prefix lists and route maps are the primary tools for defining and enforcing BGP routing policy on Cisco equipment. Understanding them is fundamental to operating BGP safely.

Prefix Lists: The Right Tool for Matching IP Prefixes

What’s Wrong with ACLs for BGP?

Network engineers who know ACLs often reach for them first when filtering BGP routes. ACLs work — but they have a critical limitation when used for prefix matching: they match on the address bits only, not the prefix length.

Consider filtering out all routes more specific than /24:

! ACL approach — WRONG for prefix length filtering
access-list 1 deny   any              ! Blocks everything
access-list 1 permit any              ! Permits everything
! There's no way to say "permit only /24 and shorter" with a standard ACL

Prefix lists solve this by matching on both the address AND the prefix length (with optional range):

! Prefix list — correct approach
ip prefix-list FILTER deny   0.0.0.0/0 ge 25    ! Deny /25 and longer
ip prefix-list FILTER permit 0.0.0.0/0 le 24    ! Permit /24 and shorter

Prefix List Syntax

ip prefix-list LIST-NAME [seq SEQUENCE] permit|deny PREFIX/LENGTH [ge MIN] [le MAX]

PREFIX/LENGTH: The network to match (e.g., 10.0.0.0/8)
ge MIN: Match if the prefix length is greater than or equal to MIN
le MAX: Match if the prefix length is less than or equal to MAX

The match logic: a prefix matches if:

The address bits (masked to the specified length) match the specified network
The prefix length falls within the specified ge/le range (if given)

Prefix List Examples

! Match exactly 10.0.0.0/8
ip prefix-list EXACT permit 10.0.0.0/8

! Match any prefix within 10.0.0.0/8 (any more-specific)
ip prefix-list RFC1918-10 permit 10.0.0.0/8 le 32

! Match only /24s within 192.168.0.0/16
ip prefix-list ONLY-24s permit 192.168.0.0/16 ge 24 le 24

! Match /24s and /25s within 192.168.0.0/16
ip prefix-list 24-AND-25 permit 192.168.0.0/16 ge 24 le 25

! Block anything more specific than /24 (anti-deaggregation filter)
ip prefix-list NO-SPECIFICS deny 0.0.0.0/0 ge 25
ip prefix-list NO-SPECIFICS permit 0.0.0.0/0 le 24

! Permit only the default route
ip prefix-list DEFAULT-ONLY permit 0.0.0.0/0

! Block the default route
ip prefix-list NO-DEFAULT deny 0.0.0.0/0
ip prefix-list NO-DEFAULT permit 0.0.0.0/0 le 32

! Permit only RFC 1918 address space
ip prefix-list RFC1918 permit 10.0.0.0/8 le 32
ip prefix-list RFC1918 permit 172.16.0.0/12 le 32
ip prefix-list RFC1918 permit 192.168.0.0/16 le 32

! Block bogons (RFC 1918 + other non-routable space)
ip prefix-list BOGON-FILTER deny 0.0.0.0/8 le 32
ip prefix-list BOGON-FILTER deny 10.0.0.0/8 le 32
ip prefix-list BOGON-FILTER deny 100.64.0.0/10 le 32
ip prefix-list BOGON-FILTER deny 127.0.0.0/8 le 32
ip prefix-list BOGON-FILTER deny 169.254.0.0/16 le 32
ip prefix-list BOGON-FILTER deny 172.16.0.0/12 le 32
ip prefix-list BOGON-FILTER deny 192.0.0.0/24 le 32
ip prefix-list BOGON-FILTER deny 192.168.0.0/16 le 32
ip prefix-list BOGON-FILTER deny 198.18.0.0/15 le 32
ip prefix-list BOGON-FILTER deny 240.0.0.0/4 le 32
ip prefix-list BOGON-FILTER permit 0.0.0.0/0 le 32

Applying Prefix Lists to BGP

Prefix lists are applied to BGP neighbors in the inbound or outbound direction:

router bgp 65001
  neighbor 203.0.113.1 prefix-list NO-SPECIFICS in    ! Filter what we accept
  neighbor 203.0.113.1 prefix-list MY-PREFIXES out     ! Filter what we advertise

After changing prefix lists or route maps applied to a BGP neighbor, you must soft-reset the session to apply the new policy without dropping the connection:

! Inbound soft reset (re-evaluate received routes)
clear ip bgp 203.0.113.1 soft in

! Outbound soft reset (re-advertise our routes)
clear ip bgp 203.0.113.1 soft out

! Both directions
clear ip bgp 203.0.113.1 soft

Route Maps: Multi-Condition Policy with Actions

Beyond Simple Permit/Deny

Prefix lists are powerful for matching prefixes, but they only permit or deny. Route maps do more — they can:

Match on multiple criteria simultaneously (prefix, AS path, communities, MED, next-hop)
Modify route attributes when a match occurs (set local-preference, MED, communities, next-hop, weight)
Apply different treatments to different subsets of routes

Think of a route map as a series of if/then rules applied to each route:

If route matches condition(s) in clause N → apply actions, permit/deny
If no match in clause N → try clause N+10
If no match in any clause → implicit deny (drop the route)

Route Map Structure

route-map MAP-NAME permit|deny SEQUENCE
  match [condition]        ! Zero or more match statements
  set [attribute]          ! Zero or more set statements (only for permit clauses)

A route-map clause with no match statement matches everything — useful as a catch-all at the end.

Multiple match statements in a single clause use AND logic — ALL conditions must match. To implement OR logic, use separate clauses with the same sequence range.

Match Conditions

! Match by prefix list
match ip address prefix-list MY-PREFIXES

! Match by AS path (using regex)
match as-path PATH-ACL-1

! Match by BGP community
match community COMMUNITY-LIST-1

! Match by MED value
match metric 100

! Match by next-hop
match ip next-hop prefix-list NEXTHOP-LIST

! Match by route type
match route-type local
match route-type external

! Match by tag (for redistributed routes)
match tag 100

Set Actions

! Set local preference (higher = more preferred within your AS)
set local-preference 200

! Set MED (lower = more preferred by remote AS, hint only)
set metric 100

! Set BGP communities
set community 65001:100 additive    ! Add community, keep existing
set community 65001:100             ! Replace all communities
set community none                  ! Remove all communities

! Set weight (local to this router only, higher = preferred)
set weight 1000

! Set next-hop
set ip next-hop 10.0.0.1
set ip next-hop self                ! Use this router as next-hop

! AS-path prepending (make route less preferred to remote)
set as-path prepend 65001 65001 65001

! Remove private ASNs from AS path
set as-path remove-private-as

! Set origin
set origin igp
set origin incomplete

AS Path Regular Expressions

AS path access lists use regular expressions to match patterns in the AS path string. This is one of the more powerful (and confusing) aspects of BGP policy:

! Match routes originated by AS 65002
ip as-path access-list 1 permit ^65002$
! ^ = start of path, $ = end, means "exactly 65002 with nothing else"

! Match routes that transit AS 65002 (anywhere in path)
ip as-path access-list 2 permit _65002_
! _ matches space, start, or end of string

! Match routes originated locally (empty AS path)
ip as-path access-list 3 permit ^$

! Match routes from your direct peers only (one ASN away)
ip as-path access-list 4 permit ^[0-9]+$

! Match all routes (permit everything)
ip as-path access-list 5 permit .*

! Block routes from AS 64512 and everything downstream of it
ip as-path access-list 6 deny _64512_
ip as-path access-list 6 permit .*

Practical BGP Policy Configurations

Scenario 1: Basic Customer Filter

A customer connects via BGP and should only advertise their own prefixes:

! Define what the customer is allowed to advertise
ip prefix-list CUSTOMER-ACME permit 203.0.113.0/24
ip prefix-list CUSTOMER-ACME permit 198.51.100.0/24

! Apply inbound — only accept their legitimate prefixes
router bgp 65000
  neighbor 10.0.0.2 remote-as 65100
  neighbor 10.0.0.2 description CUSTOMER-ACME
  neighbor 10.0.0.2 prefix-list CUSTOMER-ACME in
  ! Advertise a default route to the customer
  neighbor 10.0.0.2 default-originate

Scenario 2: Inbound Policy with Local Preference

Prefer routes from your primary upstream over backup:

! Match everything from primary upstream
route-map FROM-PRIMARY permit 10
  set local-preference 200    ! High = preferred

! Match everything from backup upstream  
route-map FROM-BACKUP permit 10
  set local-preference 100    ! Lower = less preferred

router bgp 65001
  neighbor 203.0.113.1 remote-as 64512    ! Primary
  neighbor 203.0.113.1 route-map FROM-PRIMARY in
  
  neighbor 203.0.113.2 remote-as 64513    ! Backup
  neighbor 203.0.113.2 route-map FROM-BACKUP in

Scenario 3: Community-Based Traffic Engineering

Use communities to signal preferred routing to your upstream:

! Tag outbound routes with communities for upstream policy
! (Communities used vary by upstream — check their looking glass)
route-map TO-UPSTREAM permit 10
  match ip address prefix-list MY-PREFIXES
  set community 64512:100 additive     ! Example: upstream's "prefer this path" community

! Strip communities we receive before passing to other peers
route-map STRIP-COMMUNITIES permit 10
  set community none

router bgp 65001
  neighbor 203.0.113.1 route-map TO-UPSTREAM out
  neighbor 10.0.0.1 route-map STRIP-COMMUNITIES out   ! Don't leak upstream communities

Scenario 4: Full Internet Peering with RPKI-Based Filtering

A more complete inbound policy combining multiple tools:

! Bogon prefix filter
ip prefix-list BOGONS deny 0.0.0.0/8 le 32
ip prefix-list BOGONS deny 10.0.0.0/8 le 32
ip prefix-list BOGONS deny 100.64.0.0/10 le 32
ip prefix-list BOGONS deny 127.0.0.0/8 le 32
ip prefix-list BOGONS deny 169.254.0.0/16 le 32
ip prefix-list BOGONS deny 172.16.0.0/12 le 32
ip prefix-list BOGONS deny 192.168.0.0/16 le 32
ip prefix-list BOGONS deny 240.0.0.0/4 le 32
ip prefix-list BOGONS permit 0.0.0.0/0 le 24    ! Only accept /24 and shorter

! Bogon ASN filter
ip as-path access-list 10 deny _0_              ! Block AS 0
ip as-path access-list 10 deny _23456_          ! Block AS_TRANS placeholder
ip as-path access-list 10 deny _6449[2-9]_      ! Block private 2-byte ASNs
ip as-path access-list 10 deny _6[5-9][0-9][0-9][0-9]_
ip as-path access-list 10 deny _6[5-9][0-9][0-9][0-9][0-9]_
ip as-path access-list 10 permit .*

! Inbound route-map combining all filters
route-map FROM-PEER permit 10
  match ip address prefix-list BOGONS      ! Reject bogon prefixes
  set local-preference 100
route-map FROM-PEER deny 20
  match as-path 10                         ! Reject bogon ASNs

router bgp 65001
  bgp rpki server tcp 10.0.0.100 port 3323    ! Connect RPKI validator
  neighbor 203.0.113.1 route-map FROM-PEER in

Troubleshooting Route Maps and Prefix Lists

! Check if a specific prefix matches a prefix list
show ip prefix-list FILTER 10.0.0.0/24

! Show all entries in a prefix list
show ip prefix-list FILTER

! Check route map processing
debug ip bgp 203.0.113.1 updates in
debug ip bgp 203.0.113.1 updates out

! See what routes are being accepted/rejected
show ip bgp neighbors 203.0.113.1 received-routes   ! Requires soft-reconfig inbound
show ip bgp neighbors 203.0.113.1 advertised-routes

! Check route map statistics (how many routes matched each clause)
show route-map MY-ROUTE-MAP

! Test AS path regex
show ip bgp regexp ^65002$

Best Practices

Always have an explicit deny at the end of prefix lists used for inbound filtering. Without it, the implicit deny catches anything not matched — which is correct, but can be confusing. An explicit final deny any makes intent clear.

Use prefix lists for prefix matching and route maps for attribute manipulation. Don’t use route maps where a simpler prefix list will do — route maps are harder to troubleshoot.

Sequence numbers matter. Leave gaps between sequence numbers (10, 20, 30) so you can insert entries without rewriting the entire list. ip prefix-list FILTER seq 15 permit ... inserts between 10 and 20.

Filter both inbound and outbound. Inbound filters protect you from accepting bad routes. Outbound filters protect your peers from your mistakes. Both are necessary.

Never accept routes more specific than /24 from the internet. More-specific routes are almost always either misconfigured, leaked internal routes, or route hijacking attempts. /24 is the generally accepted maximum specificity for globally routable prefixes.

Always filter RFC 1918 and bogon prefixes from internet-facing peers. Private address space and reserved prefixes have no legitimate place in the global routing table.