Configuring Match Conditions in Routing Policy Terms
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:
You can include these statements at the following hierarchy levels:
- [edit policy-options policy-statement policy-name term term-name]
- [edit logical-systems logical-system-name policy-options policy-statement policy-name term term-name]
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.
 | Note: In export policies, omitting the from statement from a routing policy term might lead to unexpected results. For more information, see Applying Routing Policies and Policy Chains to Routing Protocols. |
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.
| Note: All conditions in the from and to statements must match for the action to be taken. The match conditions defined in Table 1 are effectively a logical AND operation. Matching in prefix lists and route lists is handled differently. They are effectively a logical OR operation. For more information about how matching occurs for prefix lists and route lists, including how they are evaluated, see Configuring Prefix Lists for Use in Routing Policy Match Conditions and Configuring Route Lists for Use in Routing Policy Match Conditions. 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 1 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 1 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 1: 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 Configuring AS Path Regular Expressions to 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 Configuring AS Path Regular Expressions to 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_PREF) 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 Configuration Guide. 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 address | Standard | 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. Note: If you include a netmask with the next-hop address, the netmask is ignored and a system log message is generated. For more information about system log messages, see the Junos OS System Log Messages Reference. | |
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 Configuring 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 Configuring 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 Configuring 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:
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. For more information about access routes and access-internal routes, see Example: Importing and Exporting Access and Access-Internal Routes in a Routing Policy. | |
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 Configuring Route Lists 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 Configuring Route Lists 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. | |
