BGP

BGP Route Filtering with Prefix Lists

Prefix lists are the preferred BGP filtering tool: faster than ACLs, easier to read, and built for matching networks with specific prefix lengths. Every production BGP deployment needs them on inbound and outbound.
BGP Route Filtering with Prefix Lists
In: BGP

Controlling which routes you accept from peers and which routes you advertise is fundamental to BGP operations. Prefix lists are the preferred tool for this — they're faster than access lists, easier to read, and purpose-built for matching IP prefixes with specific prefix lengths. Every production BGP deployment should have prefix-list filters on both inbound and outbound directions.

Prefix List Syntax

ip prefix-list NAME [seq N] {permit|deny} PREFIX/LEN [ge MIN] [le MAX]
  • PREFIX/LEN: The network and prefix length to match. 10.0.0.0/8 matches exactly 10.0.0.0 with a /8 mask.
  • ge (greater than or equal to): Match prefix lengths from this value up to 32 (or up to the le value if specified).
  • le (less than or equal to): Match prefix lengths up to this value, starting from the base length (or from the ge value if specified).

Examples

! Match exactly 10.1.0.0/16 — nothing else
ip prefix-list EXACT permit 10.1.0.0/16

! Match 10.0.0.0/8 and all more-specific prefixes (/8 through /32)
ip prefix-list AGGREGATE-AND-SPECIFICS permit 10.0.0.0/8 le 32

! Match any prefix within 10.0.0.0/8 that is between /16 and /24
ip prefix-list RANGE permit 10.0.0.0/8 ge 16 le 24

! Match any prefix (0.0.0.0/0 le 32 = everything)
ip prefix-list ANY permit 0.0.0.0/0 le 32

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

Applying to BGP Neighbors

Inbound Filtering (what you accept)

R1-HQ(config)# router bgp 65001
R1-HQ(config-router)# neighbor 172.16.0.2 prefix-list ISP-A-INBOUND in

Outbound Filtering (what you advertise)

R1-HQ(config-router)# neighbor 172.16.0.2 prefix-list OUR-PREFIXES out

Real-World Filtering Scenarios

Scenario 1: Accept Only Specific Prefixes from a Peer

You have a private peering agreement with a partner (AS 65010) who should only send you their allocated space: 100.64.0.0/16 and its subnets.

ip prefix-list ISP-A-INBOUND seq 10 permit 100.64.0.0/16 le 24
ip prefix-list ISP-A-INBOUND seq 100 deny 0.0.0.0/0 le 32
!
router bgp 65001
 neighbor 172.16.0.2 prefix-list ISP-A-INBOUND in

This accepts 100.64.0.0/16 and any subnets up to /24 (allowing their internal disaggregation) but blocks everything else. The implicit deny at the end of a prefix list means seq 100 is technically redundant but makes intent explicit — always a good practice.

Scenario 2: Advertise Only Your Own Prefixes

Never trust yourself to not leak routes. Always filter outbound:

ip prefix-list OUR-PREFIXES seq 10 permit 10.1.0.0/16
ip prefix-list OUR-PREFIXES seq 20 permit 10.2.0.0/16
!
router bgp 65001
 neighbor 172.16.0.2 prefix-list OUR-PREFIXES out
 neighbor 172.16.0.6 prefix-list OUR-PREFIXES out

This ensures you only advertise your own address space (10.1.0.0/16 and 10.2.0.0/16) to ISPs, regardless of what other routes exist in your BGP table.

Scenario 3: Bogon Filtering (Inbound)

Bogons are prefixes that should never appear in the global BGP table. Filter them inbound from all eBGP peers:

ip prefix-list BOGON-FILTER seq 10 deny 0.0.0.0/8 le 32
ip prefix-list BOGON-FILTER seq 20 deny 10.0.0.0/8 le 32
ip prefix-list BOGON-FILTER seq 30 deny 100.64.0.0/10 le 32
ip prefix-list BOGON-FILTER seq 40 deny 127.0.0.0/8 le 32
ip prefix-list BOGON-FILTER seq 50 deny 169.254.0.0/16 le 32
ip prefix-list BOGON-FILTER seq 60 deny 172.16.0.0/12 le 32
ip prefix-list BOGON-FILTER seq 70 deny 192.0.2.0/24 le 32
ip prefix-list BOGON-FILTER seq 80 deny 192.168.0.0/16 le 32
ip prefix-list BOGON-FILTER seq 90 deny 198.51.100.0/24 le 32
ip prefix-list BOGON-FILTER seq 100 deny 203.0.113.0/24 le 32
ip prefix-list BOGON-FILTER seq 110 deny 224.0.0.0/4 le 32
ip prefix-list BOGON-FILTER seq 120 deny 240.0.0.0/4 le 32
ip prefix-list BOGON-FILTER seq 900 permit 0.0.0.0/0 le 24

The final line permits all other prefixes up to /24 — this also filters overly specific prefixes (longer than /24), which are generally noise or misconfigurations. Adjust the /24 threshold based on your requirements — some networks accept up to /28 for specific reasons.

Scenario 4: Accept Default Route Only

If your ISP sends you only a default route (common in single-homed setups):

ip prefix-list DEFAULT-ONLY seq 10 permit 0.0.0.0/0
!
router bgp 65001
 neighbor 172.16.0.2 prefix-list DEFAULT-ONLY in

Verification

R1-HQ# show ip prefix-list ISP-A-INBOUND
ip prefix-list ISP-A-INBOUND: 2 entries
   seq 10 permit 100.64.0.0/16 le 24
   seq 100 deny 0.0.0.0/0 le 32

R1-HQ# show ip prefix-list ISP-A-INBOUND detail
ip prefix-list ISP-A-INBOUND:
   count: 2, range entries: 1, sequences: 10 - 100, refcount: 1
   seq 10 permit 100.64.0.0/16 le 24 (hit count: 4)
   seq 100 deny 0.0.0.0/0 le 32 (hit count: 12)

The hit counts show how many routes matched each entry — useful for verifying the filter is working as expected.

! See what ISP-A is sending vs what we accept after filtering
R1-HQ# show ip bgp neighbors 172.16.0.2 received-routes
  ... (all routes from ISP-A, pre-filter)

R1-HQ# show ip bgp neighbors 172.16.0.2 routes
  ... (only routes that passed the prefix-list filter)

Prefix Lists vs Route Maps

Prefix lists can only match on prefix and prefix length — they can't match on AS-path, communities, or other attributes, and they can't set anything. For that, you need route maps (covered next). A common pattern is to use a prefix list inside a route map as a match condition:

route-map ISP-A-POLICY permit 10
 match ip address prefix-list ISP-A-INBOUND
 set local-preference 150

Troubleshooting

SymptomCauseFix
All routes from peer disappeared after applying prefix listPrefix list denying everything — missing permit statement or typo in prefix/lengthCheck show ip prefix-list [name] for hit counts. Verify the permit entries match expected prefixes. Remember the implicit deny at the end.
Prefix list applied but routes unchangedPrefix list applied in wrong direction (in vs out) or to wrong neighborVerify with show ip bgp neighbors [ip] | include prefix. Do a soft reset: clear ip bgp [ip] soft in.
Specific prefix being denied unexpectedlyge/le range not covering the prefix length, or earlier deny entry matching firstCheck sequence numbers — earlier entries are evaluated first. Use show ip prefix-list [name] [prefix] to test which entry matches.

Key Takeaways

  • Prefix lists are the preferred method for BGP route filtering — faster and more readable than access lists.
  • Always filter both inbound (what you accept) and outbound (what you advertise) on eBGP sessions.
  • Use ge/le operators to match ranges of prefix lengths. Without ge/le, only exact matches are permitted.
  • Bogon filtering is a baseline security measure — every internet-facing BGP router should have it.
  • Check hit counts with show ip prefix-list [name] detail to verify your filters are matching as expected.
Written by
More from Ping Labz
MPLS L3VPN with MP-BGP and VPNv4
MPLS

MPLS L3VPN with MP-BGP and VPNv4

MPLS L3VPN architecture: VRFs, Route Distinguishers, Route Targets, MP-BGP for VPNv4, the two-label stack, PE-CE routing, and the Cisco IOS XE configuration.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Ping Labz.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.