7.2 Prefix Lists & Route Filters

Prefix Lists & Route Filters

Precise route filtering is essential for scalable enterprise routing architectures. In Junos OS, network engineers control prefix advertisements and routing table ingestion using two primary mechanisms: Prefix Lists and Route Filters. While both tools evaluate IPv4 and IPv6 network prefixes, they differ fundamentally in syntax, flexibility, reusability, and internal evaluation mechanics. Mastering their distinct behaviors and the unique longest-match evaluation rule within policy terms is a vital component of the JNCIS-ENT exam.

---

1. Prefix Lists: Architecture and Exact Matching

A Prefix List is a named, reusable collection of IP addresses configured under the [edit policy-options prefix-list <name>] hierarchy. Once declared, a prefix list can be referenced across multiple routing policies as well as stateless firewall filters.

[edit policy-options]
set prefix-list corp-internal 10.10.0.0/16
set prefix-list corp-internal 10.20.0.0/16
set prefix-list corp-internal 172.16.0.0/12

The Exact-Match Rule of Prefix Lists

By default, a prefix list performs strict exact matching on both the IP address bits and the prefix length:

• If 10.10.0.0/16 is listed in corp-internal, an incoming route for 10.10.0.0/16 matches.
• A more-specific subnet within that address space, such as 10.10.1.0/24 or 10.10.100.0/24, will not match!
• A less-specific supernet, such as 10.0.0.0/8, will not match.

To reference a prefix list in a routing policy term:

[edit policy-options policy-statement export-corp-prefixes]
set term permit-internal from prefix-list corp-internal
set term permit-internal then accept

Dynamic and Apply-Path Prefix Lists

Junos supports dynamic prefix lists populated via system automation, as well as apply-path prefix lists. An apply-path prefix list uses a configuration path query to dynamically extract IP addresses from other areas of the Junos configuration hierarchy, such as physical interface addresses:

[edit policy-options prefix-list router-interfaces]
set apply-path "interfaces <*> unit <*> family inet address <*>"

Whenever a network administrator provisions a new interface or modifies an IP address on the chassis, Junos automatically updates the router-interfaces prefix list without requiring manual policy edits.

---

2. Route Filters: Granular Prefix Evaluation

Unlike prefix lists—which are defined as standalone objects outside of policies—a Route Filter is configured directly inside a policy term under the from route-filter statement. Route filters allow engineers to match a base network prefix alongside a wide array of variable-length subnet qualifiers.

[edit policy-options policy-statement <name> term <term-name>]
set from route-filter <prefix> <match-type> [<action>]

Comprehensive Match Types

Junos OS supports five fundamental route filter match types:

1. exact:

   • Definition: Matches only the exact network address and exact prefix length specified.
   • Syntax: route-filter 10.50.0.0/16 exact
   • Matched: 10.50.0.0/16 only.
   • Rejected: 10.50.1.0/24, 10.50.0.0/17, 10.0.0.0/8.

2. longer:

   • Definition: Matches any subnet strictly longer (more specific) than the specified prefix length that falls completely within the base network address. The base prefix itself is never matched!
   • Syntax: route-filter 10.50.0.0/16 longer
   • Matched: 10.50.1.0/24, 10.50.128.0/17, 10.50.0.0/30.
   • Rejected: 10.50.0.0/16 (exact length), 10.0.0.0/8 (shorter), 192.168.1.0/24.

3. orlonger:

   • Definition: Matches the exact prefix or any subnet strictly longer than the specified prefix length within the network boundary.
   • Syntax: route-filter 10.50.0.0/16 orlonger
   • Matched: 10.50.0.0/16, 10.50.1.0/24, 10.50.100.0/22, 10.50.1.1/32.
   • Rejected: 10.0.0.0/15 (shorter), 172.16.1.0/24.

4. upto /<n>:

   • Definition: Matches the specified base prefix and any longer subnet up to and including prefix length /<n>. The qualifier /<n> must be numerically greater than or equal to the base prefix length.
   • Syntax: route-filter 10.50.0.0/16 upto /24
   • Matched: 10.50.0.0/16, 10.50.0.0/18, 10.50.1.0/24.
   • Rejected: 10.50.1.128/25 (exceeds /24), 10.50.1.1/32 (exceeds /24), 10.0.0.0/8.

5. prefix-length-range /<low>-/<high>:

   • Definition: Matches subnets falling within the base network whose prefix lengths are between /<low> and /<high> inclusive. The base prefix is only matched if its own prefix length falls within the range.
   • Syntax: route-filter 10.50.0.0/16 prefix-length-range /20-/24
   • Matched: 10.50.0.0/20, 10.50.4.0/22, 10.50.1.0/24.
   • Rejected: 10.50.0.0/16 (length 16 is below /20), 10.50.1.0/25 (above /24), 10.0.0.0/8.

---

3. Route Filter Match Type Reference Table

The following table illustrates evaluation results across different match types using 172.16.0.0/16 as the target filter:

---

4. Precedence & Longest-Match Evaluation Order within a Term

A critical trap on the JNCIS-ENT exam involves how Junos evaluates multiple route filters defined inside the same term.

In standard policy processing, Junos evaluates terms sequentially from top to bottom. However, within a single term, Junos does NOT evaluate route filters in the order they appear in the configuration!

The Longest-Match Route Filter Rule: When multiple route filters are configured within the same term, Junos sorts and evaluates them based on longest prefix length (most specific prefix first). If an evaluated route matches multiple overlapping route filters within that term, the filter with the longest prefix length takes precedence.

Repeated Prefixes and the No-Walkup Default

For identical destination prefixes, Junos tests configured match types in order and uses the first applicable match; there is no universal exact > longer > upto > orlonger priority table.

Junos first selects the longest covering prefix, then tests its qualifier. If that qualifier fails, the term fails by default; Junos does not automatically try a shorter covering prefix in the same term. For example, a /24 candidate under a /16 exact entry fails that entry even if a separate /8 orlonger in the same term could match. Separate terms, or explicit supported walkup, can implement the desired fallback. This differs from sequential evaluation across terms.

Practical Evaluation Walkthrough

Consider the following Junos configuration where a broad reject is configured before a specific permit:

[edit policy-options policy-statement filter-traffic term term-1]
set from route-filter 10.0.0.0/8 orlonger reject
set from route-filter 10.100.0.0/16 exact accept

If the router receives prefix 10.100.0.0/16:

• In other operating systems, 10.0.0.0/8 orlonger reject would match first and reject the route.
• In Junos OS, because both filters reside in the same term (term-1), Junos evaluates /16 before /8. The route matches 10.100.0.0/16 exact and is accepted!

Critical Caveat: If these route filters were placed in different terms (e.g., term A containing /8 orlonger reject and term B containing /16 exact accept), sequential term evaluation applies. term A would be evaluated first, and 10.100.0.0/16 would be rejected. The longest-match evaluation rule applies strictly within a single term.

---

5. In-Line Route Filter Actions and Policy Optimization

Route filters support in-line actions directly on the filter statement. This enables engineers to compress complex policy logic into a single term rather than authoring dozens of individual terms:

[edit policy-options policy-statement edge-transit term filter-subnets]
set from route-filter 192.168.0.0/16 orlonger reject
set from route-filter 192.168.10.0/24 exact accept
set from route-filter 192.168.20.0/24 exact accept
set from route-filter 0.0.0.0/0 exact accept

In this configuration, all four route filters reside within filter-subnets. Junos automatically sorts /24 ahead of /16, and /16 ahead of /0. The subnets 192.168.10.0/24 and 192.168.20.0/24 are accepted; all other subnets within 192.168.0.0/16 are rejected; and the default route 0.0.0.0/0 is accepted.

Official references checked 2026-10-18: Route-filter precedence, Walkup behavior.