Skip to content
LinkState
Go back

ge and le edits that reopen aggregate holes

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:

VendorCommand ModeBasic SyntaxExample
Cisco IOS/IOS-XE/IOS-XR`ip prefix-list [seq ] {permitdeny} / [ge ] [le ]`ip prefix-list PL-ACC seq 10 permit 10.0.0.0/8 ge 16 le 24
Juniper Junospolicy-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 seq {permitdeny} / [ge ] [le ]`identical to Cisco
Nokia SR OSconfigure 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

  1. Extract the configured prefix-list from device configuration.
  2. Derive the intended set mathematically.
  3. Compute the rendered predicate as a triple (base_match, ge, le).
  4. Generate a test vector of candidate prefixes.
  5. Apply the rendered predicate to each candidate to obtain the accepted set.
  6. Compare the intended set vs. the accepted set.

Impact of Ge/Le Changes on Prefix List Coverage

Effects of Small Ge/Le Changes

ChangeEffect on Rendered PredicateTypical Coverage Shift
Decrease ge by 1Lowers 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 1Raises 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

  1. Verify the configured prefix-list.
  2. Capture the raw routing updates.
  3. Apply the prefix-list in a test route-map.
  4. Compare the tag distribution with the expected set.
  5. If discrepancies appear, isolate the offending entry.

Common Mistakes and Misconfigurations

MistakeSymptomRoot Cause
Off-by-one in ge/leAdmission of supernets or exclusion of desired more-specificsTypo or misunderstanding of inclusive/exclusive bounds

Share this post on:

Previous Post
When ndots turns service discovery into a DNS storm
Next Post
Aging out zombie inventory with last-seen signals