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 (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. 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. | |
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. 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:
| |
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:
| |
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_PREFlocal-preference (add | subtract) number) attribute. The preference value can be a number in the range 0 through 4,294,967,295 (232 – 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 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:
| |
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:
| |
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. 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:
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:
| |
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:
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:
| |
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. | |