Configuring Route Lists for Use in Routing Policy Match Conditions
A route list is a collection of destination prefixes. When specifying a prefix, you can specify an exact match with a particular route or a less precise match. You can configure either a common action that applies to the entire list or an action associated with each prefix.
 | Note: Because the configuration of route lists includes setting up prefixes and prefix lengths, we strongly recommend that you have a thorough understanding of IP addressing, including supernetting, before proceeding with the configuration. It is also important to understand how a route list is evaluated, particularly if the route list includes multiple route-filter options in a from statement. We strongly recommend that you read How Route Lists Are Evaluated in Routing Policy Match Conditions before proceeding with the configuration. Not fully understanding the evaluation process could result in faulty configuration and unexpected results. |
This section discusses the following topics:
Configuring Route Lists
To configure a route list, include one or more route-filter or source-address-filter statements at the [edit policy-options policy-statement policy-name term term-name from] hierarchy level:
The route-filter option is typically used to match prefixes of any type except for unicast source addresses.
The source-address-filter option is typically used to match unicast source addresses in multiprotocol BGP (MBGP) and Multicast Source Discovery Protocol (MSDP) environments.
source-prefix is the IPv4 or IPv6 prefix specified as prefix/prefix-length. If you omit prefix-length for an IPv4 prefix, the default is /32. If you omit prefix-length for an IPv6 prefix, the default is /128. Prefixes specified in a from statement must be either all IPv4 addresses or all IPv6 addresses.
match-type is the type of match to apply to the destination prefix. It can be one of the match types listed in Table 1. For examples of the match types and the results when presented with various routes, see Table 2.
actions is the action to take if the destination prefix matches. It can be one or more of the actions listed in Configuring Flow Control Actions and Configuring Actions That Manipulate Route Characteristics.
In route lists, you can specify actions in two ways:
- In the route-filter or source-address-filter option—These actions are taken immediately after a match occurs, and the then statement is not evaluated.
- In the then statement—These actions are taken after a match occurs and if an action is not specified in the route-filter or source-address-filter option.
The upto and prefix-length-range match types are similar in that both specify the most-significant bits and provide a range of prefix lengths that can match. The difference is that upto allows you to specify an upper limit only for the prefix length range, whereas prefix-length-range allows you to specify both lower and upper limits.
For more examples of these route list match types, see Route List Examples.
Table 1: Route List Match Types for a Prefix List
Match Type | Match Condition |
|---|---|
exact | The route shares the same most-significant bits (described by prefix-length), and prefix-length is equal to the route’s prefix length. |
longer | The route shares the same most-significant bits (described by prefix-length), and prefix-length is greater than the route’s prefix length. |
orlonger | The route shares the same most-significant bits (described by prefix-length), and prefix-length is equal to or greater than the route’s prefix length. |
prefix-length-range prefix-length2-prefix-length3 | The route shares the same most-significant bits (described by prefix-length), and the route’s prefix length falls between prefix-length2 and prefix-length3, inclusive. |
through destination-prefix | All the following are true:
You do not use the through match type in most routing policy configurations. (For an example, see Example: Rejecting Routes from Specific Hosts.) |
upto prefix-length2 | The route shares the same most-significant bits (described by prefix-length) and the route’s prefix length falls between prefix-length and prefix-length2. |
Table 2: Match Type Examples
Prefix | 192.168/16 exact | 192.168/16 longer | 192.168/16 orlonger | 192.168/16 upto /24 | 192.168/16 through 192.168.16/20 | 192.168/16 prefix length range |
|---|---|---|---|---|---|---|
10.0.0.0/8 | – | – | – | – | – | – |
192.168.0.0/16 | Match | – | Match | Match | Match | – |
192.168.0.0/17 | – | Match | Match | Match | Match | – |
192.168.0.0/18 | – | Match | Match | Match | Match | Match |
192.168.0.0/19 | – | Match | Match | Match | Match | Match |
192.168.4.0/24 | – | Match | Match | Match | – | – |
192.168.5.4/30 | – | Match | Match | – | – | – |
192.168.12.4/30 | – | Match | Match | – | – | – |
192.168.12.128/32 | – | Match | Match | – | – | – |
192.168.16.0/20 | – | Match | Match | Match | Match | Match |
192.168.192.0/18 | – | Match | Match | Match | – | Match |
192.168.224.0/19 | – | Match | Match | Match | – | Match |
10.169.1.0/24 | – | – | – | – | – | – |
10.170.0.0/16 | – | – | – | – | – | – |
How Route Lists Are Evaluated in Routing Policy Match Conditions
During route list evaluation, the policy framework software compares each route’s source address with the destination prefixes in the route list. The evaluation occurs in two steps:
- The policy framework software performs a longest-match lookup, which means that the software searches
for the prefix in the list with the longest length.
The longest-match lookup considers the prefix and prefix length only and not the match type. The following sample route list illustrates this point:
from {route-filter 192.168.0.0/14 upto /24 reject;route-filter 192.168.0.0/15 exact;}then accept;The longest match is the second route-filter, 192.168.0.0/15, which is based on prefix and prefix length only.
- Once an incoming route matches a prefix (longest
first), the following actions occur:
- The route filter stops evaluating other prefixes, even if the match type fails.
- The software examines the match type and action associated with that prefix.
In Step 1, if route 192.168.1.0/24 were evaluated, it would fail to match. It matches the longest prefix of 192.168.0.0/15, but it does not match exact. The route filter is finished because it matched a prefix, but the result is a failed match because the match type failed.
If a match occurs, the action specified with the prefix is taken. If an action is not specified with the prefix, the action in the then statement is taken. If neither action is specified, the software evaluates the next term or routing policy, if present, or takes the accept or reject action specified by the default policy. For more information about the default routing policies, see Default Routing Policies and Actions.
| Note: If you specify multiple prefixes in the route list, only one prefix needs to match for a match to occur. The route list matching is effectively a logical OR operation. |
If a match does not occur, the software evaluates the next term or routing policy, if present, or takes the accept or reject action specified by the default policy.
For example, compare the prefix 192.168.254.0/24 against the following route list:
The prefix 192.168.254.0/23 is determined to be the longest prefix. When the software evaluates 192.168.254.0/24 against the longest prefix, a match occurs (192.168.254.0/24 is a subset of 192.168.254.0/23). Because of the match between 192.168.254.0/24 and the longest prefix, the evaluation continues. However, when the software evaluates the match type, a match does not occur between 192.168.254.0/24 and 192.168.254.0/23 exact. The software concludes that the term does not match and goes on to the next term or routing policy, if present, or takes the accept or reject action specified by the default policy.
How Prefix Order Affects Route List Evaluation
The order in which the prefixes are specified (from top to bottom) typically does not matter, because the policy framework software scans the route list looking for the longest prefix during evaluation. An exception to this rule is when you use the same destination prefix multiple times in a list. In this case, the order of the prefixes is important, because the list of identical prefixes is scanned from top to bottom, and the first match type that matches the route applies.
In the following example, different match types are specified for the same prefix. The route 0.0.0.0/0 would be rejected, the route 0.0.0.0/8 would be marked with next-hop self, and the route 0.0.0.0/25 would be rejected.
Common Configuration Problem with the Longest-Match Lookup
A common problem when defining a route list is including a shorter prefix that you want to match with a longer, similar prefix in the same list. For example, imagine that the prefix 192.168.254.0/24 is compared against the following route list:
Because the policy framework software performs longest-match lookup, the prefix 192.168.254.0/23 is determined to be the longest prefix. An exact match does not occur between 192.168.254.0/24 and 192.168.254.0/23 exact. The software determines that the term does not match and goes on to the next term or routing policy, if present, or takes the accept or reject action specified by the default policy. (For more information about the default routing policies, see Default Routing Policies and Actions.) The shorter prefix 192.168.0.0/16 orlonger that you wanted to match is inadvertently ignored.
One solution to this problem is to remove the prefix 192.168.0.0/16 orlonger from the route list in this term and move it to a previous term where it is the only prefix or the longest prefix in the list.
Route List Examples
The examples in this section show only fragments of routing policies. Normally, you would combine these fragments with other terms or routing policies.
In all examples, remember that the following actions apply to nonmatching routes:
- Evaluate next term, if present.
- Evaluate next policy, if present.
- Take the accept or reject action specified by the default policy. For more information about the default routing policies, see Default Routing Policies and Actions.
The following examples show how to configure route lists for various purposes:
- Example: Rejecting Routes with Specific Destination Prefixes and Mask Lengths
- Example: Rejecting Routes with a Mask Length Greater than Eight
- Example: Rejecting Routes with Mask Length Between 26 and 29
- Example: Rejecting Routes from Specific Hosts
- Example: Accepting Routes with a Defined Set of Prefixes
- Example: Rejecting Routes with a Defined Set of Prefixes
- Example: Rejecting Routes with Prefixes Longer than 24 Bits
- Example: Rejecting PIM Multicast Traffic Joins
- Example: Rejecting PIM Traffic
Example: Rejecting Routes with Specific Destination Prefixes and Mask Lengths
Reject routes with a destination prefix of 0.0.0.0 and a mask length from 0 through 8, and accept all other routes:
Example: Rejecting Routes with a Mask Length Greater than Eight
Reject routes with a mask of /8 and greater (that is, /8, /9, /10, and so on) that have the first 8 bits set to 0 and accept routes less than 8 bits in length:
Example: Rejecting Routes with Mask Length Between 26 and 29
Reject routes with the destination prefix of 192.168.10/24 and a mask between /26 and /29 and accept all other routes:
Example: Rejecting Routes from Specific Hosts
Reject a range of routes from specific hosts, and accept all other routes:
You do not use the through match type in most routing policy configurations. You should think of through as a tool to group a contiguous set of exact matches. For example, instead of specifying four exact matches:
You could represent them with the following single match:
Example: Accepting Routes with a Defined Set of Prefixes
Explicitly accept a limited set of prefixes (in the first term) and reject all others (in the second term):
Example: Rejecting Routes with a Defined Set of Prefixes
Reject a few groups of prefixes, and accept the remaining prefixes:
Example: Rejecting Routes with Prefixes Longer than 24 Bits
Reject all prefixes longer than 24 bits. You would install this routing policy in a sequence of routing policies in an export statement. The first term in this filter passes on all routes with a prefix length of up to 24 bits. The second, unnamed term rejects everything else.
If, in this example, you were to specify route-filter 0.0.0.0/0 upto /24 accept, matching prefixes would be accepted immediately and the next routing policy in the export statement would never get evaluated.
If you were to include the then reject statement in the term acl20, prefixes greater than 24 bits would never get rejected because the policy framework software, when evaluating the term, would move on to evaluating the next statement before reaching the then reject statement.
Example: Rejecting PIM Multicast Traffic Joins
Configure a routing policy for rejecting Protocol Independent Multicast (PIM) multicast traffic joins for a source destination prefix from a neighbor:
Example: Rejecting PIM Traffic
Configure a routing policy for rejecting PIM traffic for a source destination prefix from an interface:
The following routing policy qualifiers apply to PIM:
- interface—Interface over which a join is received
- neighbor—Source from which a join originates
- route-filter—Group address
- source-address-filter—Source address for which to reject a join
For more information about importing a PIM join filter in a PIM protocol definition, see the Junos Multicast Protocols Configuration Guide.
