Guide
Prefix Lists vs ACLs: A Multi-Vendor Guide
How prefix lists and access lists differ, when to use each, and how the syntax maps across Cisco IOS, Juniper, Palo Alto, and Fortinet.
NextHop LLC · Updated 2026-06-07
Prefix lists and access control lists are both filtering constructs, but they operate at different layers and serve different purposes. Confusing the two is a common source of routing policy bugs that are difficult to diagnose — this guide clarifies the distinction and maps the syntax across Cisco IOS, Juniper Junos, Palo Alto, and Fortinet.
The Fundamental Difference
The most important thing to understand: prefix lists filter routing information; ACLs filter packets (and can also filter routes, with important caveats).
A prefix list is a sequence of permit/deny statements that match IP prefixes — network addresses plus their prefix lengths. Prefix lists are applied to BGP neighbors, redistribution, or route maps to control which routes are accepted into or advertised out of the routing table. They are not involved in forwarding decisions for live traffic.
An ACL (Access Control List) is a packet filter. In its classic form it matches on source/destination IP (and optionally port/protocol) and is applied to an interface or a policy to permit or deny traffic. On Cisco IOS, ACLs can also be used inside a distribute-list to filter routes, but this is considered legacy practice — prefix lists are more precise, perform better, and are easier to read.
Prefix List Mechanics: le and ge
A prefix list entry matches on two dimensions: the network address and the prefix length. The le (less-than-or-equal) and ge (greater-than-or-equal) keywords add a prefix-length range, making prefix lists far more expressive than ACLs for route filtering.
ip prefix-list EXAMPLE permit 10.0.0.0/8— matches only the exact prefix 10.0.0.0/8. A /9 or /24 within that block does not match.ip prefix-list EXAMPLE permit 10.0.0.0/8 le 24— matches any prefix within 10.0.0.0/8 with a prefix length from /8 up to /24 inclusive.ip prefix-list EXAMPLE permit 10.0.0.0/8 ge 16 le 24— matches prefixes within 10.0.0.0/8 with length between /16 and /24.ip prefix-list EXAMPLE permit 0.0.0.0/0 le 32— matches all prefixes (the universal permit). Useful as a catch-all at the end of a list.
There is an implicit deny all at the end of every prefix list, just like an ACL. If a route does not match any permit entry, it is denied.
Cisco IOS Syntax Examples
Prefix list applied to a BGP neighbor to filter inbound prefixes from a peer:
! Define the prefix list ip prefix-list CUSTOMER-IN seq 5 permit 192.168.100.0/24 ip prefix-list CUSTOMER-IN seq 10 permit 192.168.101.0/24 ip prefix-list CUSTOMER-IN seq 15 deny 0.0.0.0/0 le 32 ! Apply to a BGP neighbor (inbound) router bgp 65001 neighbor 203.0.113.1 prefix-list CUSTOMER-IN inStandard ACL — matches source IP for packet filtering on an interface:
! Standard numbered ACL (source IP only) access-list 10 permit 10.10.10.0 0.0.0.255 access-list 10 deny any ! Extended named ACL — matches source + destination + protocol ip access-list extended BLOCK-TELNET deny tcp any any eq 23 permit ip any any ! Apply to an interface (inbound) interface GigabitEthernet0/1 ip access-group BLOCK-TELNET inACL used in a distribute-list for route filtering (legacy, avoid on modern IOS XE):
! This works but prefix-lists are preferred access-list 1 permit 192.168.0.0 0.0.255.255 router ospf 1 distribute-list 1 in GigabitEthernet0/0Juniper Junos Syntax
Junos uses route-filter statements inside a policy to match prefixes. The equivalent of le/ge uses upto andprefix-length-range:
# Junos policy — equivalent of Cisco prefix-list CUSTOMER-IN
policy-statement CUSTOMER-IN {
term accept-customer-prefixes {
from {
route-filter 192.168.100.0/24 exact;
route-filter 192.168.101.0/24 exact;
}
then accept;
}
term default-deny {
then reject;
}
}
# Match any prefix within 10.0.0.0/8 up to /24 (equivalent to: le 24)
policy-statement ACCEPT-RFC1918-SUMMARIES {
term match {
from {
route-filter 10.0.0.0/8 upto /24;
}
then accept;
}
}
# Apply to BGP neighbor
protocols bgp {
group CUSTOMER {
neighbor 203.0.113.1 {
import CUSTOMER-IN;
}
}
}Junos firewall filters (packet ACLs) use a different configuration hierarchy under firewall family inet filter and are applied with input/output on interface units — distinct from routing policies.
Palo Alto and Fortinet: Address Objects vs Route Filters
Next-generation firewalls separate packet filtering from routing policy more cleanly than IOS does. On Palo Alto Networks firewalls, packet filtering is done through Security Policy rules that reference Address Objects:
# Palo Alto — Address Object (CLI / Panorama set command)
set address "Corp-LAN" ip-netmask 10.10.10.0/24
set address "Corp-Servers" ip-netmask 10.10.10.128/26
# Security policy referencing address objects
set rulebase security rules "Allow-Corp-To-Internet" \
source "Corp-LAN" \
destination any \
application any \
service application-default \
action allowBGP route filtering on Palo Alto uses Import/Export Rules under the BGP configuration with prefix-match conditions — conceptually identical to Cisco prefix lists but configured in the web UI or as XML via the API.
On Fortinet FortiGate, address objects define IP ranges for firewall policies; BGP prefix filtering uses prefix-list and route-map in the CLI:
# FortiGate — address object for packet filtering
config firewall address
edit "Corp-LAN"
set subnet 10.10.10.0 255.255.255.0
next
end
# FortiGate — BGP prefix-list (route filtering)
config router prefix-list
edit "CUSTOMER-IN"
config rule
edit 1
set prefix 192.168.100.0/24
set ge 24
set le 24
set action permit
next
edit 2
set prefix 192.168.101.0/24
set ge 24
set le 24
set action permit
next
end
next
end
config router bgp
config neighbor
edit "203.0.113.1"
set prefix-list-in "CUSTOMER-IN"
next
end
endWhen to Use Each
| Scenario | Use | Reason |
|---|---|---|
| Filter BGP prefixes from a peer | Prefix list | Precise prefix-length matching with le/ge; better performance |
| Filter routes during redistribution | Prefix list (via route-map) | More readable and maintainable than distribute-list with ACL |
| Block traffic on an interface | ACL (extended) | Packet-level match on src/dst IP, port, protocol |
| Allow a management subnet to SSH to routers | ACL (standard or extended) | Simple source-IP match; prefix lists cannot match traffic |
| Prevent default route acceptance from eBGP peer | Prefix list | Deny 0.0.0.0/0 le 0 (exact match on default route) |
| QoS classification by subnet | ACL (in route-map) | Route-map matches ACL for MQC policy-map classification |
The Prefix List Generator tool generates multi-vendor prefix list syntax automatically from a list of prefixes — useful when you have a large number of customer prefixes to allow. For understanding the address space those prefixes come from, see the ASN and BGP prefix guide.
Try the tool
Prefix List Generator