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, all routes are considered to match. All routes then take the configured actions of the policy term.

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 (2³² – 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 (2³² – 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: `egp`—Path information originated from another AS. `igp`—Path information originated from within the local AS. `incomplete`—Path information was learned by some other means.
`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 (2³² – 1). A lower number indicates a more preferred route. Note: Do not set `preference2` for BGP route-policy.
`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	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.
`bridge-domain-id bridge-domain-number`	Extended	Bridge domain ID, VLAN ID, or (with VXLAN encapsulation) a VXLAN virtual network identifier (VNI).
`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 (2³² – 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: `equal`—The number of communities must equal this value to be considered a match. `orhigher` —The number of communities must be greater than or equal to this value to be considered a match. `orlower`—The number of communities must be less than or equal to this value to be considered a match. 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. This match condition is not supported for use with the To statement.
`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, Extended Communities, and Large Communities as Routing Policy Match Conditions. BGP EVPN routes have a set of extended communities carried in the BGP update message path attribute, and as such, you can use extended communities for filtering BGP EVPN routes. The information available includes encapsulation type, mac-mobility information, EVPN split-horizon label information, ESI mode, and etree leaf label. Use the following syntax to specify BGP EVPN extended communities: `community (type, in decimal format) val1:val2` `val1` and `val2` can be specified as [2 + 4] octets, or as [4 + 2] octets.
`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.
`evpn-esi`	Standard	You can filter BGP EVPN routes on the basis of Ethernet Segment Identifiers (ESIs) information for routes types 1, 2, 4, 7, and 8, which are the only types to include the ESI attribute in their prefix. (ESI values are encoded as 10-byte integers and are used to identify a multihomed segment.)
`evpn-etag`	Standard	You can filter BGP EVPN routes on the basis of EVPN tag information, which is available from the prefix of the EVPN route. Requires EVPN be set in the following CLI hierarchy: `filter policy-options policy-statement name term name family`
`evpn-mac-route`	Standard	Filtering BGP EVPN type-2 routes based on if it has any IP address. EVPN type-2 MAC routes can have IP address in the prefix along with MAC address. The IP address carried in the MAC-IP route can be either IPv4 or IPv6 address. It is possible to filter out type-2 routes based on only if it has only mac address or mac+ipv4 address or mac+ipv6 address.
`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, or to be advertised to, one of the specified interfaces. Direct routes match routes configured on the specified interface.
`level level`	Standard	(Intermediate System-to-Intermediate System [IS-IS] only) IS-IS level. Match a route learned from, or to be advertised to, a specified level.
`local-preference value`	Standard	(BGP only) BGP local preference (LOCAL_PREF`local-preference (add \| subtract) number`) attribute. The preference value can be a number in the range 0 through 4,294,967,295 (2³² – 1).
`mac-filter-list`	Standard	(BGP only) Named mac filter list. EVPN type-2 routes have mac address as part of the prefix, which you can use to create a list of MAC addresses.
`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 Junos OS Multicast Protocols User 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: `node-local` (value=1)—No corresponding prefix `link-local` (value=2)—Corresponding prefix 224.0.0.0/24 `site-local` (value=5)—No corresponding prefix `global` (value=14)—Corresponding prefix 224.0.1.0 through 238.255.255.255 `organization-local` (value=8)—Corresponding prefix 239.192.0.0/14
`neighbor address`	Standard	Address of one or more neighbors (peers). For BGP, the address can be a directly connected or indirectly connected peer. 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 address is the neighbor from which the advertisement is received, or for `to` statements, it 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. This match condition is not supported for use with the To statement.
`nlri-route-type`	Standard	Route type from NLRI 1 through NLRI 10. Multiple route types can be specified in a single policy. For EVPN, NLRI route types range from 1 to 8 (the first octet of the route prefix in the BGP update message is the EVPN route type). In addition to filtering on EVPN NLRI route types, you can also filter on IP address or MAC address (mac-ip) that is embedded in the EVPN route prefix for route types 2 and 5. To do so, use a `prefix-list` or `route-filter` for the address. When a type-5 route is created from a type 2 mac-ip advertisement that was learned remotely, then the community that was learned from the type-2 route advertisement is included in the new type-5 route. You can prevent this by enabling the `donot-advertise-community` statement at the `protocols evpn ip-prefix-routes` hierarchy.
`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: `egp`—Path information originated in another AS. `igp`—Path information originated within the local AS. `incomplete`—Path information was learned by some other means.
`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 (2³² – 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. This match condition is not supported for use with the To statement. This match condition is not supported for use with the To statement.
`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. When used with EVPN NRLI route types 2 and 5, the following are supported: `from prefix-list-filter [ exact \| longer \| orlonger ]` For information about this extended match condition, see Understanding Prefix Lists for Use in Routing Policy Match Conditions. This match condition is not supported for use with the To statement.
`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`, `anchor`, `arp`, `bgp`, `bgp-ls-epe`,`bgp-static`, `direct`, `dvmrp`, `esis`, `evpn`, `frr`, `isis`, `l-isis`, `isis`, `l2-learned-host-routing`, `l2circuit`, `l2vpn`, `ldp`, `local`, `mpls`, `msdp`, `ospf` (matches both OSPFv2 and OSPFv3 routes), `ospf2` (matches OSPFv2 routes only), `ospf3` (matches OSPFv3 routes only), `pim`, `rift`, `rip`, `ripng`, `route-target`, `rsvp`, `spring-te`, `static`, or `vpls`.
`rib routing-table`	Standard	Name of a routing table. The value of `routing-table` can be one of the following: inet.0—Unicast IPv4 routes `instance-name` inet.0—Unicast IPv4 routes for a particular routing instance inet.1—Multicast IPv4 routes inet.2—Unicast IPv4 routes for multicast reverse-path forwarding (RPF) lookup inet.3—MPLS routes mpls.0—MPLS routes for label-switched path (LSP) next hops inet6.0—Unicast IPv6 routes
`route-distinguisher`	Standard	Name of the route-distinguisher (RD). RD supports filtering BGP EVPN routes. The RD information is carried in the prefix of the EVPN route.
`route-filter` `route-filter-list`	Standard	Named route filter or route filter list. You can specify prefix length qualifiers for the list of routes in the route filter list. When used with EVPN NRLI route types 2 and 5, the following are supported: `from route-filter [ address-mask \| exact \| longer \| orlonger \| prefix-length-range \| through \| upto ]` This match condition is not supported for use with the To statement.
`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 an Export Policy for BGP Route Target Filtering for VPNs. This match condition is not supported for use with the To statement.
`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. This match condition is not supported for use with the To statement.
`state (active \| inactive)`	Standard	(BGP export only) Match on the following types of advertised routes: `active`—An active BGP route `inactive`—A route advertised to internal BGP peers as the best external path even if the best path is an internal route `inactive`—A route advertised by BGP as the best route even if the routing table did not select it to be an active route
`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, the`tag` 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 the`tag2` attribute. However, for EXTERNAL routes, OSPF does not store anything in the `tag2`attribute. 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. See Configuring Origin Validation for BGP.

Routing Policy Match Conditions

Related Documentation