6.6. 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 context to configure protocol-independent parameters relating to segment routing.

This command creates the context to configure segment routing policies. A segment routing policy specifies traffic to be matched by the policy and actions to take on the matched traffic by applying the instructions encoded in one or more segment lists.

This command administratively enables the collection of ingress traffic statistics for all segment routing policies. The statistics provide counts for the number of incoming packets and bytes corresponding to each (color, endpoint) combination.

If there are any SR-MPLS interfaces on an FP2 or older line-cards, an attempt to enable this command will fail.

The no form of the command disables ingress stats collection for all segment routing policies.

This command administratively disables the collection of ingress statistics for all segment routing policies.

The no form of the command administratively enables the collection of ingress statistics for all segment routing policies.

This command associates a reserved label block with segment routing policies. The name must already exist. Reserved label blocks are configured under the config>router>mpls-labels hierarchy.

A locally-targeted segment routing policy (statically configured or BGP signaled) cannot be activated if its binding SID (BSID) is not an available label between the start-label and end-label of the referenced reserved label block.

The no form of the command removes any association of segment routing policies with a reserved label block.

This command deactivates all segment routing policies and removes the associated entries from the forwarding plane of the router.

It is necessary to execute this shutdown if you want to make a change to the reserved-label-block reference.

The no form of the command enables all segment routing policies so that they can be revalidated and reinstalled as necessary.

This command creates a context to configure a segment routing policy. The resulting segment routing policy is targeted for local installation or propagation by BGP to another router.

The no form of the command deletes the statically defined segment routing policy.

This command associates a binding SID with a statically defined segment routing policy. This is a mandatory parameter in order to enable the segment routing policy. The BSID label should be an available label in the reserved-label-block range.

The no form of the command removes the BSID association.

This command associates a color value with a statically defined segment routing policy. This is a mandatory parameter in order to enable the segment routing policy.

The no form of the command removes the color association.

This command associates a distinguisher value with a statically defined segment routing policy. This is a mandatory parameter for non-local segment routing policies (for which head-end is not local). Every non-local segment routing policy must have a unique distinguisher value. When a non-local static segment routing policy is imported into BGP and originated as a BGP route, the configured distinguisher value is copied into the NLRI of the route.

The no form of the command removes the distinguisher association.

This command associates an IPv4 endpoint address with a statically-defined segment routing policy. This is a mandatory parameter in order to enable the segment routing policy.

An endpoint address of 0.0.0.0 is a special value that matches all BGP next-hops, however in order to use this policy the BGP route must have a color extended community with the color-only bits set to '01' or '10'.

The no form of the command removes the endpoint association.

This command associates a head-end location with a statically-defined segment routing policy. The head-end is an identification of the router which is the target to install the policy. This is a mandatory parameter for enabling the segment routing policy.

In order to associate a static policy with the local router as head-end, the keyword local must be specified. The static policy is associated with another (non-local) router if the head-end parameter is set to any IPv4 address. When a non-local static segment routing policy is imported into BGP and originated as a BGP route, the configured head-end address is converted into an IPv4-address specific route-target extended community that is automatically added to the route.

The no form of the command removes the head-end association.

This command associates a preference value with a statically defined-segment routing policy. This is an optional parameter.

When there are multiple policies for the same (color, endpoint) combination that are targeted for local installation, only one is selected as the active path for the (color, endpoint). In this selection process (which considers both static local policies and BGP signaled policies), the policy with the highest preference value is preferred over all policies with a lower preference value.

The no form of the command reverts to the default value.

This command creates the context to configure a segment list for the statically-defined segment routing policy.

Up to 32 segment lists are supported per policy.

The no form of the command deletes the segment list.

This command creates the context to configure a segment inside a segment-list of a statically-defined segment routing policy.

Each segment list can have up to 11 segments.

The no form of the command deletes the segment context.

This command configures the MPLS label value this is associated with a segment.

The no form of the command removes the label value.

This command deactivates a segment-list. If this is done on an active policy with more than one segment list, then traffic forwarded by the policy will be diverted to the remaining segment-lists.

The no form of the command enables the segment list so that it can be validated and installed as necessary.

This command associates a weight value with a segment list of a statically-defined segment routing policy in order to achieve weighted ECMP behavior. Weight is an optional parameter.

When any segment-list in the active policy has a weight greater than 1, traffic matching the policy will be load-balanced across the segment lists according to their relative weight values.

The no form of the command reverts to the default value.

This command deactivates the associated static policy and causes another policy for the same (color, endpoint) combination to be promoted as the active path, assuming there is another valid policy.

It is necessary to execute this shutdown if you want to make critical configuration changes to the static policy.

The no form of the command enables the static policy so that it can be validated and installed as necessary.

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

The no form of the command deletes the AS path.

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 to use in route policy entries.

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

This command creates a logical expression to match a route policy community.

The no form of the command deletes the logical expression.

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

The no version of this command deletes route policy community members.

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 global-variables configuration context.

The no form of the command removes all global variables.

This command allows operators to configure routing policies that are often reused across BGP peers of a common type (transit, peer, customer, and so on). Using global variables allows an operator to have a single variable 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.

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

The no form of the command removes the global variable.

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 checks policy references to ensure that a policy exists and displays a CLI error if the policy does not exist. Enabling this option protects against accidentally referencing a missing or misspelled policy, that can lead to unexpected results when the policy is evaluated.

The no version of this command disables policy reference checks and allows policies that do not exist to be referenced.

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 affect 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 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 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 matches BGP routes based on their AS path length (the number of AS numbers in the AS_PATH).

If no comparison qualifiers are present (equal, or-higher, or-lower), then equal is the implied default.

Confederation member AS numbers in the AS_PATH do not count towards the total. An AS_SET element is considered to have a length of 1.

The unique option counts .

A non-BGP route does not match a policy entry if it contains the as-path-length command.

This command enables BGP routes to be matched based on the IP addresses encoded in the CLUSTER_LIST attribute.

The first ip-address/mask pair is matched against the most recently added cluster ID. Each subsequent ip-address/mask pair is tested against the next most recent cluster ID.

For example, to match all routes reflected by the RR with cluster ID 1.1.1.1 and then any other RR before reaching the router where the policy is applied, use the command cluster-id 0.0.0.0/0 1.1.1.1/32.

Note: The command matches routes with two or more cluster IDs; the third and older cluster IDs are not evaluated and are automatically considered matching.

The cluster-id none form of the command only matches BGP routes without any CLUSTER_LIST attribute.

A non-BGP route does not match a policy entry if it contains the cluster-id command.

This command matches BGP routes based on community length (that is, the number of community members in the COMMUNITY, EXTENDED_COMMUNITY, or LARGE_COMMUNITY the attributes).

If no comparison qualifiers are present (equal, or-higher, or-lower), then equal is the implied default.

Without the optional standard, extended, or large keyword, the community length applies to the total number of communities, of all types. If some keywords are present, then only the types specified are counted against the limit.

A non-BGP route does not match a policy entry if it contains the community-count command.

This command matches BGP routes based on local preference (the value in the LOCAL_PREF attribute).

If no comparison qualifiers are present (equal, or-higher, or-lower), then equal is the implied default.

A non-BGP route does not match a policy entry if it contains the local-preference command.

This command matches BGP routes based on local preference (the value in the MULTI_EXIT_DISC attribute).

If no comparison qualifiers are present (equal, or-higher, or-lower), then equal is the implied default.

A non-BGP route does not match a policy entry if it contains the metric command. In addition, a BGP route without a MED attribute also does not match a policy entry if it contains a metric command.

This command enables BGP routes to be matched based on the BGP next-hop address. The match condition is evaluated against the IPv4 or IPv6 address in the NEXT_HOP or MP_REACH_NLRI attribute.

When the next-hop match is applied to VPN-IP routes, the Route Distinguisher (RD) is ignored.

A non-BGP route does not match a policy entry if it contains the next-hop command.

This command matches BGP routes based on their path type (EBGP or IBGP). A route learned from an EBGP peer has path-type ebgp. A route learned from an IBGP or confed-EBGP peer has path-type ibgp.

A non-BGP route does not match a policy entry if it contains the path-type command.

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 configures 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). By default, each subscriber-management route will internally (local to the node) carry the origin attribute with one of three values (aaa, dynamic, and static). The value of the attribute depends on the origin of the subscriber-management route. The aaa, dynamic or static values are never carried in BGP updates as part of the BGP origin attribute and are visible within the BGP process.

The values for the origin attribute in the subscriber-management routes allows customized advertisement of the subscriber-management routes by the 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 enables the policy-variables configuration context.

The no form of the command removes all policy variables.

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 28 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 parameter 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 parameter is specified, any protocol is considered a match.

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

This command allows the operator to renumber the existing entry ID to a new entry ID. When performing the renumbering action, the two entry IDs must be different. The existing (from) entry-id must exist. The new (to) entry-id must not exist.

Renumbering is not saved in the configuration because it is a performing action.

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 matches BGP routes based on the EVPN route type. All route types, supported in SROS, are the following:

The no version of this command removes the evpn-type matching.

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.

This command assigns a route admin tag policy as an action in a route policy.

The admin tag policy must exist under config>router>admin-tags.

The no form of the command removes the admin tag policy.

The effect of the advertise-label command depends on the context where the associated policy is applied.

When the per-prefix option is used and the command is configured as the 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. In this situation, non-qualifying routes include local interface routes and BGP-VPN routes. The command overrides, for specific routes, the configured label-mode of the exporting VPRN service.

When configured with the per-prefix option, the 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.

When configured with the pop option, the command also serves a purpose in route-table-import policies. When a /32 IPv4 static, OSPF, or IS-IS route is matched and accepted by a label-IPv4 RIB route-table-import policy entry or default-action with this command, and the route is a candidate to be advertised as a label-IPv4 route (due to a BGP export policy), the advertised BGP label is programmed for a Pop operation. When a /32 static, OSPF, or IS-IS route is imported into the label-IPv4 RIB and then exported as a BGP route, the default behavior is to program a “swap” operation in the datapath, which swaps the BGP label with the tunnel label that takes traffic to the destination of the /32 route.

This command assigns a BGP AIGP metric to routes matching the entry. 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 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 instructs the router to create an MPLS-over-UDP tunnel upon receiving BGP routes that match the import policy.

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 VPRN 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.

Note: This command is supported with the following protocols: RIP import, BGP import, VPRN VRF import (vrf-import), and VPRN GRT lookup export (export-grt).

This command has an affect only in BGP route-table-import policies and applies only to BGP IPv4 and IPv6 routes created by importing static routes with indirect next-hops. When such a route matches a policy entry with this action, the BGP next-hop is the resolved next-hop of the static route.

The no form of the command reverts to the default behavior, which copies the indirect next-hop of the static route into the BGP next-hop without resolving it further.

This command configures the default source-class for this policy-statement.

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.