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 in

Standard 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 in

ACL 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/0

Juniper 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 allow

BGP 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
end

When to Use Each

ScenarioUseReason
Filter BGP prefixes from a peerPrefix listPrecise prefix-length matching with le/ge; better performance
Filter routes during redistributionPrefix list (via route-map)More readable and maintainable than distribute-list with ACL
Block traffic on an interfaceACL (extended)Packet-level match on src/dst IP, port, protocol
Allow a management subnet to SSH to routersACL (standard or extended)Simple source-IP match; prefix lists cannot match traffic
Prevent default route acceptance from eBGP peerPrefix listDeny 0.0.0.0/0 le 0 (exact match on default route)
QoS classification by subnetACL (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

Open Prefix List Generator