Understanding Route Filters for Use in Routing Policy Match Conditions
A route filter is a collection of match prefixes. When specifying a match 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.
Because the configuration of route filters includes setting up prefixes and prefix lengths, before proceeding with the configuration you should have a thorough understanding of IP addressing, including supernetting, and how route filters are evaluated (explained here: How Route Filters Are Evaluated in Routing Policy Match Conditions).
This section discusses the following topics:
Radix Trees
To understand the operation of a route filter, you need to be familiar with a device used for binary number matching known as a radix tree (sometimes called a patricia trie or radix trie). A radix tree uses binary lookups to identify IP addresses (routes). Remember that an IP address is a 32-bit number represented in a dotted decimal format for easy comprehension by humans. These 8-bit groupings can each have a value between 0 and 255. A radix tree can be a graphical representation of these binary numbers.
In Figure 1, the radix tree starts with no configured value (starts at 0) and is at the leftmost position of the binary IP address. This is shown as 0/0, which is often referred to as the default route.
Because this is binary, each bit can have only one of two possible values—a 0 or a 1. Moving down the left branch represents a value of 0, while moving to the right represents a value of 1. The first step is shown in Figure 2. At the first position, the first octet of the IP address has a value of 00000000 or 10000000—a 0 or 128, respectively. This is represented in Figure 2 by the values 0/1 and 128/1.
The second step is shown in Figure 3. This second level of the tree has four possible binary values for the first octet: 00000000, 01000000, 10000000, and 11000000. These decimal values of 0, 64, 128, and 192 are represented by the IP addresses of 0/2, 64/2, 128/2, and 192/2 on the radix tree.
This step-by-step process continues for 33 total levels to represent every possible IP address.
The radix tree structure is helpful when locating a group of routes that all share the same most significant bits. Figure 4 shows the point in the radix tree that represents the 192.168.0.0/16 network. All of the routes that are more specific than 192.168.0.0/16 are shown in the highlighted section.
Configuring Route Filters
The topic, Configuring Route Filters, describes default Junos OS behavior. The walkup feature, which is not covered in this topic, alters the evaluation results discussed in this topic by allowing the router to consider shorter match conditions configured within the same term. See Walkup for Route Filters Overview for details.
To configure a route filter, include one or more route-filter
or source-address-filter
statements:
[edit policy-options policy-statement policy-name term term-name from] route-filter destination-prefix match-type { actions; }
The route-filter
option is typically used to match an incoming route address
to destination match prefixes of any type except for unicast source addresses.
The destination-prefix
address is the IP version 4 (IPv4)
or IP version 6 (IPv6) address 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.
The source-address-filter
option is typically used to match an incoming route
address to unicast source addresses in multiprotocol BGP (MBGP) and Multicast Source Discovery
Protocol (MSDP) environments.
source-address-filter source-prefix match-type { actions; }
source-prefix
address is the IPv4 or IPv6 address prefix
specified as prefix/prefix-length
. If
you omit prefix-length
for an IPv4 prefix, the default is
/32prefix-length
. 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 source
or 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
are the actions to take if a route address matches
the criteria specified for a destination match prefix (specified as part of a route-filter
option) or for a source match prefix (specified as part of a destination-address-filter
option). The actions can consist of one or more of the actions described in Actions in Routing Policy Terms.
In a route filter you can specify actions in two ways:
In the
route-filter
orsource-address-filter
option—These actions are taken immediately after a match occurs, and thethen
statement is not evaluated.In the
then
statement—These actions are taken after a match occurs but no actions are specified for theroute-filter
orsource-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 filter match types, see Route Filter Examples.
Match Type |
Match Criteria |
---|---|
|
All of the following are true:
Note:
The The When the longest-match lookup is performed on a route filter, the lookup evaluates an For more information about this route filter match type, see How an Address Mask Match Type Is Evaluated. For example configurations showing route filters that contain the |
|
All of the following are true:
|
|
All of the following are true:
|
|
All of the following are true:
|
|
All of the following are true:
|
|
All of the following are true:
You do not use the |
|
All of the following are true:
|
Figure 5 shows the detailed radix tree for the route 192.168.0.0/16.
Figure 6 and Table 2 demonstrate the operation of the various route filter match types.
Prefix |
192.168/16 exact |
192.168/16 longer |
192.168/16 orlonger |
192.168/16 upto /24 |
192.168/16 prefix-length-range/18 – /20 |
192.168/16 through192.168.16/20 |
192.168/19 address-mask255.255.0.0 |
---|---|---|---|---|---|---|---|
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 |
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 |
– |
Match |
10.169.1.0/24 |
– |
– |
– |
– |
– |
– |
– |
10.170.0.0/16 |
– |
– |
– |
– |
– |
– |
– |
How Route Filters Are Evaluated in Routing Policy Match Conditions
During route filter evaluation, the policy framework software compares each route’s source address with the destination prefixes in the route filter. 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
andprefix-length
components of the configured match prefix only, and not thematch-type
component. The following sample route filter 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 for the candidate route 192.168.1.0/24 is the second route-filter, 192.168.0.0/15, which is based on prefix and prefix length only.
When 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.
When a route source address is evaluated against a match criteria that uses the address-mask
match type, both steps of the evaluation include the configured netmask
value. For more information, see How an Address Mask Match Type Is Evaluated.
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.
If you specify multiple prefixes in the route filter, only one prefix needs to match for a match to occur. The route filter 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 filter:
route-filter 192.168.0.0/16 orlonger; route-filter 192.168.254.0/23 exact;
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.
The walkup feature allows terms with multiple route filters to “walk-up” the evaluation process to include less-specific routes as well as the longest match. In other words, enabling walkup changes the default behavior from “if one fails, then the term fails” to “if one matches, then the term matches.” For more information about the walkup feature, see Walkup for Route Filters Overview.
- How Prefix Order Affects Route Filter Evaluation
- How an Address Mask Match Type Is Evaluated
- Common Configuration Problem with the Longest-Match Lookup
How Prefix Order Affects Route Filter 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 filter 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.
The walkup feature allows terms with multiple route filters to “walk-up” the evaluation process to include less-specific routes as well as the longest match. In other words, enabling walkup changes the default behavior from “if one fails, then the term fails” to “if one matches, then the term matches.” For more information about the walkup feature, see Walkup for Route Filters Overview.
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.
route-filter 0.0.0.0/0 upto /7 reject; route-filter 0.0.0.0/0 upto /24 next-hop self; route-filter 0.0.0.0/0 orlonger reject;
How an Address Mask Match Type Is Evaluated
The address-mask
routing policy match type enables you to match incoming
IPv4 or IPv6 route addresses on a configured netmask value in addition to the length of a
configured destination match prefix. During route filter evaluation, an address-mask
match type is processed differently from other routing policy match types, taking into consideration
the configured netmask value:
When a longest-match lookup evaluates an
address-mask
routing policy match type, theprefix-length
component of the configured match prefix is not considered. Instead, the lookup considers the number of contiguous high-order bits set in the configured netmask value.When an incoming IPv4 or IPv6 route address is evaluated against a route filter match criteria that uses the
address-mask
routing policy match type, the match succeeds if the following values are identical:The bit-wise logical AND of the configured netmask value and the incoming IPv4 or IPv6 route address
The bit-wise logical AND of the configured netmask value and the configured destination match prefix
For an example configuration of a route filter that contains two address-mask
match types, see Evaluation of an Address Mask Match Type with Longest-Match Lookup.
Common Configuration Problem with the Longest-Match Lookup
A common problem when defining a route filter 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 filter:
route-filter 192.168.0.0/16 orlonger; route-filter 192.168.254.0/23 exact;
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.) 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 filter in this term and move it to another term where it is the only prefix or the longest prefix in the list.
Another solution is to enable the walkup feature. See Walkup for Route Filters Overview for details.
Route Filter 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
orreject
action specified by the default policy. For more information about the default routing policies, see Default Routing Policies.
The following examples show how to configure route filters for various purposes:
- Rejecting Routes with Specific Destination Prefixes and Mask Lengths
- Rejecting Routes with a Mask Length Greater than Eight
- Rejecting Routes with Mask Length Between 26 and 29
- Rejecting Routes from Specific Hosts
- Accepting Routes with a Defined Set of Prefixes
- Rejecting Routes with a Defined Set of Prefixes
- Rejecting Routes with Prefixes Longer than 24 Bits
- Rejecting PIM Multicast Traffic Joins
- Rejecting PIM Traffic
- Accepting Incoming IPv4 Routes by Applying an Address Mask to the Route Address and the Destination Match Prefix
- Accepting Incoming IPv4 Routes with Similar Patterns But Different Prefix Lengths
- Evaluation of an Address Mask Match Type with Longest-Match Lookup
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:
[edit] policy-options { policy-statement policy-statement from-hall2 { term 1 { from { route-filter 0.0.0.0/0 upto /8 reject; } } then accept; } }
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:
[edit] policy-options { policy-statement from-hall3 { term term1 { from { route-filter 0/0 upto /7 accept; route-filter 0/8 orlonger; } then reject; } } }
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:
[edit] policy-options { policy-statement from-customer-a { term term1 { from { route-filter 192.168.10/24 prefix-length-range /26–/29 reject; } then accept; } } }
Rejecting Routes from Specific Hosts
Reject a range of routes from specific hosts, and accept all other routes:
[edit] policy-options { policy-statement hosts-only { from { route-filter 10.125.0.0/16 upto /31 reject; route-filter 0/0; } then accept; } }
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:
from route-filter 0.0.0.0/1 exact from route-filter 0.0.0.0/2 exact from route-filter 0.0.0.0/3 exact from route-filter 0.0.0.0/4 exact
You could represent them with the following single match:
from route-filter 0.0.0.0/1 through 0.0.0.0/4
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):
policy-options { policy-statement internet-in { term 1 { from { route-filter 192.168.231.0/24 exact accept; route-filter 192.168.244.0/24 exact accept; route-filter 192.168.198.0/24 exact accept; route-filter 192.168.160.0/24 exact accept; route-filter 192.168.59.0/24 exact accept; } } term 2 { then { reject; } } }
Rejecting Routes with a Defined Set of Prefixes
Reject a few groups of prefixes, and accept the remaining prefixes:
[edit policy-options] policy-statement drop-routes { term 1{ from { # first, reject a number of prefixes: route-filter default exact reject; # reject 0.0.0.0/0 exact route-filter 0.0.0.0/8 orlonger reject; # reject prefix 0, mask /8 or longer route-filter 10.0.0.0/8 orlonger reject; # reject loopback addresses } route-filter 10.105.0.0/16 exact { # accept 10.105.0.0/16 as-path-prepend “1 2 3”; accept; } route-filter 192.0.2.0/24 orlonger reject; # reject test network packets route-filter 172.16.233.0/3 orlonger reject; # reject multicast and higher route-filter 0.0.0.0/0 upto /24 accept; # accept everything up to /24 route-filter 0.0.0.0/0 orlonger accept; # accept everything else } } } }
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.
[edit policy-options] policy-statement 24bit-filter { term acl20 { from { route-filter 0.0.0.0/0 upto /24; } then next policy; } then reject; }
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.
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:
[edit] policy-options { policy-statement join-filter { from { neighbor 10.14.12.20; source-address-filter 10.83.0.0/16 orlonger; } then reject; } }
Rejecting PIM Traffic
Configure a routing policy for rejecting PIM traffic for a source destination prefix from an interface:
[edit] policy-options { policy-statement join-filter { from { interface so-1/0/0.0; source-address-filter 10.83.0.0/16 orlonger; } then reject; } }
The following routing policy qualifiers apply to PIM:
interface
—Interface over which a join is receivedneighbor
—Source from which a join originatesroute-filter
—Group addresssource-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 OS Multicast Protocols User Guide.
Accepting Incoming IPv4 Routes by Applying an Address Mask to the Route Address and the Destination Match Prefix
Accept incoming IPv4 routes with a destination prefix of 10.1.0/24 and the third byte an even number from 0 to 14, inclusive:
[edit] policy-options { policy-statement from_customer_a { term term_1 { from { route-filter 10.1.0.0/24 address-mask 255.255.241.0; } then { ... reject; } } } }
The route filter in routing policy term term_1
matches the following incoming
IPv4 route addresses:
10.1.0.0/24
10.1.2.0/24
10.1.4.0/24
10.1.6.0/24
10.1.8.0/24
10.1.10.0/24
10.1.12.0/24
10.1.14.0/24
The bit-wise logical AND of the netmask value and the candidate route address must match the bit-wise logical AND of the netmask value and the match prefix address. That is, where the netmask bit pattern 255.255.241.0 contains a set bit, the incoming IPv4 route address being evaluated must match the value of the corresponding bit in the destination prefix address 10.1.0.0/24.
The first two bytes of the netmask value are binary 1111 1111 1111 1111, which means that a candidate route address will fail the match if the first two bytes are not 10.1.
The third byte of the netmask value is binary 1111 0001, which means that a candidate route address will fail the match if the third byte is greater than 15 (decimal), an odd number, or both.
The prefix length of the match prefix address is 24 (decimal), which means that a candidate route address will fail the match if its prefix length is not exactly 24.
As an example, suppose that the candidate route address being tested in the policy is 10.1.8.0/24 (binary 0000 1010 0000 0001 0000 1000).
When the netmask value is applied to this candidate route address, the result is binary 0000 1010 0000 0001 0000 0000.
When the netmask value is applied to the configured destination prefix address, the result is also binary 0000 1010 0000 0001 0000 0000.
Because the results of both AND operations are the same, the match continues to the second match criteria.
Because the prefix lengths of the candidate address and the configured destination prefix address are the same (24 bits), the match succeeds.
As another example, suppose that the candidate route address being tested in the policy is 10.1.3.0/24 (binary 0000 1010 0000 0001 0000 0011).
When the netmask value is applied to this candidate route address, the result is binary 0000 1010 0000 0001 0000 0001.
However, when the netmask value is applied to the configured destination prefix address, the result is binary 0000 1010 0000 0001 0000 0000.
Because the results of the two AND operations are different (in the third byte), the match fails.
Accepting Incoming IPv4 Routes with Similar Patterns But Different Prefix Lengths
Accept incoming IPv4 route addresses of the form 10.*.1/24 or 10.*.1.*/32:
[edit] policy-options { policy-statement from_customer_b { term term_2 { from { route-filter 10.0.1.0/24 address-mask 255.0.255.0; route-filter 10.0.1.0/32 address-mask 255.0.255.0; } then { ... reject; } } } }
The route filter match criteria 10.0.1.0/24 address-mask 255.0.255.0
matches
an incoming IPv4 route address of the form 10.*.1/24. The route’s prefix length must
be exactly 24 bits long, and any value is acceptable in the second byte.
The route filter match criteria 10.0.1.0/32 address-mask 255.0.255.0
matches
an incoming IPv4 route address of the form 10.*.1.*/32. The route’s prefix length must
be exactly 32 bits long, and any value is acceptable in the second byte and the fourth
byte.
Evaluation of an Address Mask Match Type with Longest-Match Lookup
This example illustrates how a longest-match lookup evaluates a route filter that contains
two address-mask
match types. Consider the route filter configured in the routing
policy term term_3
below:
[edit] policy-options { policy-statement from_customer_c { term term_3 { from { route-filter 10.0.1.0/24 address-mask 255.0.255.0; route-filter 10.0.2.0/24 address-mask 255.240.255.0; } then { ... } } } }
Suppose that the incoming IPv4 route source address 10.1.1.0/24 is tested against the
route filter configured in the policy term term_3
:
The longest-match lookup tree for routing policy term
term_3
contains two match prefixes: one prefix for10.0.1.0/24 address-mask 255.0.255.0
and one prefix for10.0.2.0/24 address-mask 255.240.255.0
. When searching the tree for the longest-prefix match for a candidate, the longest-match lookup considers the number of contiguous high-order bits in the configurednetmask-value
instead of the length of the configureddestination-prefix
:For the first route filter match criteria, the longest-match lookup entry is 10.0.0.0/8 because the netmask value contains 8 contiguous high-order bits.
For second route filter match criteria, the longest-match lookup entry is 10.0.0.0/12 because the netmask value contains 12 contiguous high-order bits.
For the candidate route address 10.1.1.0/24, the longest-match lookup returns the tree entry 10.0.0.0/12, which is corresponds to the route filter match criteria
10.0.2.0/24 address-mask 255.240.255.0
.Now that the longest-match prefix in
term_3
has been identified for the candidate route address, the candidate route address is evaluated against the route filter match criteria10.0.2.0/24 address-mask 255.240.255.0
:To test the incoming IPv4 route address 10.1.1.0/24, the netmask value 255.240.255.0 is applied to 10.1.1.0/24. The result is 10.0.1.0.
To test the configured destination prefix address 10.0.2.0/24, the netmask value 255.240.255.0 is applied to 10.0.2.0/24. The result is 10.0.2.0.
Because the results are different, the route filter match fails. No actions, whether specified with the match criteria or with the
then
statement, are taken. The incoming IPv4 route address is not evaluated against any other match criteria.