Route Policy Command Reference

This command is required to discard changes made to a route policy.

This command is required in order to enter the mode to create or edit route policies.

This command is required to save changes made to a route policy.

This command creates a text description which is stored in the configuration file to help identify the content of the entity.

The no form of the command removes the string from the configuration.

This command creates a route policy AS path regular expression statement to use in route policy entries.

The no form of the command deletes the AS path regular expression statement.

This command creates a route policy AS path regular expression statement to use in route policy entries.

The no form of the command deletes the AS path regular expression statement.

This command creates the context to edit route policy entries within an autonomous system path group.

Multiple entries can be created using unique entries. The router exits the filter when the first match is found and executes the action specified. For this reason, entries must be sequenced correctly from most to least explicit.

An entry does not require matching criteria defined (in which case, everything matches) but must have at least define an action in order to be considered complete. Entries without an action are considered incomplete and will be rendered inactive.

The no form of the command removes the specified entry from the autonomous system path group.

This command creates a route policy community list to use in route policy entries.

The no form of the command deletes the community list or the provided community ID.

This command specifies the inactivity timer for the exclusive lock time for policy editing. When a session is idle for greater than this time, the lock is removed and the configuration changes is aborted.

This command enables the context to configure route policies. Route policies are applied to the routing protocol.

The no form of the command deletes the route policy configuration.

This command triggers route policy re-evaluation.

By default, when a change is made to a policy in the config router policy options context and then committed, the change is effective immediately. There may be circumstances when the changes should or must be delayed; for example, if a policy change is implemented that would effect every BGP peer on a router, the consequences could be dramatic. It is more effective to control changes on a peer by peer basis.

If the triggered-policy command is enabled, and a given peer is established, and you want the peer to remain up, then, in order for a change to a route policy to take effect, a clear command with the soft or soft-inbound option must be used. In other words, when a triggered-policy is enabled, any routine policy change or policy assignment change within the protocol will not take effect until the protocol is reset or a clear command is issued to re-evaluate route policies; for example, clear router bgp neighbor x.x.x.x soft. This keeps the peer up and the change made to a route policy is applied only to that peer, or group of peers.

This command enables weighted load balancing in the base router instance for certain types of OSPF, IS-IS, and static routes with equal-cost multipath (ECMP) next hops.

For OSPF and static routes, this command only applies to IPv4 routes where all the next hops are tunnel next hops corresponding to MPLS LSPs with configured load-balancing weights. Weighted load balancing over MPLS LSPs is supported in the following cases:

For IS-IS routes, in addition to enabling the behavior described for OSPF and static routes, this command also allows weighted load balancing when all the ECMP next hops are interfaces with configured load-balancing weights. The interface-level weighted ECMP support for IS-IS applies to both IPv4 and IPv6.

If one or more LSPs or interfaces in the ECMP set of a prefix do not have a load-balancing weight configured, the regular ECMP spraying for the prefix will be performed.

The no form of the command restores regular ECMP spraying of packets to static and IGP route destinations.

This command creates a context to configure a route damping profile to use in route policy entries.

The no form of the command deletes the named route damping profile.

This command configures the half-life parameter for the route damping profile.

The half life value is the time, expressed in minutes, required for a route to remain stable in order for the Figure of Merit (FoM) value to be reduced by one half; for example, if the half life value is 6 (minutes) and the route remains stable for 6 minutes, then the new FoM value is 3 (minutes). After another 3 minutes pass and the route remains stable, the new FoM value is 1.5 (minutes).

When the FoM value falls below the reuse threshold, the route is once again considered valid and can be reused or included in route advertisements.

The no form of the command removes the half life parameter from the damping profile.

This command configures the maximum suppression parameter for the route damping profile.

This value indicates the maximum time, expressed in minutes, that a route can remain suppressed.

The no form of the command removes the maximum suppression parameter from the damping profile.

This command configures the reuse parameter for the route damping profile.

When the Figure of Merit (FoM) value falls below the reuse threshold, the route is once again considered valid and can be reused or included in route advertisements.

The no form of the command removes the reuse parameter from the damping profile.

This command configures the suppression parameter for the route policy damping profile.

A route is suppressed when it has flapped frequently enough to increase the Figure of Merit (FoM) value to exceed the suppress threshold limit. When the FoM value exceeds the suppress threshold limit, the route is removed from the route table or inclusion in advertisements.

The no form of the command removes the suppress parameter from the damping profile.

This command creates a context to configure a prefix list to use in route policy entries.

The no form of the command deletes the named prefix list.

This command creates a prefix entry in the route policy prefix list.

The no form of the command deletes the prefix entry from the prefix list.

This command creates the context to edit route policy entries within the route policy statement.

Multiple entries can be created using unique entries. The router exits the filter when the first match is found and executes the action specified. For this reason, entries must be sequenced correctly from most to least explicit.

An entry does not require matching criteria defined (in which case, everything matches) but must have at least define an action in order to be considered complete. Entries without an action are considered incomplete and will be rendered inactive.

The no form of the command removes the specified entry from the route policy statement.

This command configures an OSPF area as a route policy match criterion.

This match criterion is only used in export policies.

All OSPF routes (internal and external) are matched using this criterion if the best path for the route is by the specified area.

The no form of the command removes the OSPF area match criterion.

This command configures an AS path regular expression statement as a match criterion for the route policy entry.

If no AS path criterion is specified, any AS path is considered to match.

AS path regular expression statements are configured at the global route policy level (config>router>policy-options>as-path name).

The no form of the command removes the AS path regular expression statement as a match criterion.

This command creates a route policy AS path regular expression statement to use in route policy entries.

The no form of the command deletes the AS path regular expression statement.

This command configures a community list as a match criterion for the route policy entry.

If no community list is specified, any community is considered a match.

The no form of the command removes the community list match criterion.

This command creates the context to configure policy match criteria based on a route’s source or the protocol from which the route is received.

If no condition is specified, all route sources are considered to match.

The no form of the command deletes the source match criteria for the route policy statement entry.

This command specifies the external route matching criteria for the entry.

This command specifies address families as matching conditions.

This command is used to match BGP flow-spec routes on the basis of the destination IP prefix in the flow specification. An IPv4 flow-spec route is matched by this command if its NLRI contains a type 1 subcomponent encoding a prefix and prefix-length that is covered by an entry in the referenced prefix-list. An IPv6 flow-spec route is matched by this command if its NLRI contains a type 1 component encoding prefix-offset=0 and a prefix & prefix-length that is covered by an entry in the referenced prefix-list.

The flow-spec-dest command has no effect when the policy is not applied as a BGP import or export policy.

This command is used to match BGP flow-spec routes on the basis of the source IP prefix in the flow specification. An IPv4 flow-spec route is matched by this command if its NLRI contains a type 2 subcomponent encoding a prefix and prefix-length that is covered by an entry in the referenced prefix-list. An IPv6 flow-spec route is matched by this command if its NLRI contains a type 2 component encoding prefix-offset=0 and a prefix & prefix-length that is covered by an entry in the referenced prefix-list.

The flow-spec-source command has no effect when the policy is not applied as a BGP import or export policy.

This command specifies the multicast group-address prefix list containing multicast group-addresses that are embedded in the join or prune packet as a filter criterion. The prefix list must be configured prior to entering this command. Prefix lists are configured in the config>router>policy-options>prefix-list context.

The no form of the command removes the criterion from the configuration.

This command specifies a prefix list host IP address as a match criterion for the route policy-statement entry.

This command specifies the router interface, specified either by name or address, as a filter criterion.

The no form of the command removes the criterion from the configuration.

This command specifies the ISIS route level as a match criterion for the entry.

This command allows match on ng-MVPN BGP route type when the policy is used for VRF-import/VRF-export/BGP global export policy. The policy will only be applied to multicast routes.

The no form of the command disables mvpn-type in the policy evaluation.

This command specifies the neighbor address as found in the source address of the actual join and prune message as a filter criterion. If no neighbor is specified, any neighbor is considered a match.

The no form of the of the command removes the neighbor IP match criterion from the configuration.

This command will configure a match criteria for the origin attribute. Originally, the origin attribute was applicable only to BGP as a mandatory well-known BGP attribute.

The functionality of the origin attribute has expanded to subscriber-management routes (/32 IPv4 host and IPv6 PD wan-host routes). Each subscriber-management route will internally (local to the node) by default carry the origin attribute with one of the three new values (aaa, dhcp and ludb). The value of the attribute will depend on the origin of the subscriber-management route. The aaa, dhcp or ludb values will never be carried in BGP updates as part of the BGP origin attribute or be otherwise visible within the BGP process.

This introduction of the three new values for the origin attribute in the subscriber-management routes will allow customized advertisement of the subscriber-management routes via routing policy.

This command is used to match BGP routes on the basis of origin validation state:

This command creates the context to configure a route policy statement.

Route policy statements control the flow of routing information to and from a specific protocol, set of protocols, or to a specific BGP neighbor.

The policy-statement is a logical grouping of match and action criteria. A single policy-statement can affect routing in one or more protocols and/or one or more protocols peers/neighbors. A single policy-statement can also affect both the import and export of routing information.

The no form of the command deletes the policy statement.

This command is used to call another policy by name and evaluate it as a subroutine, or to evaluate a logical expression of subroutine policies.

If the result of the subroutine evaluation is an 'accept', then the route is considered to match the entry in the parent policy that called the subroutine. If the result of the subroutine evaluation is a 'reject’, then the route is considered a non-match of the entry in the parent policy that called the subroutine.

Up to 3 levels of subroutine calls are supported. If a subroutine at maximum depth has this command, it is automatically considered a non-match of all routes.

The no form of the command removes the policy statement as a match criterion.

This command configures a nested policy statement as a match criterion for the route policy entry.

Policy statements are configured at the global route policy level (config>router>policy-options policy-statement).

The command is used to call another policy by name and evaluate it as a subroutine. If the result of the subroutine evaluation is an 'accept', then the route is considered to match the entry in the parent policy that called the subroutine. If the result of the subroutine evaluation is a 'reject’, then the route is considered a non-match of the entry in the parent policy that called the subroutine. Up to 3 levels of subroutine calls are supported. If a subroutine at maximum depth has this command, it is automatically considered a non-match of all routes.

The no form of the command removes the policy statement as a match criterion.

This command allows operators a powerful and flexible approach to configuring routing policies that are often reused across BGP peers of a common type (transit, peer, customer, and so on). Using policy variables allows an operator to have a single policy that is consistent across all peers of a type, while retaining the flexibility to reference different policy functions (prefixes, prefix-lists, community lists, and so on) with unique names if required, by defining variable names and the variable value.

Depending on the parameter referenced, the correct type should be specified as follows:

The no form of the command removes the policy-variables statement.

This command configures a prefix list as a match criterion for a route policy statement entry.

If no prefix list is specified, any network prefix is considered a match.

An empty prefix list will evaluate as if 'no match' was found.

The prefix lists specify the network prefix (this includes the prefix and length) a specific policy entry applies.

A maximum of five prefix names can be specified.

The no form of the command removes the prefix list match criterion.

This command configures a routing protocol as a match criterion for a route policy statement entry. This command is used for both import and export policies depending how it is used.

If no protocol criterion is specified, any protocol is considered a match.

The no form of the command removes the protocol match criterion.

This command configures a routing protocol as a match criterion for a route policy statement entry. This command is used for both import and export policies depending how it is used.

If no protocol criterion is specified, any protocol is considered a match.

The no form of the command removes the protocol match criterion.

This command specifies the source address that is embedded in the join or prune packet as a filter criterion.

The no form of the command removes the criterion from the configuration.

This command specifies a multicast data source address as a match criterion for this entry.

This command will configure a match criteria on the state attribute. The state attribute carries the state of an SRRP instance and it can be applied to:

Based on the state attribute of the route we can manipulate the route advertisement into the network.

We can enable or disable (in case there is no SRRP running) tracking of SRRP state by routes.

This is done on a per subscriber-interface route basis, where a subscriber-interface route is tracking a single SRRP instance state (SRRP instance might be in a Fate Sharing Group).

For subscriber-management and managed-routes, tracking is enabled per group interface under which SRRP is enabled.

This command specifies a multicast data source address as a match criterion for this entry.

This command matches the tag value in static or IGP routes. A decimal or hexadecimal value of 4 octets can be entered. For IS-IS, OSPF, and static routes, all four octets can be used. For RIP and RIPng, only the two most significant octets are used if more than two octets are configured.

The no form of the command removes the tag field match criterion.

This command creates the context to configure export policy match criteria based on a route’s destination or the protocol into which the route is being advertised.

If no condition is specified, all route destinations are considered to match.

The to command context only applies to export policies. If it is used for an import policy, match criteria is ignored.

The no form of the command deletes export match criteria for the route policy statement entry.

This command configures an OSPF type metric as a match criterion in the route policy statement entry.

If no type is specified, any OSPF type is considered a match.

The no form of the command removes the OSPF type match criterion.

This command creates the context to configure actions to take for routes matching a route policy statement entry.

This command is required and must be entered for the entry to be active.

Any route policy entry without the action command will be considered incomplete and will be inactive.

The no form of the command deletes the action context from the entry.

This command sets the Add-Paths send-limit to a specific value for all routes matched by the policy entry or default action. Add-Paths allows a BGP router to send multiple paths for the same NLRI/prefix to a peer advertising the Add-Paths receive capability. The send-limit dictates the maximum number of paths that can be advertised.

The default send-limit is controlled by the instance, group or neighbor level configuration and applies to all prefixes in a particular address family. Using route policies allows the default send-limit to be overridden to use a larger or smaller maximum value on a per-prefix basis. For example if, for most prefixes advertised to a peer, at most 1 path should be advertised but for a few exceptional prefixes up to 4 paths should be advertised then the neighbor-level send-limit can be set to a value of 1 and the add-paths-send-limit in the policy entry that matches the exceptional routes can be set to a value of 4.

When this command is configured as a default-action or entry-specific action of a VRF export policy, every qualifying matched route is advertised with a per-prefix label in the resulting VPN-IP routes. Examples of non-qualifying routes that are not affected by this command are local interface routes and BGP-VPN routes. Essentially this command overrides, for specific routes, the configured label-mode of the exporting VPRN service.

This command also affects BGP import policies applied to a base router BGP peer. When a label-IPv4 route is matched and accepted by a BGP import policy entry or default action with this command, and it is the best path for the prefix in the label-IPv4 RIB, a per-prefix label is used in the advertised route if there is a BGP next-hop change. A label-IPv4 route advertised with a pre-prefix label supports ECMP forwarding across multiple BGP next-hops; for example, BGP multipath.

The effect of this command on a route matched and accepted by a route policy entry depends on how the policy is applied (BGP import policy vs. BGP export policy), the type of route and the specific form of the command.

In a BGP import policy this command is used to:

In a BGP export policy this command is used to:

This command assigns a BGP AS path list to routes matching the route policy statement entry.

If no AS path list is specified, the AS path attribute is not changed.

The no form of the command disables the AS path list editing action from the route policy entry.

The command prepends a BGP AS number once or numerous times to the AS path attribute of routes matching the route policy statement entry.

If an AS number is not configured, the AS path is not changed.

If the optional number is specified, then the AS number is prepended as many times as indicated by the number.

The no form of the command disables the AS path prepend action from the route policy entry.

This command causes qualifying matched BGP routes to be marked as leakable, meaning they are candidates to be leaked into other routing instances (copied with their complete set of path attributes). A BGP route is a qualifying route if the NLRI has an IPv4 or IPv6 prefix without a label.

Note: A leakable BGP route is not actually leaked into another routing instance unless it is accepted by a leak-import policy of that other routing instance.

The bgp-leak command has an effect only when the policy is applied as a BGP import policy in the base router or a VPRN context.

This command adds or removes a BGP community list to or from routes matching the route policy statement entry.

If no community list is specified, the community path attribute is not changed.

The community list changes the community path attribute according to the add and remove keywords.

The no form of the command disables the action to edit the community path attribute for the route policy entry.

This command configures a damping profile used for routes matching the route policy statement entry.

If no damping criteria is specified, the default damping profile is used.

The no form of the command removes the damping profile associated with the route policy entry.

This command associates a forwarding-class and optionally priority with the routes matched by a route policy entry. The command takes effect when the action of the route policy entry is accept, next-entry or next-policy. It has no effect except in route policies applied as VRF import policies, BGP import policies or RIP import policies.

The no form of the command removes the QoS association of the routes matched by the route policy entry.

This command enables the context to configure actions to apply to routes that do not match any entries of a route policy statement.

The no form of the command deletes the default-action context for the policy statement.

When the best BGP route for an IPv4 or IPv6 prefix is matched by a policy entry or policy default action with this command, BGP attempts to find and install a pre-programmed backup path for the prefix in order to provide BGP fast reroute protection.

The install-backup-path command overrides and has no dependency on commands such as the BGP instance backup-path command or the VPRN-level enable-bgp-vpn-backup command, which enable BGP fast reroute for an entire address family. The install-backup-path command provides more precise control over which IP prefixes are supported with pre-programmed backup paths.

If, within a VPRN, the best path for an IP prefix is provided by a VPRN BGP route, the backup path can be provided by another VPRN BGP route or an imported VPN-IP route. If, within a VPRN, the best path for an IP prefix is provided by an imported VPN-IP route, the backup path can be provided by another VPN-IP route.

The install-backup-path command is supported only in BGP import policies and VRF import policies and has no effect on policy types other than BGP import policies and VRF import policies. The install-backup-path command applies only to the following types of matched routes: IPv4, IPv6, label-IPv4, label-IPv6, VPN-IPv4, and VPN-IPv6.

This command assigns a BGP local preference to routes matching a route policy statement entry.

If no local preference is specified, the BGP configured local preference is used.

The no form of the command disables assigning a local preference in the route policy entry.

In a BGP import or export policy, this command assigns a MED value to routes matched by the policy statement entry. The MED value may be set to a fixed value (overriding the received value), set to the routing table cost of the route used to resolve the NEXT_HOP of the BGP route (igp option), or modified by adding or subtracting a fixed value offset.

The no form of the command removes the MED attribute from the matched routes.

This command enables a redirection under a filtering policy. The filtering policy in this case becomes a redirection policy and it is defined under the router>policy-option hierarchy.

After the redirection policy is applied to the subscriber, all IGMP messages will be processed per subscriber host before they get redirected to the referenced interface (and possibly service). However, multicast traffic will not be replicated directly per subscriber host but instead it will be forwarded on the interface that is referenced in the redirection policy. The redirected interface must have IGMP enabled.

Currently all traffic is redirected and there is no ability to selectively redirect multicast traffic based on match conditions (multicast-groups, source IP address of IGMP messages, etc). Multicast redirection is supported between VPRN services and also between interfaces within the Global Routing Context. Multicast redirection is not supported between the VRPN services and the Global Routing Context. Multicast redirection is supported in the wholesale/retail VPRN context.

Note: Redirecting from a VPRN instance to the GRT is not supported. Redirecting from a VPRN to a different VPRN is supported and redirecting from an IES to another IES is also supported.

This command assigns the specified next hop IP address to routes matching the policy statement entry.

If a next-hop IP address is not specified, the next-hop attribute is not changed.

The no form of the command disables assigning a next hop address in the route policy entry.

This command configures BGP to advertise routes that match a policy entry (or that match no other policy entry and, therefore, to which the default action applies) using a local address of the BGP instance as the BGP next-hop address. The command applies to IPv4, IPv6, label-IPv4, and label-IPv6 routes. It also applies to VPN-IPv4 and VPN-IPv6 routes, but only when used in conjunction with the enable-rr-vpn-forwarding command.

This command affects how routes are advertised to IBGP peers, regardless of whether or not they were learned from an IBGP or EBGP peer

The no form of the command uses protocol standard behavior to decide whether or not to set next-hop-self in advertised routes.

This command sets the BGP origin assigned to routes exported into BGP.

If the routes are exported into protocols other than BGP, this option is ignored.

The no form of the command disables setting the BGP origin for the route policy entry.

This command is used to mark BGP IPv4 and IPv6 routes matching the default-action or a specific entry of a route policy with one of the 3 following origin validation states:

This command assigns a route preference to routes matching the route policy statement entry.

If no preference is specified, the default Route Table Manager (RTM) preference for the protocol is used.

The no form of the command disables setting an RTM preference in the route policy entry.

This command specifies that BGP routes matching an entry or default-action of a route policy should be tagged internally as requiring sticky ECMP behavior. When a BGP route with multiple equal-cost BGP next-hops is programmed for sticky ECMP the failure of one or more of its BGP next-hops causes only the affected traffic flows to be re-distributed to the remaining next-hops; by default (without sticky-ECMP) all flows are potentially affected, even those using a next-hop that did not fail.

This command assigns a tag to routes matching the entry, which is then applied to IGP routes. A decimal or hexadecimal value of 4 octets can be entered.

For IS-IS and OSPF, all four octets can be used.

For RIP and RIPng, only the two most significant octets are used if more than two octets are configured.

The no form of the command removes the tag.

This command sets the subtype for the Type 5 LSA (external LSA).

The no form of the command disables assigning a type in the route policy entry.

This command is used to specify a route existence expression to control evaluation of the policy entry. If the route existence expression evaluates to ‘true’ the matching and action commands of the policy entry are applied as normal. If the route existence expression evaluates to ‘false’ the entire policy entry is skipped and processing continues with the next entry; however, conditional expressions are only parsed when the route policy is used as a BGP export policy or VRF export policy.