Introduction to Prefix Lists
Definition and Purpose
A prefix list is an ordered set of permit/deny statements that match IP prefixes based on their address and prefix length. Unlike an access-list that inspects arbitrary bits, a prefix list evaluates the network portion of an address and optionally enforces a range of permissible prefix lengths with the ge (greater-than or equal) and le (less-than or equal) operators. Prefix lists are primarily used in routing policy (route-maps, policy-statements, import/export filters) to control which prefixes are admitted to, advertised from, or redistributed into a routing protocol such as BGP, OSPF, or IS-IS.
Configuration and Implementation
On most network operating systems, the syntax follows a common pattern:
| Vendor | Command Mode | Basic Syntax | Example |
|---|---|---|---|
| Cisco IOS/IOS-XE/IOS-XR | `ip prefix-list | deny} | ip prefix-list PL-ACC seq 10 permit 10.0.0.0/8 ge 16 le 24 |
| Juniper Junos | policy-options prefix-list <name> { <address>/<length>; } (range expressed via prefix-list + prefix-list-filter in policy) | policy-options { prefix-list PL-ACC { 10.0.0.0/8 orlonger; } } + then { prefix-list-filter PL-ACC prefix-length-range /16-/24; } | |
| Arista EOS | `ip prefix-list | deny} | identical to Cisco |
| Nokia SR OS | configure router policy-options prefix-list <name> prefix <network>/<length> [ge <min>] [le <max>] | similar | |
The list is processed sequentially; the first matching entry determines the permit/deny outcome. If no entry matches, an implicit deny any (or permit any depending on vendor) applies. |
Understanding Prefix List Coverage
Intended Coverage
Intended coverage is the set of prefixes the network designer believes the prefix list will match, based on the configured network/length, ge, and le values. It is a mental model derived from the policy statement.
Example: ip prefix-list PL-INT seq 5 permit 10.0.0.0/8 ge 16 le 24
Intended coverage = all prefixes whose first 8 bits are 10.0.0.0 and whose prefix length is between /16 and /24 inclusive.
Rendered Entries
Rendered entries refer to the exact match conditions that the forwarding plane (or routing protocol policy engine) will evaluate after the prefix list has been parsed.
(address & mask) == network
and
prefixlen >= ge (if ge present) **and** prefixlen <= le (if le present)
Thus the rendered condition is a logical conjunction of three predicates.
Accepted Routes
Accepted routes are the actual routes that survive the prefix-list filter when the routing protocol processes updates.
Comparing Intended and Rendered Prefix List Coverage
Methodology for Comparison
- Extract the configured prefix-list from device configuration.
- Derive the intended set mathematically.
- Compute the rendered predicate as a triple
(base_match, ge, le). - Generate a test vector of candidate prefixes.
- Apply the rendered predicate to each candidate to obtain the accepted set.
- Compare the intended set vs. the accepted set.
Impact of Ge/Le Changes on Prefix List Coverage
Effects of Small Ge/Le Changes
| Change | Effect on Rendered Predicate | Typical Coverage Shift |
|---|---|---|
Decrease ge by 1 | Lowers minimum allowed prefix length → admits longer prefixes (more-specifics) and possibly supernets if the new length < base length. | +1 bit of specificity → roughly doubles the number of candidate prefixes inside the base block. |
Increase ge by 1 | Raises minimum length → excludes the previously allowed longest prefixes; may block intended more-specifics. | -1 bit → removes roughly half of the previously allowed prefixes. |
Admitting More-Specifics Outside the Original Containment Plan
When ge is lowered below the configured base length, the prefix list begins to accept prefixes whose length is shorter than the base network’s length.
Troubleshooting Prefix List Coverage Issues
Identifying and Isolating Problems
- Verify the configured prefix-list.
- Capture the raw routing updates.
- Apply the prefix-list in a test route-map.
- Compare the tag distribution with the expected set.
- If discrepancies appear, isolate the offending entry.
Common Mistakes and Misconfigurations
| Mistake | Symptom | Root Cause |
|---|---|---|
Off-by-one in ge/le | Admission of supernets or exclusion of desired more-specifics | Typo or misunderstanding of inclusive/exclusive bounds |