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.
If you want the bigger picture first, the BGP complete guide covers the architecture this article plugs into.
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/8matches 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
levalue if specified). - le (less than or equal to): Match prefix lengths up to this value, starting from the base length (or from the
gevalue 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/0Applying 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 inFrom the other end of a ticket an inbound list looks nothing like a filter problem: the peer is advertising correctly, the session is Established, and the prefix simply is not there. Before you escalate to the far side, check whether your own inbound filter ate the prefix, because it presents identically to five other causes.
Outbound Filtering (what you advertise)
R1-HQ(config-router)# neighbor 172.16.0.2 prefix-list OUR-PREFIXES outReal-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 inThis 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 outThis 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 24The 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 inVerification
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 150Troubleshooting
show ip prefix-list [name] for hit counts. Verify the permit entries match expected prefixes. Remember the implicit deny at the end.show ip bgp neighbors [ip] | include prefix. Do a soft reset: clear ip bgp [ip] soft in.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] detailto verify your filters are matching as expected.