How to Configure BGP Route Filtering on Cisco Routers: Prefix Lists and Route Maps

Filtering is the backbone of safe BGP operation. Every route you accept from a peer, every route you advertise, and every routing policy decision you make should pass through deliberate filtering — otherwise you’re trusting every neighbor to only ever send you exactly what they should, which is not a bet worth making on the internet. This guide covers prefix lists, route maps, AS-path filtering, and how to combine them into a coherent BGP filtering strategy on Cisco routers.

Why Filtering Matters More in BGP Than Anywhere Else

Internal routing protocols operate within a trust boundary you control end to end. BGP, by contrast, is the protocol that talks to the outside world — other organizations, other networks, sometimes networks you have no operational relationship with beyond a peering agreement. A missing filter can mean:

• Accepting a full internet routing table from a peer who should only be sending you a default route.
• Accepting more-specific prefixes that hijack routing for address space you don’t actually own (route hijacking, whether malicious or accidental).
• Advertising your internal address space or a partner’s routes to the wrong peer.
• Accepting a default route from a peer who shouldn’t be providing one, silently black-holing your traffic.

Prefix Lists: The Building Block

Prefix lists match on IP prefix and prefix length range, and are generally preferred over old-style access-lists for BGP filtering because they’re more expressive and easier to read.

Basic Syntax

Router(config)# ip prefix-list NAME seq 10 permit 198.51.100.0/24
Router(config)# ip prefix-list NAME seq 20 deny 0.0.0.0/0

Matching a Range of Prefix Lengths

To permit any subnet of 198.51.100.0/22 that is at least a /24 but no more specific than /26:

Router(config)# ip prefix-list SPECIFIC-RANGE seq 10 permit 198.51.100.0/22 ge 24 le 26

Denying the Default Route

A very common defensive filter on eBGP sessions where you never want to accept a default route from a peer:

Router(config)# ip prefix-list NO-DEFAULT seq 5 deny 0.0.0.0/0
Router(config)# ip prefix-list NO-DEFAULT seq 10 permit 0.0.0.0/0 le 32

Applying a Prefix List Directly to a Neighbor

Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 prefix-list NO-DEFAULT in

Filtering Bogons and Private Address Space

Any router accepting full eBGP routes from an external peer should filter RFC 1918 space, documentation prefixes, and other bogon ranges that should never legitimately appear in the global table:

ip prefix-list BOGONS seq 10 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS seq 20 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS seq 30 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS seq 40 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS seq 50 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS seq 60 permit 0.0.0.0/0 le 32

router bgp 65001
 neighbor 203.0.113.2 prefix-list BOGONS in

In production, many operators subscribe to maintained bogon feeds rather than hand-maintaining this list, since the exact set of reserved/unallocated space changes over time.

AS-Path Filtering

AS-path access lists filter based on the AS-path attribute using regular expressions, useful for filtering by origin AS or path characteristics rather than prefix value.

Basic AS-Path ACL

Router(config)# ip as-path access-list 10 permit ^65002$

This matches only routes originated directly by AS 65002 with no other AS in the path — i.e., routes learned directly from that neighbor with them as the origin.

Denying Routes That Traverse a Specific AS

Router(config)# ip as-path access-list 20 deny _65099_
Router(config)# ip as-path access-list 20 permit .*

The underscores act as word boundaries in the regex, matching AS 65099 anywhere in the path.

Applying AS-Path Filters to a Neighbor

Router(config-router)# neighbor 203.0.113.2 filter-list 20 in

Route Maps: Combining and Extending Filters

Route maps let you combine prefix-list matches, AS-path matches, and community matches into a single policy, and also apply actions (set statements) beyond simple permit/deny.

Example: Filter and Set Local Preference Together

route-map ISP-A-IN permit 10
 match ip address prefix-list CUSTOMER-BLOCKS
 match as-path 10
 set local-preference 150
route-map ISP-A-IN deny 20

router bgp 65001
 neighbor 203.0.113.2 route-map ISP-A-IN in

Note the explicit deny 20 at the end — while route-maps have an implicit deny-all if you don’t add one, being explicit here makes the intent obvious to the next engineer reading the config, and gives you a place to add logging or additional matches later.

Outbound Filtering Example

Ensuring only your organization’s specific advertised blocks ever leave toward a given peer, regardless of what else might get redistributed into BGP internally:

route-map OUTBOUND-TO-ISP-A permit 10
 match ip address prefix-list MY-ADVERTISED-BLOCKS
route-map OUTBOUND-TO-ISP-A deny 20

router bgp 65001
 neighbor 203.0.113.2 route-map OUTBOUND-TO-ISP-A out

This is a critical safety net — even if something goes wrong with redistribution internally, this outbound filter is the last line of defense preventing unintended prefixes from reaching the peer.

Maximum-Prefix Protection

Even with careful filtering, it’s wise to configure a hard limit on how many prefixes you’ll accept from any given peer, to protect against configuration mistakes on their end or intentional route table stuffing:

router bgp 65001
 neighbor 203.0.113.2 maximum-prefix 500 80 restart 5

This tears down the session if the peer sends more than 500 prefixes, warns at 80% of that threshold, and attempts to restart the session after 5 minutes.

Real-World Scenario: Multi-Homed Customer Edge Router

An enterprise multi-homed to two ISPs wants to:

1. Only accept a default route plus specific partner routes from each ISP (not the full internet table).
2. Only advertise its own public block, nothing else.
3. Reject any accidental RFC 1918 announcements from either ISP.

ip prefix-list ACCEPT-FROM-ISP seq 10 permit 0.0.0.0/0
ip prefix-list ACCEPT-FROM-ISP seq 20 permit 203.0.113.0/24
ip prefix-list ACCEPT-FROM-ISP seq 900 deny 10.0.0.0/8 le 32
ip prefix-list ACCEPT-FROM-ISP seq 910 deny 172.16.0.0/12 le 32
ip prefix-list ACCEPT-FROM-ISP seq 920 deny 192.168.0.0/16 le 32

ip prefix-list MY-BLOCK seq 10 permit 198.51.100.0/24

router bgp 65001
 neighbor 203.0.113.1 remote-as 64500
 neighbor 203.0.113.1 prefix-list ACCEPT-FROM-ISP in
 neighbor 203.0.113.1 prefix-list MY-BLOCK out
 neighbor 203.0.113.1 maximum-prefix 100 80

 neighbor 198.51.100.1 remote-as 64501
 neighbor 198.51.100.1 prefix-list ACCEPT-FROM-ISP in
 neighbor 198.51.100.1 prefix-list MY-BLOCK out
 neighbor 198.51.100.1 maximum-prefix 100 80

Verification Commands

Router# show ip prefix-list NAME
Router# show ip prefix-list detail NAME
Router# show ip bgp neighbors 203.0.113.2 received-routes
Router# show ip bgp neighbors 203.0.113.2 advertised-routes
Router# show ip bgp filter-list 20

Sample output showing filter hit counts:

Router# show ip prefix-list detail ACCEPT-FROM-ISP
ip prefix-list ACCEPT-FROM-ISP:
   count: 5, range entries: 3, sequences: 10 - 920, refcount: 2
   seq 10 permit 0.0.0.0/0 (hit count: 1, refcount: 1)
   seq 20 permit 203.0.113.0/24 (hit count: 1, refcount: 1)

Common Configuration Mistakes

• Relying only on inbound filtering and skipping outbound filtering — always filter both directions; internal mistakes (like a bad redistribution) will bypass an inbound-only filtering strategy.
• Forgetting the implicit deny at the end of prefix lists and route-maps, causing routes to be unexpectedly dropped after adding new permit entries without extending or reordering sequence numbers correctly.
• Not filtering bogons/RFC 1918 space on eBGP sessions accepting full routes, leaving the router vulnerable to accidental or malicious announcements.
• Confusing le/ge semantics — ge and le describe the prefix length range being matched, not additive/subtractive modifiers; a common source of prefix-list logic errors.
• Skipping maximum-prefix, leaving no automatic protection against a peer sending an unexpectedly large route table.

Best Practices

1. Filter in both directions on every eBGP session — inbound to protect your own table, outbound to protect your peer and your reputation.
2. Always configure maximum-prefix on external sessions as a safety net beyond explicit filtering.
3. Maintain bogon/RFC 1918 filters and review them periodically, since reserved and allocated space changes over time.
4. Use route-maps rather than bare prefix-list application whenever you need to combine matches or apply set actions, keeping policy logic centralized and readable.
5. Document sequence number gaps deliberately (increments of 10) so future entries can be inserted without renumbering everything.
6. Test filter changes with show ip bgp neighbors ... received-routes / advertised-routes before and after, comparing route counts to catch unintended drops or leaks.

Troubleshooting Checklist

• show ip prefix-list detail NAME — check hit counts to confirm the filter is actually matching traffic as designed.
• show ip bgp neighbors X received-routes — requires soft-reconfiguration inbound or BGP route-refresh capability to show pre-filter routes for comparison.
• show ip bgp neighbors X advertised-routes — confirm outbound filtering results.
• show ip bgp summary — check prefix counts received per neighbor against expectations.
• If a session flaps unexpectedly, check maximum-prefix thresholds and logs for a limit breach.

FAQs

What’s the difference between a prefix-list and an access-list for BGP filtering? Prefix lists are purpose-built for BGP/routing filtering, support ge/le range matching, and are generally more readable and performant than legacy access-lists reused for routing filters. Prefix lists are the modern standard.

Do I need soft-reconfiguration inbound to see received routes before filtering? Yes, unless your routers support the BGP route-refresh capability (most modern IOS/IOS-XE do), in which case show ip bgp neighbors X received-routes works without needing the memory-intensive soft-reconfiguration storage.

Should I filter based on AS-path or prefix-list for customer routes? Both, ideally — prefix-list filtering ensures only expected address space is accepted, while AS-path filtering adds a layer of validation that the route actually originates from (or transits) the expected AS.

How strict should outbound filtering be on a simple single-homed customer router? Even single-homed setups benefit from an explicit outbound prefix-list limiting advertisement to exactly your allocated block — it’s cheap insurance against internal misconfiguration leaking unintended routes.

Summary

BGP route filtering is not optional hardening — it’s core operational hygiene for any router speaking BGP to an external peer. Prefix lists handle address-based filtering with clean range matching, AS-path filters add origin and transit validation, and route-maps tie it together with the ability to also set attributes like local preference or communities in the same policy pass. Filtering deliberately in both directions, protecting against bogons, and backing it all up with maximum-prefix limits gives you a BGP edge that fails safely rather than silently accepting or leaking routes it shouldn’t.

References

• Configuring BGP Filtering: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-16/irg-xe-16-book/irg-bgp-filtering.html
• IP Prefix List Configuration: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-16/irg-xe-16-book/irg-prefix-lists.html
• BGP Best Practices – Team Cymru Bogon Reference: https://www.team-cymru.com/bogon-reference