Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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:

  • 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 (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:

  • 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_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 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 (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:

  • 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, 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.

See Configuring Origin Validation for BGP.