Supported Platforms
Related Documentation
- ACX, M, MX, PTX, QFX, SRX, T Series
- Understanding Prefix Lists for Use in Routing Policy Match Conditions
- Understanding Route Filters for Use in Routing Policy Match Conditions
Routing Policy Match Conditions
Each term in a routing policy can include two statements, from and to, to define the conditions that a route must match for the policy to apply:
In the from statement, you define the criteria that an incoming route must match. You can specify one or more match conditions. If you specify more than one, they all must match the route for a match to occur.
The from statement is optional. If you omit the from and the to statements, all routes are considered to match.
In export policies, omitting the from statement from a routing policy term might lead to unexpected results.
In the to statement, you define the criteria that an outgoing route must match. You can specify one or more match conditions. If you specify more than one, they all must match the route for a match to occur. You can specify most of the same match conditions in the to statement that you can in the from statement. In most cases, specifying a match condition in the to statement produces the same result as specifying the same match condition in the from statement.
The to statement is optional. If you omit both the to and the from statements, all routes are considered to match.
Table 1 summarizes key routing policy match conditions.
Table 1: Summary of Key Routing Policy Match Conditions
Match Condition | Description |
---|---|
aggregate-contributor | Matches routes that are contributing to a configured aggregate. This match condition can be used to suppress a contributor in an aggregate route. |
area area-id | Matches a route learned from the specified OSPF area during the exporting of OSPF routes into other protocols. |
as-path name | Matches the name of the path regular expression of an autonomous systems (AS). BGP routes whose AS path matches the regular expression are processed. |
color preference | Matches a color value. You can specify preference values that are finer-grained than those specified in the preference match conditions. The color value can be a number from 0 through 4,294,967,295 (232 – 1). A lower number indicates a more preferred route. |
community | Matches the name of one or more communities. If you list more than one name, only one name needs to match for a match to occur. (The matching is effectively a logical OR operation.) |
external [type metric-type] | Matches external OSPF routes, including routes exported from one level to another. In this match condition, type is an optional keyword. The metric-type value can be either 1 or 2. When you do not specify type, this condition matches all external routes. |
interface interface-name | Matches the name or IP address of one or more router interfaces. Use this condition with protocols that are interface-specific. For example, do not use this condition with internal BGP (IBGP). Depending on where the policy is applied, this match condition matches routes learned from or advertised through the specified interface. |
internal | Matches a routing policy against the internal flag for simplified next-hop self policies. |
level level | Matches the IS-IS level. Routes that are from the specified level or are being advertised to the specified level are processed. |
local-preference value | Matches a BGP local preference attribute. The preference value can be from 0 through 4,294,967,295 (232 – 1). |
metric metric metric2 metric | Matches a metric value. The metric value corresponds to the multiple exit discriminator (MED), and metric2 corresponds to the IGP metric if the BGP next hop runs back through another route. |
neighbor address | Matches the address of one or more neighbors (peers). For BGP export policies, the address can be for a directly connected or indirectly connected peer. For all other protocols, the address is for the neighbor from which the advertisement is received. |
next-hop address | Matches the next-hop address or addresses specified in the routing information for a particular route. For BGP routes, matches are performed against each protocol next hop. |
origin value | Matches the BGP origin attribute, which is the origin of the AS path information. The value can be one of the following:
|
preference preference preference2 preference | Matches the preference value. You can specify a primary preference value (preference) and a secondary preference value (preference2). The preference value can be a number from 0 through 4,294,967,295 (232 – 1). A lower number indicates a more preferred route. |
protocol protocol | Matches the name of the protocol from which the route was learned or to which the route is being advertised. It can be one of the following: aggregate, bgp, direct, dvmrp, isis, local, ospf, pim-dense, pim-sparse, rip, ripng, or static. |
route-type value | Matches the type of route. The value can be either external or internal. |
All conditions in the from and to statements must match for the action to be taken. The match conditions defined in Table 2 are effectively a logical AND operation. Matching in prefix lists and route lists is handled differently. They are effectively a logical OR operation. If you configure a policy that includes some combination of route filters, prefix lists, and source address filters, they are evaluated according to a logical OR operation or a longest-route match lookup.
Table 2 describes the match conditions available for matching an incoming or outgoing route. The table indicates whether you can use the match condition in both from and to statements and whether the match condition functions the same or differently when used with both statements. If a match condition functions differently in a from statement than in a to statement, or if the condition cannot be used in one type of statement, there is a separate description for each type of statement. Otherwise, the same description applies to both types of statements.
Table 2 also indicates whether the match condition is standard or extended. In general, the extended match conditions include criteria that are defined separately from the routing policy (autonomous system [AS] path regular expressions, communities, and prefix lists) and are more complex than standard match conditions. The extended match conditions provide many powerful capabilities. The standard match conditions include criteria that are defined within a routing policy and are less complex than the extended match conditions.
Table 2: Complete List of Routing Policy Match Conditions
Match Condition | Match Condition Category | from Statement Description | to Statement Description |
---|---|---|---|
aggregate-contributor | Standard | Match routes that are contributing to a configured aggregate. This match condition can be used to suppress a contributor in an aggregate route. | |
area area-id | Standard | (Open Shortest Path First [OSPF] only) Area identifier. In a from statement used with an export policy, match a route learned from the specified OSPF area when exporting OSPF routes into other protocols. | |
as-path name | Extended | (Border Gateway Protocol [BGP] only) Name of an AS path regular expression. For more information, see Understanding AS Path Regular Expressions for Use as Routing Policy Match Conditions. | |
as-path-group group-name | Extended | (BGP only) Name of an AS path group regular expression. For more information, see Understanding AS Path Regular Expressions for Use as Routing Policy Match Conditions. | |
color preference color2 preference | Standard | Color value. You can specify preference values (color and color2) that are finer-grained than those specified in the preference and preference2 match conditions. The color value can be a number in the range from 0 through 4,294,967,295 (232 – 1). A lower number indicates a more preferred route. | |
community-count value (equal | orhigher | orlower) | Standard | (BGP only) Number of community entries required for a route to match. The count value can be a number in the range of 0 through 1,024. Specify one of the following options:
Note: If you configure multiple community-count statements, the matching is effectively a logical AND operation. Note: The community-count attribute only works with standard communities. It does not work with extended communities. | You cannot specify this match condition. |
community [ names ] | Extended | Name of one or more communities. If you list more than one name, only one name needs to match for a match to occur (the matching is effectively a logical OR operation). For more information, see Understanding BGP Communities and Extended Communities as Routing Policy Match Conditions. | |
external [ type metric-type ] | Standard | (OSPF and IS-IS only) Match IGP external routes. For IS-IS routes, the external condition also matches routes that are exported from one IS-IS level to another. The type keyword is optional and is applicable only to OSPF external routes. When you do not specify type, the external condition matches all IGP external (OSPF and IS-IS) routes. When you specify type, the external condition matches only OSPF external routes with the specified OSPF metric type. The metric type can either be 1 or 2. To match BGP external routes, use the route-type match condition. | |
family family-name | Standard | Name of an address family. Match the address family of the route. Depending on your device and configuration, family-name can be one of the following:
Default setting is inet. | |
instance instance-name | Standard | Name of one or more routing instances. Match a route learned from one of the specified instances. | Name of one or more routing instances. Match a route to be advertised over one of the specified instances. |
interface interface-name | Standard | Name or IP address of one or more routing device interfaces. Do not use this qualifier with protocols that are not interface-specific, such as IBGP. Match a route learned from one of the specified interfaces. Direct routes match routes configured on the specified interface. | Name or IP address of one or more routing device interfaces. Do not use this qualifier with protocols that are not interface-specific, such as IBGP. Match a route to be advertised from one of the specified interfaces. |
level level | Standard | (Intermediate System-to-Intermediate System [IS-IS] only) IS-IS level. Match a route learned from a specified level. | (IS-IS only) IS-IS level. Match a route to be advertised to a specified level. |
local-preference value | Standard | (BGP only) BGP local preference (LOCAL_PREFlocal-preference (add | subtract) number) attribute. The preference value can be a number in the range 0 through 4,294,967,295 (232 – 1). | |
metric metric metric2 metric metric3 metric metric4 metric | Standard | Metric value. You can specify up to four metric values, starting with metric (for the first metric value) and continuing with metric2, metric3, and metric4. (BGP only) metric corresponds to the multiple exit discriminator (MED), and metric2 corresponds to the interior gateway protocol (IGP) metric if the BGP next hop runs back through another route. | |
multicast-scoping (scoping-name | number) < (orhigher | orlower) > | Standard | Multicast scope value of IPv4 or IPv6 multicast group address. The multicast-scoping name corresponds to an IPv4 prefix. You can match on a specific multicast-scoping prefix or on a range of prefixes. Specify orhigher to match on a scope and numerically higher scopes, or orlower to match on a scope and numerically lower scopes. For more information, see the Multicast Protocols Feature Guide for Routing Devices. You can apply this scoping policy to the routing table by including the scope-policy statement at the [edit routing-options] hierarchy level. The number value can be any hexadecimal number from 0 through F. The multicast-scope value is a number from 0 through 15, or one of the following keywords with the associated meanings:
| |
neighbor address | Standard | Address of one or more neighbors (peers). For BGP, the address can be a directly connected or indirectly connected peer. For all other protocols, the address is the neighbor from which the advertisement is received. Note: The neighbor address match condition is not valid for the Routing Information Protocol (RIP). | Address of one or more neighbors (peers). For BGP import policies, specifying to neighbor produces the same result as specifying from neighbor. For BGP export policies, specifying the neighbor match condition has no effect and is ignored. For all other protocols, the to statement matches the neighbor to which the advertisement is sent. Note: The neighbor address match condition is not valid for the Routing Information Protocol (RIP). |
next-hop [ addresses ] | Standard | One or more next-hop addresses specified in the routing information for a particular route. A next-hop address cannot include a netmask. For BGP routes, matches are performed against each protocol next hop. | |
next-hop-type merged | Standard | LDP generates a next hop based on RSVP and IP next hops available to use, combined with forwarding-class mapping. | You cannot specify this match condition. |
nlri-route-type | Standard | Route type from NLRI 1 through NLRI 10. Multiple route types can be specified in a single policy. | |
origin value | Standard | (BGP only) BGP origin attribute, which is the origin of the AS path information. The value can be one of the following:
| |
policy [ policy-name ] | Extended | Name of a policy to evaluate as a subroutine. For information about this extended match condition, see Understanding Policy Subroutines in Routing Policy Match Conditions. | |
preference preference preference2 preference | Standard | Preference value. You can specify a primary preference value (preference) and a secondary preference value (preference2). The preference value can be a number from 0 through 4,294,967,295 (232 – 1). A lower number indicates a more preferred route. To specify even finer-grained preference values, see the color and color2 match conditions in this table. | |
prefix-list prefix-list-name ip-addresses | Extended | Named list of IP addresses. You can specify an exact match with incoming routes. For information about this extended match condition, see Understanding Prefix Lists for Use in Routing Policy Match Conditions. | You cannot specify this match condition. |
prefix-list-filter prefix-list-name match-type | Extended | Named prefix list. You can specify prefix length qualifiers for the list of prefixes in the prefix list. For information about this extended match condition, see Understanding Prefix Lists for Use in Routing Policy Match Conditions. | You cannot specify this match condition. |
protocol protocol | Standard | Name of the protocol from which the route was learned or to which the route is being advertised. It can be one of the following: access, access-internal, aggregate, arp, bgp, direct, dvmrp, esis, frr, isis, l2circuit, l2vpn, ldp, local, msdp, ospf, ospf2, ospf3, pim,rip, ripng, route-target, rsvp, or static. Note: The ospf2 statement matches on OSPFv2 routes. The ospf3 statement matches on OSPFv3 routes. The ospf statement matches on both OSPFv2 and OSPFv3 routes. | |
rib routing-table | Standard | Name of a routing table. The value of routing-table can be one of the following:
| |
route-filter destination-prefix match-type <actions> | Extended | List of destination prefixes. When specifying a destination prefix, you can specify an exact match with a specific route or a less precise match using match types. You can configure either a common action that applies to the entire list or an action associated with each prefix. For more information, see Understanding Route Filters for Use in Routing Policy Match Conditions. | You cannot specify this match condition. |
route-type value | Standard | Type of BGP route. The value can be one of the following:
To match IGP external routes, use the external match condition. | |
rtf-prefix-list name route-targets | Extended | (BGP only) Named list of route target prefixes for BGP route target filtering and proxy BGP route target filtering. For information about this extended match condition, see Example: Configuring Proxy BGP Route Target Filtering. | You cannot specify this match condition. |
source-address-filter destination-prefix match-type <actions> | Extended | List of multicast source addresses. When specifying a source address, you can specify an exact match with a specific route or a less precise match using match types. You can configure either a common action that applies to the entire list or an action associated with each prefix. For more information, see Understanding Route Filters for Use in Routing Policy Match Conditions. | You cannot specify this match condition. |
state (active | inactive) | Standard | (BGP export only) Match on the following types of advertised routes:
| |
tag string tag2 string | Standard | Tag value. You can specify two tag strings: tag (for the first string) and tag2. These values are local to the router and can be set on configured routes or by using an import routing policy. You can specify multiple tags under one match condition by including the tags within a bracketed list. For example: from tag [ tag1 tag2 tag3 ]; For OSPF routes, thetag action sets the 32-bit tag field in OSPF external link-state advertisement (LSA) packets. For IS-IS routes, the tag action sets the 32-bit flag in the IS-IS IP prefix type length values. (TLV). OSPF stores the INTERNAL route's OSPF area ID in thetag2 attribute. However, for EXTERNAL routes, OSPF does not store anything in the tag2attribute. You can configure a policy term to set the tag2 value for a route. If the route, already has a tag2 value (for example, an OSPF route that stores area id in tag2), then the original tag2 value is overwritten by the new value. When the policy contains the "from area" match condition, for internal OSPF routes, where tag2 is set, based on the OSPF area- ID, the evaluation is conducted to compare the tag2 attribute with the area ID. For external OSPF routes that do not have the tag2 attribute set, the match condition fails. | |
validation-database | Standard | When BGP origin validation is configured, triggers a lookup in the route validation database to determine if the route prefix is valid, invalid, or unknown. The route validation database contains route origin authorization (ROA) records that map route prefixes to expected originating autonomous systems (ASs). This prevents the accidental advertisement of invalid routes. |
Related Documentation
- ACX, M, MX, PTX, QFX, SRX, T Series
- Understanding Prefix Lists for Use in Routing Policy Match Conditions
- Understanding Route Filters for Use in Routing Policy Match Conditions
Published: 2013-07-31
Supported Platforms
Related Documentation
- ACX, M, MX, PTX, QFX, SRX, T Series
- Understanding Prefix Lists for Use in Routing Policy Match Conditions
- Understanding Route Filters for Use in Routing Policy Match Conditions