Understanding Prefix Lists for Use in Routing Policy Match Conditions
A prefix list is a named list of IP addresses. You can specify an exact match with incoming routes and (optionally) apply a common action to all matching prefixes in the list.
Suppose, for example, that you configure the following prefix list:
prefix-list bgp179 { apply-path "protocols bgp group <*> neighbor <*>"; }
This works well when all neighbors on the device are in the same address family.
When the neighbors are in different address families, for example when both IPv4 and IPv6 neighbors are configured, you can use a prefix list as follows:
prefix-list IPV4-BGP-NEIGHBORS { apply-path "protocols bgp group <*> neighbor <*.*.*.*>"; } prefix-list IPV6-BGP-NEIGHBORS { apply-path "protocols bgp group <*> neighbor <*:*:*>"; }
One prefix list matches IPv4 addresses. The other matches IPv6 addresses. You can run
the show configuration policy-options prefix-list prefix-list name | display inheritance
command to verify the configuration.
A prefix list functions like a route list that contains multiple instances of the exact
match type only. The differences between these two extended match conditions
are summarized in Table 1.
Feature |
Prefix List |
Route Lists |
---|---|---|
Action |
Can specify action in a |
Can specify action that is applied to a particular prefix in a |
For information about configuring route lists, see Understanding Route Filters for Use in Routing Policy Match Conditions.
This section includes the following information:
Configuring Prefix Lists
You can create a named prefix list and include it in a routing policy with the prefix-list
match condition (described in Routing Policy Match Conditions).
To define a prefix list, include the prefix-list
statement:
[edit policy-options] prefix-list prefix-list-name { apply-path path; ip-addresses; }
You can use the apply-path
statement to include all prefixes (and their associated
network mask) pointed to by a defined path, or you can specify one or more addresses, or both.
To include a prefix list in a routing policy, specify the prefix-list
match
condition in the from
statement at the [edit policy-options policy-statement policy-name term term-name]
hierarchy level:
[edit policy-options policy-statement policy-name term term-name] from { prefix-list prefix-list-name; } then actions;
name
identifies the prefix list. It can contain letters,
numbers, and hyphens (-) and can be up to 127 bytes long. To include spaces in the name, enclose
the entire name in quotation marks (“ ”).
ip-addresses
are the IPv4 or IP version 6 (IPv6)
prefixes 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. You cannot apply actions to individual
prefixes in the list.
You can specify the same prefix list in the from
statement of multiple routing
policies or firewall filters. For information about firewall filters, see Guidelines for Configuring Firewall Filters and Guidelines for Applying Standard Firewall Filters.
Use the apply-path
statement to configure a prefix list comprising all IP
prefixes pointed to by a defined path. This eliminates most of the effort required to maintain
a group prefix list.
The path consists of elements separated by spaces. Each element matches a configuration keyword or an identifier, and you can use wildcards to match more than one identifier. Wildcards must be enclosed in angle brackets, for example, <*>.
You cannot add a path element, including wildcards, after a leaf statement in the apply-path
statement. Path elements, including wildcards, can only be used after a
container statement.
When you use apply-path
to define a prefix list, you can also use the same
prefix list in a policy statement.
For examples of configuring a prefix list, see Example: Configuring Routing Policy Prefix Lists.
How Prefix Lists Are Evaluated in Routing Policy Match Conditions
During prefix list evaluation, 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 order in which you specify the prefixes, from top to bottom, does not matter. The software then compares a route’s source address to the longest prefix.
You can use prefix list qualifiers for prefixes contained in a prefix list by configuring a prefix list filter. For more information, see Configuring Prefix Lists for Use in Routing Policy Match Conditions.
If a match occurs, the evaluation of the current term continues. If a match does not occur, the evaluation of the current term ends.
If you specify multiple prefixes in the prefix list, only one prefix must match for a match to occur. The prefix list matching is effectively a logical OR operation.
Configuring Prefix List Filters
A prefix list filter allows you to apply prefix list qualifiers to a list of prefixes within a prefix list. The prefixes within the list are evaluated using the specified qualifiers. You can configure multiple prefix list filters under the same policy term.
To configure a prefix list filter, include the prefix-list-filter
statement
at the [edit policy-options policy-statement policy-name from]
hierarchy level:
[edit policy-options policy-statement policy-name] from { prefix-list-filter prefix-list-name match-type actions; }
The prefix-list-name
option is the name of the prefix
list to be used for evaluation. You can specify only one prefix list.
The match-type
option is the type of match to apply
to the prefixes in the prefix list. It can be one of the match types listed in Table 2.
The actions
option is the action to take if the prefix
list matches. It can be one or more of the actions listed in Configuring Flow Control Actions and Configuring Actions That Manipulate
Route Characteristics.
Match Type |
Match Condition |
---|---|
|
The route shares the same most-significant bits (described by |
|
The route shares the same most-significant bits (described by |
|
The route shares the same most-significant bits (described by |