Route policies

Configuring route policies

Nokia’s router supports two databases for routing information. The routing database is composed of the routing information learned by the routing protocols. The forwarding database is composed of the routes actually used to forward traffic through a router. In addition, link state databases are maintained by interior gateway protocols (IGPs) such as IS-IS and OSPF.

Routing protocols calculate the best route to each destination and place these routes in a forwarding table. The routes in the forwarding table are used to forward routing protocol traffic, sending advertisements to neighbors and peers.

A routing policy can be configured that will not place routes associated with a specific origin in the routing table. Those routes will not be used to forward data packets to the intended destinations and the routes are not advertised by the routing protocol to neighbors and peers.

Routing policies control the size and content of the routing tables, the routes that are advertised, and the best route to take to reach a destination. Careful planning is essential to implement route policies that can affect the flow of routing information or packets in and traversing through the router. Before configuring and applying a route policy, develop an overall plan and strategy to accomplish your intended routing actions.

There are no default route policies. Each policy must be created explicitly and applied to a routing protocol or to the forwarding table. Policy command options are modifiable.

Policy statements

SR OS route policy statements consist of a sequence of ordered rules, or entries. When the policy is applied to a routing adjacency, route table, or some other context, each route associated with that context is evaluated by the rules of the policy, in the specified order, until a matching entry is found or the end of the policy is reached. If a matching entry is found, then its actions are applied to the route. However, if there is no matching entry, then the policy default action is applied to the route.

Use the commands in the following context to configure route policy statements:

  • MD-CLI
    configure policy-options policy-statement
  • classic CLI
    configure router policy-options policy-statement

Some of the match criteria that can be used in a policy entry include:

  • IP prefix-list reference

  • AS path regular expression

  • community list reference

  • route properties such as MED, local-preference, IGP metric, IGP route type, BGP path type, and so on

In classic mode and mixed-mode every policy-statement must have numbered entries.

In the MD-CLI mode, each policy-statement can be configured to be named or number entry types. Numbered types behave as in classic mode and mixed-mode. In named types, each entry is a specific string-format name up to 255 characters in length, and entries are evaluated in user order (the order they appear in the configuration).

The MD-CLI and NETCONF management interfaces support insert commands that change the order of the named entries in a policy statement.

For example, if a named entry called entry2 needs to be moved ahead of an already-existing named entry called entry1 (so that it is evaluated first), use the following command to change the order.

configure policy-options policy-statement insert named-entry entry2 before entry1

Policy statement chaining and logical expressions

Multiple policy-statement names can be specified in the CLI commands that attach route policies to specific functions. A chain of routing policies is created if a list of two or more policy names is specified in the CLI command. Route policy chaining allows complex route processing logic to be broken into smaller components. This enables the reuse of common functions and facilitates the process of amending and updating route control logic as required.

Each route is evaluated against a policy chain as follows.

  1. The route is evaluated against the first listed policy. If the route matches an entry with action next-policy, or the route matches no entry and the default action is next-policy (or there is no default action specified at all), the evaluation continues into the second policy.

  2. The route is evaluated against the second listed policy. If the route matches an entry with next-policy as the action or a default action of next-policy applies, the evaluation continues to the third policy.

  3. The sequential evaluation of policies continues until the route is accepted or rejected by an entry or explicit default action.

In addition to policy chaining, the SR OS also supports policy logical expressions that enable applications to use complex multiple policy statements. A policy logical expression can be used as a standalone expression or as part of a policy chain. Each policy chain supports a maximum of one logical expression. The logical expression is usually the first element of the policy chain; however, it can appear in a non-initial position as long as its length does not exceed 64 characters.

A route policy logical expression is a string composed of logical operators (keywords AND, OR and NOT), up to 16 route policy names (each up to 64 characters in length and delimited by brackets ( ) and square brackets [ ] to group sub-expressions (with up to three levels of nesting)). The total length of the route policy expression cannot exceed 900 characters.

The following are examples of valid logical expressions in the SR OS CLI syntax:

  • ‟NOT [policyA]”

  • ‟[policyA] AND [policyB] OR [policyC]”

  • ‟NOT ([policyA] OR [policyB] OR [policyC])”

The final result of a route policy evaluation against a logical expression is TRUE or FALSE. The SR OS rules for policy evaluation are as follows.

  • If the expression includes a NOT operator followed by a sub-expression in brackets, the expression is flattened using De Morgan's rule.

    For example, the expression ‟NOT ([policyA] OR [policyB] OR [policyC])” is flattened to: ‟(NOT [policyA]) AND (NOT [policyB]) AND (NOT [policyC])”.

  • The usual rules of precedence apply: NOT is the highest priority, then AND, then OR.

  • The use of ‟NOT <expression>” negates the TRUE/FALSE result of the expression.

  • Where the logic is ‟(<expression1>) AND (<expression2>)”, if expression1 is FALSE, the result is FALSE and expression2 is not evaluated. If expression1 is TRUE, expression2 is then evaluated. The final result is TRUE only if both expressions are TRUE.

  • Where the logic is ‟(<expression1>) OR (<expression2>)”, if expression1 is TRUE, the result is TRUE and expression2 is not evaluated. If expression1 is FALSE, expression2 is then evaluated. The final result is TRUE if either expression is TRUE.

  • Evaluation of a policy termination is as follows:
    • MD-CLI

      If the evaluation of a policy terminates with an accept, next-entry or next-policy action, the result is TRUE. If the evaluation of a policy terminates with an reject or drop action, the result is FALSE. If a route matches no entry in a policy and there is no specified default action, the implied default action is next-policy; if there is no next policy, this translates to the default action for the protocol.

    • classic CLI

      If the evaluation of a policy terminates with an accept, next-entry or next-policy action, the result is TRUE. If the evaluation of a policy terminates with an reject or drop action, the result is FALSE. If a route matches no entry in a policy and there is no specified default action, the implied default action is next-policy; if there is no next policy, this translates to the default action for the protocol.

    If the evaluation of a policy terminates with an accept, next-entry or next-policy action, the result is TRUE. If the evaluation of a policy terminates with an reject or drop action, the result is FALSE. If a route matches no entry in a policy and there is no specified default action, the implied default action is next-policy; if there is no next policy, this translates to the default action for the protocol.

  • When a route is evaluated against a policy contained in a logical expression, the route property changes (such as MED, local preference, communities) made by the matching entry or default action apply cumulatively to the route. The result of a cumulative change is that a policy evaluated later in the logical expression (or later in the entire policy chain) may undo or reverse prior changes. A later policy in the logical expression (or policy chain) may also match a route on the basis of route properties that were modified by earlier policies.

When evaluation of the logical expression is complete, the final TRUE or FALSE result is translated back to a traditional action. The FALSE value is translated to action reject; the TRUE value is translated to action accept, action next-policy or action next-entry to match the action of the last policy that produced the TRUE result.

Routing policy subroutines

It is possible to reference a routing policy from within another routing policy to construct powerful subroutine based policies.

Up to the three levels of subroutine calls are supported. Policy subroutines produce a final result of TRUE or FALSE through matching and policy entry actions. A policy entry action of ‛accept’ evaluates to TRUE, and a policy entry action of reject evaluates to FALSE.

When using next-policy action state in the subroutine, the match value is defined by the default action behavior. The action is protocol-dependent. See Default action behavior for information about the default actions that are applied during packet processing.

Note: When subroutines are configured to reject routes, the accept action state can be used as a possible configuration in the subroutine match criteria to return a true-match, and the reject action state can be applied in the main policy entry that has called the subroutine.

If a match is not found during the evaluation of one or more routing policies, the final evaluation returns the accept or the reject provided by the default behavior based on the policy type (import or export) and the destination and/or source protocol.

Policy evaluation command

Users can evaluate a routing policy against a BGP neighbor, routing context, or individual prefix before applying the policy to the neighbor or routing context. Use the following command to show what modifications are made by a policy.

show router bgp policy-test plcy-or-long-expr
Use the display-rejects or display-rejects-only command options under the following context to display prefixes that are rejected by a policy.
show router bgp policy-test plcy-or-long-expr

Exclusive editing for policy configuration

Note: This section applies for the classic CLI.

In the classic CLI, users can set an exclusive lock on policy edit sessions using the following command.

configure router policy-options exclusive-lock

When the exclusive flag is set by a user that is editing policy, other users (console or SNMP) are restricted from being able to begin, edit, commit, or abort policy. An administrative override is made available to reset the exclusive flag in the event of a session failure.

Default action behavior

The default action of a policy applies to a route when the route does not match any of the entries of the policy. If a policy does not have any match entries, all routes are subject to the default action. If no default action is specified and the policy is the last one in a chain of policies, the default action is determined by the protocol that called the policy.

If a default action is defined for one or more of the configured route policies, then the default action is handled as follows.

  • The default action can be set to all available action states including accept, reject, next-entry, and next-policy.

  • If the action states accept or reject, the policy evaluation terminates and the appropriate result is returned.

  • If a default action is defined and no matches occurred with the entries in the policy, then the default action is used.

  • If a default action is defined and one or more matches occurred with the entries of the policy, then the default action is not used.

Denied IP unicast prefixes

The Route Table Manager does not inherently restrict any IP prefixes from the forwarding table, but individual routing protocols may not accept prefixes that are not globally routable.

Controlling route flapping

Route damping is a controlled acceptance of unstable routes from BGP peers so that any ripple effect caused by route flapping across BGP AS border routers is minimized. The motive is to delay the use of unstable routes (flapping routes) to forward data and advertisements until the route stabilizes.

Nokia’s implementation of route damping is based on the following:

  • Figure of merit

    A route is assigned a Figure of Merit (FoM), which is proportional to the frequency of flaps. FoM should be able to characterize a route’s behavior over a period of time.

  • route flap

    A route flap is not limited to the withdrawn route. It also applies to any change in the AS path or the next hop of a reachable route. A change in AS path or next hop indicates that the intermediate AS or the route-advertising peer is not suppressing flapping routes at the source or during the propagation. Even if the route is accepted as a stable route, the data packets destined for the route could experience unstable routing because of the unstable AS path or next hop.

  • suppress threshold

    The threshold is a configured value that, when exceeded, the route is suppressed and not advertised to other peers. The state is considered to be down from the perspective of the routing protocol.

  • reuse threshold

    When FoM value falls below a configured reuse threshold and the route is still reachable, the route is advertised to other peers. The FoM value decays exponentially after a route is suppressed. This requires the BGP implementation to decay thousands of routes from a misbehaving peer.

The following events could trigger the route flapping algorithm:

  • route flapping

    If a route flap is detected within a configured maximum route flap history time, the route’s FoM is initialized and the route is marked as a potentially unstable route. Every time a route flaps, the FoM is increased and the route is suppressed if the FoM crosses the suppress threshold.

  • route reuse timer trigger

    A suppressed route’s FoM decays exponentially. When it crosses the reuse threshold, the route is eligible for advertisement if it is still reachable.

If the route continues to flap, the FoM, with respect to time scale, resembles a sawtooth waveform with the exponential rise and decay of FoM. To control flapping, the following command options can be configured:

  • half-life

    The half-life value is the time, expressed in minutes, required for a route to remain stable in order for one half of the FoM value to be reduced. 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. After another 6 minutes passes and the route remains stable, the new FoM value is 1.5.

    Use the following command to configure the half-life value:
    • MD-CLI
      configure policy-options damping half-life
    • classic CLI
      configure router policy-options damping half-life
  • max-suppress

    The maximum suppression time, expressed in minutes, is the maximum amount of time that a route can remain suppressed.

    Use the following command to configure the maximum suppression time:

    • MD-CLI
      configure policy-options damping max-suppress
    • classic CLI
      configure router policy-options damping max-suppress
  • suppress

    If the FoM value exceeds the configured integer value, the route is suppressed for use or inclusion in advertisements.

    Use the following command to configure the suppression value:

    • MD-CLI
      configure policy-options damping suppress
    • classic CLI
      configure router policy-options damping suppress
  • reuse

    If the suppress value falls below the configured reuse value, then the route can be reused.

    Use the following command to configure the reuse value:
    • MD-CLI
      configure policy-options damping reuse
    • classic CLI
      configure router policy-options damping reuse

Regular expressions

SR OS supports using regular expression syntax to match BGP routes based on their AS path or communities.

A regular expression is made up of terms and operators and must be enclosed in quotes.

The elementary term for an AS path regular expression is an AS number. The following are more complex terms:

  • a range term composed of two elementary terms separated by a hyphen (-), such as 200-300.

  • the dot wild-card (.) character, which matches any elementary term

  • a regular expression enclosed in parentheses

  • a regular expression enclosed in square brackets, with the brackets used to specify a set of choices of elementary or range terms; for example, [100-300 400] matches any AS number between 100 and 300 (inclusive) or the AS number 400. Precede the elementary and range terms inside the square brackets with a caret sign (^) to reverse the match criteria; for example, [^100-300 400] matches all AS numbers except 100-300 or 400.

The elementary term for a community member regular expression is a single digit. The following are more complex terms:

  • a range term composed of two elementary terms separated by a hyphen (-), such as 2-3.

  • a colon (:) delimiting the parts of a standard community value

  • a regular expression enclosed in parentheses

  • a regular expression enclosed in square brackets, with the square brackets used to specify a set of choices of elementary or range terms; for example, [51-37] matches digit 5, any single digit between 1 and 3, or digit 7. Precede the elementary and range terms inside the square brackets with a caret sign (^) to reverse the match criteria; for example, [^13579]0:100 matches the standard community 20:100, but does not match 30:100.

Route target and route origin extended communities can embed two regular expressions separated by one ampersand sign (&). The first expression is applied to the AS value of the community string, and the second expression is applied to the local administrative value.

Large communities can embed three regular expressions separated by two ampersands (&). The first expression is applied to the Global Administrator, the second expression is applied to the Local Data part 1, and the third expression is applied to the Local Data part 2.

A raw hex format can be keyed to represent all extended communities; for example, ext:0102:dc0000020032 is equal to target:65530:20. Hex values "ext:" and "&" are also used to filter extended communities. The first expression is applied to the type or subtype of the extended community, and the second expression is applied to the value. In this case, hex values can also be used in the operands; for example, the value {3,f} matches a minimum of three and a maximum of 15 repetitions of the term.

The following table describes regular expression operators.

Table 1. Regular expression operators
Operator Description

|

Matches the term on alternate sides of the pipe.

*

Matches multiple occurrences of the term.

?

Matches 0 or 1 occurrence of the term.

+

Matches 1 or more occurrence of the term.

( )

Used to parenthesize so a regular expression is considered as one term.

[ ]

Used to demarcate a set of elementary or range terms.

[^]

Used to demarcate a set of elementary or range terms that are explicitly not matching.

-

Used between the start and end of a range.

{m,n}

Matches least m and at most n repetitions of the term.

{m}

Matches exactly m repetitions of the term.

{m,}

Matches m or more repetitions of the term.

^

Matches the beginning of the string - only allowed for communities.

$

Matches the end of the string - only allowed for communities.

\

An escape character to indicate that the following character is a match criteria and not a grouping delimiter.

<>

Matches any AS path numbers containing a confederation SET or SEQ.

&

Matches ‟:” between terms of a community string (applicable to extended communities origin, target, bandwidth, ext only).

Examples of ‟target:”, ‟origin:” and ‟ext:” community strings are listed in Community strings examples .

Table 2. Community strings examples
Example expression Example matches

"ext:..&f(.*)[af]$"

Matches the community "ext:0002:fffa0000001a".

'target:1&22

Matches community target:100:221.

target:^1&^22

Matches community target:100:221.

target:(.*)0$&(.*)1$

Matches community target:100:221.

origin:^1&(.*)1$

Matches community origin:100:221.

Examples of AS path and community string regular expressions are listed in AS path and community regular expression examples .

Table 3. AS path and community regular expression examples
AS path to match criteria Regular expression Example matches

Null AS path

null1

Null AS path

AS path is 11

11

11

AS path is 11 22 33

11 22 33

11 22 33

Zero or more occurrences of AS number 11

11*

Null AS path

11

11 11

11 11 11

11 … 11

Path of any length that begins with AS numbers 11, 22, 33

11 22 33 .*

11 22 33

11 22 33 400 500 600

Path of any length that ends with AS numbers 44, 55, 66

.* 44 55 66

44 55 66

100 44 55 66

100 200 44 55 66

100 200 300 44 55 66

100 200 300 … 44 55 66

One occurrence of the AS numbers 100 and 200, followed by one or more occurrences of the number 33

100 200 33+

100 200 33

100 200 33 33

100 200 33 33 33

100 200 33 33 33 … 33

One or more occurrences of AS number 11, followed by one or more occurrences of AS number 22, followed by one or more occurrences of AS number 33

11+ 22+ 33+

11 22 33

11 11 22 33

11 11 22 22 33

11 11 22 22 33 33

11 … 11 22 … 22 33 …33

Path whose second AS number must be 11 or 22

(. 11) | (. 22) .*

or . (11 | 22) .*

100 11

200 22 300 400

Path of length one or two whose second AS number may be 11 or 22

. (11 | 22)?

100

200 11

300 22

Path whose first AS number is 100 and second AS number is either 11 or 22

100 (11 | 22) .*

100 11

100 22 200 300

Either AS path 11, 22, or 33

[11 22 33]

11

22

33

Range of AS numbers to match a single AS number

10-14

10 or 11 or 12 or 13 or 14

[10-12]*

Null AS path

10 or 11 or 12

10 10 or 10 11 or 10 12

11 10 or 11 11 or 11 12

12 10 or 12 11 or 12 12

Zero or one occurrence of AS number 11

11? or 11{0,1}

Null AS path

11

One through four occurrences of AS number 11

11{1,4}

11

11 11

11 11 11

11 11 11 11

One through four occurrences of AS number 11 followed by one occurrence of AS number 22

11{1,4} 22

11 22

11 11 22

11 11 11 22

11 11 11 11 22

Path of any length, except nonexistent, whose second AS number can be anything, including nonexistent

. .* or . .{0,}

100

100 200

11 22 33 44 55

AS number is 100. Community value is 200.

^100:200$

100:200

AS number is 11 or 22. Community value is any number.

^((11)|(22)):(.*)$

11:100

22:100

11:200

AS number is 11. Community value is any number that starts with 1.

^11:(1.*)$

11:1

11:100

11:1100

AS number is any number. Community value is any number that ends with 1, 2, or 3.

^(.*):(.*[1-3])$

11:1

100:2002

333:55553

AS number is 11 or 22. Community value is any number that starts with 3 and ends with 4, 5 or 9.

^((11)|(22)):(3.*[459])$

11:34

22:3335

11:3777779

AS number is 11 or 22. Community value ends in 33 or 44.

[^((11|22)):(.*((33)|(44)))$

11:33

22:99944

22:555533

Range of Community values

100&^([1-9][0-9]|[1-9][0-9][0-9]|1[0-9][0-9][0-9]|2000)$"

100:10

100:11

100: …

100:2000

1 The null keyword matches an empty AS path.

BGP and OSPF route policy support

OSPF and BGP requires route policy support. BGP route policy diagram and OSPF route policy diagram display where route policies are evaluated in the protocol. BGP route policy diagram depicts BGP which applies a route policy as an internal part of the BGP route selection process. OSPF route policy diagram depicts OSPF which applies routing policies at the edge of the protocol, to control only the routes that are announced to or accepted from the Route Table Manager (RTM).

Figure 1. BGP route policy diagram

BGP route policies

Nokia’s implementation of BGP uses route policies extensively. The implied or default route policies can be overridden by customized route policies. The default BGP properties, with no route policies configured, behave as follows:

  • accept all BGP routes into the RTM for consideration

  • announce all used BGP learned routes to other BGP peers

  • announce none of the IGP, static or local routes to BGP peers

    Figure 2. OSPF route policy diagram

Re-advertised route policies

Occasionally, BGP routes may be re advertised from BGP into OSPF, IS-IS, and RIP. OSPF export policies (policies control which routes are exported to OSPF) are not handled by the main OSPF task but are handled by a separate task or an RTM task that filters the routes before they are presented to the main OSPF task.

Triggered policies

With triggered policy enabled, deletion and re-addition of a peer after making changes to an export policy causes the new updates to be sent out to all peers.

The triggered policy feature is not honored if a new peer is added to BGP. An update with the old policy is sent to the newly added peer. The new policy does not get applied to the new peer until the peer is flapped.

With triggered policy enabled, if a new BGP/static route comes in, a new addition or the modification of an export policy causes the updates to send out dynamically to all peers with the new or modified export policy.

When multiple peers (for example, P1, P2 and P3) share the same export policy, any modifications to the export policy followed the following command on one of the peers, for instance P1, sends out routes to P1 only according to newly modified policy.

clear router bgp neighbor soft

Though routes with a newly modified policy are not sent to other peers (P2 and P3) as there were no issues the clear router bgp neighbor command with the soft command option on these peers, RIB-OUT shows that new routes with the modified policy are sent to all the peers. RIB-IN on peers P2 and P3 are shown correctly.

Note: With the triggered policy feature enabled, deletion and re-addition of a peer after making changes to an export policy causes the new updates sent out to all peers.

The triggered policy is not honored if a new peer is added to BGP. An update with the old policy is sent to the newly added peer. The new policy is not applied to the new peer until the peer is flapped.

With the triggered policy feature enabled, if a new BGP/static route comes in, the new addition or modification of an export policy causes the updates to be sent out dynamically to all peers with the new or modified export policy.

When multiple peers, such as P1, P2, and P3, share the same export policy, any modifications to the export policy followed by using the clear router bgp neighbor command with the soft command option on one of the peer P1s, send out routes to P1 only according to the newly modified policy. Though routes with the newly modified policy are not sent to other peers (P2 and P3) as there are no issues using the clear router bgp neighbor command with the soft command option on these peers, RIB-OUT shows that the new routes with the modified policy are sent to all the peers. RIB-IN on peers P2 and P3 are shown correctly.

Set MED to IGP cost using route policies

This feature sets MED to the IGP cost of a route exported into BGP as an action in route policies. The following command supports this feature at the global BGP level.

configure router bgp med-out
configure service vprn bgp med-out

The following command supports this feature at the BGP group level.

configure router bgp group med-out
configure service vprn bgp group med-out

Additionally, the following command supports this feature at the BGP neighbor level:

  • MD-CLI

    configure router bgp neighbor med-out
    configure service vprn bgp neighbor med-out
  • classic CLI

    configure router bgp group neighbor med-out
    configure service vprn bgp group neighbor med-out

However, the preceding commands lack per-prefix granularity. Alternatively, use the command options in the following context to set the MED to a fixed number or add or subtract a fixed number from the received MED, as well as set the IGP cost option:

  • MD-CLI

    configure policy-options policy-statement entry action metric
  • classic CLI

    configure router policy-options policy-statement entry action metric

Configuring the set command option to use igp (when used in a BGP export policy), has the same effect as configuring the med-out command to use igp-cost, except that it applies only to the routes matched by the policy entry.

The effect configuring the set command option to igp depends on the route type and policy type, as described in the following table.

Table 4. Metric set IGP effect
BGP policy type Matched route type Set metric IGP effect

Export

Non-BGP route (static, OSPF, ISIS, and so on)

Add MED attribute. Set value to M.

Export

BGP route without MED

Add MED attribute. Set value to D.

Export

BGP route with MED (value A)

Overwrite MED attribute with value D.

BGP policy subroutines

A BGP policy can call another policy (subroutine) and that subroutine can call another subroutine, and so on. This facilitates re-usability of common logic and a structured approach to writing BGP policies. Up to three levels of subroutine are supported.

Route policies for BGP next-hop resolution and peer tracking

This feature adds the flexibility to attach a route policy to the BGP next-hop resolution process; it also allows a route policy to be associated with the optional BGP peer-tracking function. BGP next-hop resolution is a fundamental part of BGP protocol operation; it determines the best matching route (or tunnel) for the BGP next-hop address and uses information about this resolving route in the best path selection algorithm and to program the forwarding table. Attaching a policy to BGP next-hop resolution provides more control over which IP routes in the routing table can become resolving routes. Similar flexibility is also available for BGP peer-tracking, which is an optional feature that allows the session with a BGP neighbor to be taken down if there is no IP route to the neighbor address or if the best matching IP route is rejected by the policy.

Routing policy parameterization

Routing policy parameterization allows operators a powerful and flexible configuration approach to routing policies for policies are often reused across BGP peers of a common type (such as, transit, peer, customer).

In current modes of operation as shown in Route policy past mode of operation, an operator must create individual routing policies, prefix lists, AS-Path lists, community lists, and so on for each peer despite many times the policy ultimately being the same. In this case, if a user with 100 peers with a common policy behavior, but unique policies have to make a change to entry 135 in the policy, they must do it on all policies, which is a significant amount of work that can result in incorrect or inconsistent policy behavior.

Figure 3. Route policy past mode of operation

Using a parameter based system allows a user to have a single policy that is consistent across all peers of a type, while retaining the flexibility to reference different policy functions (such as, prefixes, prefix lists, community lists) with unique names (if required), by defining variables and the variable value.

Additionally, instead of policies being fixed and requiring many statements, the use of command options and variables may be passed to simplify policy configuration. This reduces the number of policies required on a peering edge router with large numbers of peers where only small amounts of configuration changes between peers, such as the ASN and prefix-list name.

The following types of policy variables are supported:

  • global policy variables

    Use the commands in the following context to configure global policy variables:

    • MD-CLI

      configure policy-options global-variables
    • classic CLI

      configure router policy-options global-variables

    Global policy variables can be referenced from any policy. Use global policy variables when the variables are used by multiple policies.

  • local policy variables

    Use the commands in the following contexts to configure local policy variables:

    • MD-CLI

      configure policy-options policy-statement entry from policy-variables
    • classic CLI

      configure router policy-options policy-statement entry from policy-variables

    Local policy variables can be referenced in a sub-policy. Use local policy variables when the variables are specific to a policy and are not used in any other policies.

Note: Local policy variables have precedence over global policy variables, if policy variables have the same name.
Figure 4. Route policy parameterization using sub-policies

Variables expansion can use two formats, with the variable name delimited by at-signs (@) at the beginning and the end:

  • Standard variables must start and end with at-signs (@), for example, @variable@.

  • Midstring variables must be enclosed with at-signs (@) and may be midstring, for example, @variable@, start@variable@end, @variable@end, start@variable@.

The following table describes route policy variables supported in policy command options.

Table 5. Route policy variable support in policy parameters
Parameter name Variable in policy ‟from” statement Variable in policy ‟action” statement Variable format Standard format release Midstring format release

aigp-metric

No

Yes

Standard

13.0.R4

as-path

Yes

Yes

Midstring

12.0.R1

13.0.R1

as-path expression

Yes

No

Midstring

12.0.R4

13.0.R1

as-path-group

Yes

No

Midstring

12.0.R1

13.0.R1

as-path-group expression

Yes

No

Midstring

12.0.R4

13.0.R1

as-path-length

Yes

Standard

15.0.R1

as-path-prepend

Yes

Standard

13.0.R4

cluster-id

No

community

Yes

Yes

Midstring

12.0.R1

13.0.R1

community-count

Yes

Standard

15.0.R1

N/A

damping

No

Yes

Midstring

13.0.R4

13.0.R4

local-preference

Yes (15.0.R1)

Yes (13.0.R4)

Standard

13.0.R4

metric

Yes (15.0.R1)

Yes (13.0.R4)

Standard

13.0.R4

next-hop

No

Yes

Standard

13.0.R4

origin

No

Yes

Standard

13.0.R4

path-type

No

preference

No

Yes

Standard

13.0.R4

prefix-list

Yes

No

Midstring

12.0.R1

13.0.R1

route-distinguisher-list

Yes

No

Midstring

23.3.R1

23.3.R1

tag

No

Yes

Standard

13.0.R4

type

No

Yes

Standard

13.0.R4

For the definition of the variables, there are three different possible types:

  • name name-string value value-string

  • name name-string address ip-address

  • name name-string decimal decimal

  • name name-string number value-number

  • name name-string prefix ip-prefix/ip-prefix-length

Depending on the parameter referenced, specify the correct type as follows:

  • value-string: as-path, as-path-group, community, prefix-list, damping

  • ip-address: next-hop

  • value-number: aigp-metric, as-path-length, as-path-prepend, community-count, local-preference, metric, origin, origin-validation, preference, tag, type

The logical flow of this is to configure a policy per peer, in which the variable names and values are defined. Using Route policy parameterization using sub-policies as the example, the following configuration is applied.

Routing policy parameterization using sub-policies (MD-CLI)

[ex:/configure policy-options]
A:admin@node-2# info
    as-path "as63535" {
        expression "^63535$"
    }
    as-path "as64535" {
        expression "^64535$"
    }
    as-path "as65535" {
        expression "^65535$"
    }
    community "cm-as63535" {
        member "7750:63535" { }
    }
    community "cm-as64535-highpref" {
        member "7777:64535" { }
    }
    community "cm-as64535-rejects" {
        member "64535:14" { }
    }
    community "cm-as65535" {
        member "7750:65535" { }
    }
    community "cm-as65535-rejects" {
        member "65535:14" { }
    }
    prefix-list "pfx-as63535" {
        prefix 6.3.5.0/24 type through {
            through-length 32
        }
    }
    prefix-list "pfx-as64535" {
        prefix 6.4.5.0/24 type through {
            through-length 32
        }
    }
    prefix-list "pfx-as65535" {
        prefix 6.5.5.0/24 type through {
            through-length 32
        }
    }
    policy-statement "peer1" {
        entry 5 {
            from {
                policy "std-peering-inbound-drop"
                policy-variables {
                    name "@cm-reject@" {
                        value "cm-as65535-rejects"
                    }
                }
            }
            action {
                action-type reject
            }
        }
        entry 10 {
            from {
                policy "std-peering-inbound-main"
                policy-variables {
                    name "@cm-highpref@" {
                        value "cm-as65535-highpref"
                    }
                    name "@localcm@" {
                        value "cm-as65535"
                    }
                    name "@peer-as@" {
                        value "as65535"
                    }
                    name "@peer-prefix@" {
                        value "pfx-as65535"
                    }
                }
            }
            action {
                action-type accept
            }
        }
    }
    policy-statement "peer2" {
        entry 5 {
            from {
                policy "std-peering-inbound-drop"
                policy-variables {
                    name "@cm-reject@" {
                        value "cm-as64535-rejects"
                    }
                }
            }
            action {
                action-type reject
            }
        }
        entry 10 {
            from {
                policy "std-peering-inbound-main"
                policy-variables {
                    name "@cm-highpref@" {
                        value "cm-as64535-highpref"
                    }
                    name "@localcm@" {
                        value "cm-as64535"
                    }
                    name "@peer-as@" {
                        value "as64535"
                    }
                    name "@peer-prefix@" {
                        value "pfx-as64535"
                    }
                }
            }
            action {
                action-type accept
            }
        }
    }
    policy-statement "peer3" {
        entry 5 {
            from {
                policy "std-peering-inbound-drop"
                policy-variables {
                    name "@cm-reject@" {
                        value "cm-as63535-rejects"
                    }
                }
            }
            action {
                action-type reject
            }
        }
        entry 10 {
            from {
                policy "std-peering-inbound-main"
                policy-variables {
                    name "@cm-highpref@" {
                        value "cm-as63535-highpref"
                    }
                    name "@localcm@" {
                        value "cm-as63535"
                    }
                    name "@peer-as@" {
                        value "as63535"
                    }
                    name "@peer-prefix@" {
                        value "pfx-as63535"
                    }
                }
            }
            action {
                action-type accept
            }
        }
    }
    policy-statement "std-peering-inbound-drop" {
        entry 10 {
            from {
                community {
                    name "@cm-reject@"
                }
            }
            action {
                action-type accept
            }
        }
        default-action {
            action-type reject
        }
    }
    policy-statement "std-peering-inbound-main" {
        entry 10 {
            from {
                prefix-list ["@peer-prefix@"]
                as-path {
                    name "@peer-as@"
                }
            }
            action {
                action-type accept
                local-preference 400
                community {
                    add ["@localcm@"]
                }
            }
        }
        entry 20 {
            from {
                community {
                    name "@cm-highpref@"
                }
            }
            action {
                action-type accept
                local-preference 4000
                community {
                    add ["@localcm@"]
                }
            }
        }
        default-action {
            action-type reject
        }
    }

Routing policy parameterization using sub-policies (classic CLI)

A:node-2>config>router>policy-options# info
----------------------------------------------
prefix-list "pfx-as63535"
    prefix 6.3.5.0/24 through 32
exit
prefix-list "pfx-as64535"
    prefix 6.4.5.0/24 through 32
exit
prefix-list "pfx-as65535"
    prefix 6.5.5.0/24 through 32
exit
community "cm-as63535" 
    members "7750:63535
exit
community "cm-as65535" 
    members "7750:65535"
exit
community "cm-as64535-rejects" 
    members "64535:14"
exit
community "cm-as-65535-rejects" 
    members "65535:14"
exit
community "cm-as64535-highpref" 
    members "7777:64535"
exit
as-path "as63535" 
    expression "^63535$"
exit
as-path "as64535" 
    expression "^64535$"
exit
as-path "as65535"
    expression "^65535$"
exit
policy-statement "peer1"
    entry 5
        from
            policy-variables
                name "@cm-reject@" value "cm-as65535-rejects"
            exit
            prefix-list "pfx-as64535"
                prefix 6.4.5.0/24 through 32
            exit
            policy "std-peering-inbound-main"
        exit
        action accept
        exit
    exit
exit
policy-statement "peer2"
    entry 5
        from
            policy-variables
                name "@cm-reject@" value "cm-as64535-rejects"
            exit
            community "cm-as63535"
                members "7750:63535"
            exit
            policy "std-peering-inbound-main"
        exit
        action accept
        exit
    exit
exit
policy-statement "peer3"
    entry 5
        from
            policy-variables
                name "@cm-reject@" value "cm-as63535-rejects"
            community "cm-as64535-rejects"
                members "64535:14"
            exit
            policy "std-peering-inbound-main"
        exit
        action accept
        exit
    exit
exit
policy-statement "std-peering-inbound-drop"
    default-action reject
    entry 10
        from
            community "@cm-reject@"
        exit
        action accept
    exit
policy-statement "std-peering-inbound-main"
    default-action reject
    entry 10
        from
            prefix-list "@peer-prefix@"
            as-path "@peer-as@"
        exit
        action accept
            community add "@localcm@"
            local-preference 400
        exit
    exit
    entry 20
        from
            community "@cm-highpref@"
        exit
        action accept
            community add "@localcm@"
            local-preference 4000
        exit
    exit
exit

This configuration would take slightly different actions depending on the peer.

Peer 1

  • Routes that have a community matching ‟cm-as65535-rejects” are dropped.

  • Routes matching the prefix list ‟pfx-as65535” that originated in the peer AS=65535 are accepted with a local preference of 400.

  • Community ‟7750:65535” is added to accepted prefixes.

  • As community-list ‟cm-65535-highpref” does not exist, no routes are modified with a local preference of 4000.

Peer 2

  • Routes that have a community matching ‟cm-as64535-rejects” are dropped.

  • Routes matching the prefix list ‟pfx-as65535” that originated in the peer AS=65535 are accepted with a local preference of 400.

  • Prefixes matching ‟cm-as64535-highpref” are set to a local-preference of 4000.

Peer 3

  • As community-list ‟cm-as63535-rejects” does not exist, no routes are dropped by the first entry.

  • Routes matching the prefix list ‟pfx-as63535” that originated in the peer AS=63535 are accepted with a local preference of 400.

  • Community ‟7750:63535” is added to accepted prefixes.

  • As community-list ‟cm-63535-highpref” does not exist, no routes are modified with a local preference of 4000.

When to use route policies

The following are examples of circumstances of when to configure and apply unique route policies.

  • When you want to control the protocol to allow all routes to be imported into the routing table. This enables the routing table to learn about particular routes to enable packet forwarding and redistributing packets into other routing protocols.

  • When you want to control the exporting of a protocol’s learned active routes.

  • When you want a routing protocol to announce active routes learned from another routing protocol, which is sometimes called route redistribution.

  • When you want unique behaviors to control route characteristics. For example, change the route preference.

  • When you want unique behaviors to control route characteristics. For example, change the route preference, AS path, or community values to manipulate the control the route selection.

  • When you want to control BGP route flapping (damping).

Configuration notes

This section describes route policy configuration restrictions.

General

When configuring policy statements, the policy statement name must be unique.

Policy reference checks

Note: This information applies only to the classic CLI.

In the classic CLI, use the following command to enable the policy reference checks feature.

configure router policy-reference-checks

The policy-reference-checks command checks policy references to ensure that a policy exists and displays a CLI error if the policy does not exist.

Note: The policy reference checks feature is available only in the classic CLI and not through SNMP or model-driven interfaces. Model-driven interfaces and mixed management interface configuration mode use strict policy reference checks, starting in Release 16.0.R3, where the checks cannot be disabled.

If a policy is referenced, and it has not yet been configured, and no policy-reference-checks is configured, the configuration line succeeds with the following CLI message.

WARNING: CLI Policy "bar" does not exist

If a policy is referenced, and it has not yet been configured, and policy-reference-checks is configured, the configuration line errors and fails with the following CLI message.

MINOR: CLI Policy "foo" does not exist

In the classic CLI, policy reference checks are required in router configuration contexts that reference a policy name, including the following.

configure router bgp export
configure router bgp group export
configure router bgp group import
configure router bgp group neighbor export
configure router bgp group neighbor import
configure router bgp import
configure service vprn bgp export
configure service vprn bgp group export
configure service vprn bgp group import
configure service vprn bgp group neighbor export
configure service vprn bgp group neighbor import
configure service vprn bgp import
configure service vprn vrf-export
configure service vprn vrf-import

In the classic CLI, policy reference checks are required in policy configuration contexts that reference a policy element, including the following.

configure router policy-options policy-statement entry from flow-spec-dest
configure router policy-options policy-statement entry from flow-spec-source
configure router policy-options policy-statement entry from group-address
configure router policy-options policy-statement entry from host-ip
configure router policy-options policy-statement entry from neighbor
configure router policy-options policy-statement entry from next-hop
configure router policy-options policy-statement entry from prefix-list
configure router policy-options policy-statement entry from source-address
configure router policy-options policy-statement entry to neighbor
configure router policy-options policy-statement entry to prefix-list
configure router policy-options as-path
configure router policy-options as-path-group
configure router policy-options community
configure router policy-options damping
Note: Policy reference checks are also required in policy statements used in sub-policies.

Known limitations

Note: This information applies only to the classic CLI.

Policy elements must be entered in the correct order to resolve references. For example, if a prefix list is referenced in a policy statement, the prefix list must be entered first. This feature does not order policy statements so that references to policy elements exist.

Variable expansion is not supported with the policy reference checks feature. Variables that reference policy elements that do not exist are not checked and are permitted.

This feature is available only for configuring policies. If a policy is deleted, the command succeeds with no info or warning messages displayed. In the classic CLI, use the following command to display warnings for elements that do not exist.

show router policy-edits

The policy reference checks functionality is not supported with policy expressions.

Configuring route policies with CLI

This section provides information to configure route policies.

Route policy configuration overview

Route policies allow you to configure routing according to specifically defined policies. You can create policies and entries to allow or deny paths based on various command options, such as destination address, protocol, packet size, and community list.

Policies can be as simple or complex as required. A simple policy can block routes for a specific location or IP address. More complex policies can be configured using numerous policy statement entries containing matching conditions to specify whether to accept or reject the route, control how a series of policies are evaluated, and manipulate the characteristics associated with a route.

When to create routing policies

Use the commands in the following context to configure route policies:

  • MD-CLI

    configure policy-options policy-statement
  • classic CLI

    configure router policy-options policy-statement

There are no default route policies. Each route policy must be explicitly created and applied. Applying route policies can introduce more efficiency as well as more complexity to routers.

A route policy impacts the flow of routing information or packets within and through the router. A routing policy can be specified to prevent a particular customer’s routes from being placed in the route table, which causes those routes not to forward traffic to various destinations, and the routes are not advertised by the routing protocol to neighbors.

Route policies can be created to control the following:

  • a protocol to export all the active routes learned by that protocol

  • route characteristics to control which route is selected to act as the active route to reach a destination and advertise the route to neighbors

  • protocol to import all routes into the routing table. A routing table must learn about particular routes to be able to forward packets and redistribute to other routing protocols

  • damping

If no protocol is specified in a policy, all protocols will match.

Before a route policy is applied, analyze the purpose of the policy and be aware of the results (and consequences) when packets match the specified criteria and the associated actions and default actions (if specified) are executed. Membership reports can be filtered based on a specific source address.

Default route policy actions

Each routing protocol has default behaviors for the import and export of routing information. Default route policy actions shows the default behavior for each routing protocol.

Table 6. Default route policy actions
Protocol Import Export

OSPF

Not applicable. All OSPF routes are accepted from OSPF neighbors and cannot be controlled via route policies.

  • Internal routes: All OSPF routes are automatically advertised to all neighbors.

  • External routes: By default, all non-OSPF learned routes are not advertised to OSPF neighbors.

IS-IS

Not applicable. All IS-IS routes are accepted from IS-IS neighbors and cannot be controlled via route policies

  • Internal routes: All IS-IS routes are automatically advertised to all neighbors.

  • External routes: By default, all non-IS-IS learned routes are not advertised to IS-IS peers.

RIP

By default, all RIP-learned routes are accepted.

External routes: By default, all non-RIP learned routes are not advertised to RIP peers.

BGP

By default, all routes from BGP peers are accepted and passed to the BGP route selection process.

  • Internal routes: By default, all active BGP routes are advertised to BGP peers.

  • External routes: By default, all non-BGP learned routes are not advertised to BGP peers.

Policy evaluation

Routing policy statements can consist of as few as one or several entries. The entries specify the matching criteria. A route is compared to the first entry in the policy statement. If it matches, the specified entry action is taken, either accepted or rejected. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends.

If the route does not match the first entry, the route is compared to the next entry (if more than one is configured) in the policy statement. If there is a match with the second entry, the specified action is taken. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends, and so on.

Each route policy statement can have a default-action clause defined. If a default action is defined for one or more of the configured route policies, the default actions should be handled as follows:

  • The process stops when the first complete match is found and executes the action defined in the entry.

  • If the packet does not match any of the entries, the system executes the default action specified in the policy statement.

Route policy process example shows an example of the route policy process.

Use the following command option to configure the route policy to match a specific route policy entry and continue to search for other entries within the same route policy:

  • MD-CLI

    configure policy-options policy-statement entry action action-type next-entry
  • classic CLI

    configure router policy-options policy-statement entry action next-entry

Use the following command option to configure the route policy to match a specific route policy entry and continue to search for other entries within the next route policy:

  • MD-CLI

    configure policy-options policy-statement entry action action-type next-policy
  • classic CLI

    configure router policy-options policy-statement entry action next-policy

Policies can be constructed to support multiple states to the evaluation and setting of various route attributes.

Next policy logic example shows the next-policy and next-entry route processes.

Figure 6. Route policy process example

For the default route policy actions, see Default route policy actions.

Figure 7. Next policy logic example

Damping

Damping initiates controls when routes flap. Route flapping can occur when an advertised route between nodes alternates (flaps) back and forth between two paths because of network problems which cause intermittent route failures. It is necessary to reduce the amount of routing state change updates propagated to limit processing requirements. Thus, when a route flaps beyond a configured value (the suppress value), then that route is removed from the routing tables and routing protocols until the value falls below the reuse value.

A route can be suppressed according to the Figure of Merit (FoM) value. The FoM is a value that is added to a route each time it flaps. A new route begins with an FoM value of 0.

Damping is optional. If damping is configured, the following command values must be explicitly specified, as there are no default values:

  • MD-CLI

    configure policy-options damping suppress
    configure policy-options damping half-life
    configure policy-options damping reuse
    configure policy-options damping max-suppress
  • classic CLI

    configure router policy-options damping suppress
    configure router policy-options damping half-life
    configure router policy-options damping reuse
    configure router policy-options damping max-suppress

When the FoM value of a route exceeds the suppress value, the route is removed from the routing table. The route is considered to be stable when the FoM drops below the reuse value by means of the specified half-life. The route is returned to the routing tables. When routes have higher FoM and half-life values, they are suppressed for longer periods of time. Damping example depicts an example of a flapping route, the suppress threshold, the half-life decay (time), and reuse threshold. The peaks represent route flaps, the slopes represent half-life decay.

Figure 8. Damping example

Basic configurations

This section describes how to configure route policies and provides configuration examples of common tasks. The following are the minimum route policy command options required for a policy statement:

  • at least one entry

  • entry action

The following example shows a route-policy configuration.

MD-CLI

[ex:/configure policy-options]
A:admin@node-2# info
    as-path "Outside Internet paths" {
        expression ".* 5002 .*"
    }
    as-path "Outside madeup paths" {
        expression ".* 5001 .*"
    }
    community "all-customer-announce" {
    }
    community "all-normal" {
        member "5000:[1-5][1-9][0-9]" { }
    }
    community "all-types" {
        member "5000:[1-6][1-9][0-9]" { }
    }
    policy-statement "RejectOutsideAsPaths" {
        entry 1 {
            from {
                as-path {
                    name "Outside madeup paths"
                }
                protocol {
                    name [bgp]
                }
            }
            to {
            }
            action {
                action-type reject
            }
        }
        entry 2 {
            from {
                protocol {
                    name [bgp]
                }
            }
        }
        entry 3 {
            from {
                protocol {
                    name [ospf]
                }
            }
            to {
                protocol {
                    name [bgp]
                }
            }
            action {
                action-type reject
            }
        }
        entry 4 {
            from {
                protocol {
                    name [isis]
                }
            }
            action {
                action-type reject
            }
        }
        default-action {
            action-type accept
        }
    }
    policy-statement "aggregate-customer-peer-only" {
        entry 1 {
            from {
                community {
                    name "all-customer-announce"
                }
            }
            action {
                action-type accept
            }
        }
        default-action {
            action-type accept
        }
    }

classic CLI

A:node-2>config>router>policy-options# info
----------------------------------------------
            community "all-types"
                members "5000:[1-6][1-9][0-9]"
            exit
            community "all-normal"
                members "5000:[1-5][1-9][0-9]"
            exit
            community "all-customer-announce"
            exit
            as-path "Outside madeup paths"
                expression ".* 5001 .*"
            exit
            as-path "Outside Internet paths"
                expression ".* 5002 .*"
            exit
            policy-statement "RejectOutsideAsPaths"
                entry 1
                    from
                        protocol bgp
                        as-path "Outside madeup paths"
                    exit
                    to
                    exit
                    action drop
                    exit
                exit
                entry 2
                    from
                        protocol bgp
                    exit
                exit
                entry 3
                    from
                        protocol ospf
                    exit
                    to
                        protocol bgp
                    exit
                    action drop
                    exit
                exit
                entry 4
                    from
                        protocol isis
                    exit
                    action drop
                    exit
                exit
                default-action accept
                exit
            exit
            policy-statement "aggregate-customer-peer-only"
                entry 1
                    from
                        community "all-customer-announce"
                    exit
                    action accept
                    exit
                exit
                default-action accept
                exit
            exit
----------------------------------------------

Configuring route policy components

This section describes how to configure route policy components.

Note: The MD-CLI has significant differences from the classic CLI for configuring route policy components. In the MD-CLI, there is no separate transaction (begin or commit) for the policy changes. Also, the MD-CLI supports policy statements with named entries (see Policy statements for information about policy statements).

Beginning the policy statement in the classic CLI

In the classic CLI, before creating a route policy or configuring route policy components, use the following command to enter edit mode.

configure router policy-options begin

The following error message displays when you try to modify policy options without entering begin first.

A:node-2>config>router>policy-options# policy-statement ‟allow all”
MINOR: CLI The policy-options must be in edit mode by calling begin before any changes can be made.

The following are other editing commands available in the classic CLI:

  • commit

    This command saves changes made to route policies during a session.

  • abort

    This command discards changes that have been made to route policies during a session.

There are no default policy statement command options. All command options must be explicitly configured.

Creating a route policy

Note: In the classic CLI, before creating a route policy statement, you must enter edit mode, as described in Beginning the policy statement in the classic CLI.

Use the following command to create a route policy statement:

  • MD-CLI

    configure policy-options policy-statement
  • classic CLI

    configure router policy-options policy-statement

Use the following command to configure a text description for the route policy statement:

  • MD-CLI

    configure policy-options policy-statement description
  • classic CLI

    configure router policy-options policy-statement description
Note: For a policy statement to be complete, an entry must also be specified (see Configuring an entry for more information).

Configuring a default action

Specifying a default action is optional. The default action controls those packets not matching any policy statement entries. If no default action is specified for the policy, then the action associated with the protocol to which the routing policy was applied is performed. The default action is applied only to those routes that do not match any policy entries.

A policy statement must include at least one entry (see Configuring an entry).

Note: In the classic CLI, before configuring a default action, you must enter edit mode, as described in Beginning the policy statement in the classic CLI.

Use the commands in the following context to configure a default action:

  • MD-CLI

    configure policy-options policy-statement default-action
  • classic CLI

    configure router policy-options policy-statement default-action

The following example displays a default-action configuration.

MD-CLI
[ex:/configure policy-options]
A:admin@node-2# info
...
    policy-statement "1" {
        default-action {
            action-type accept
            damping "flaptest"
            next-hop 10.10.10.104
            as-path {
                add "test"
            }
            community {
                add ["365"]
            }
        }
    }
classic CLI
A:node-2>config>router>policy-options# info
----------------------------------------------
...
            policy-statement "1"
                default-action accept
                    as-path add "test"
                    community add "365"
                    damping "flaptest"
                    next-hop 10.10.10.104
                exit
            exit
----------------------------------------------

Configuring an entry

Note: In the classic CLI, before configuring an entry, you must enter edit mode, as described in Beginning the policy statement in the classic CLI.

Use the following command to configure an entry for the route policy statement:

  • MD-CLI

    configure policy-options policy-statement entry
  • classic CLI

    configure router policy-options policy-statement entry

An entry action must be specified. Use the following command to specify an entry action:

  • MD-CLI

    configure policy-options policy-statement entry action action-type
  • classic CLI

    configure router policy-options policy-statement entry action

The other commands in the action context are optional.

The following example displays entry command option configurations and includes the default-action configuration that is shown in Configuring a default action.

MD-CLI
[ex:/configure policy-options]
A:admin@node-2# info
...
    policy-statement "1" {
        entry 1 {
            to {
                neighbor {
                    ip-address 10.10.10.104
                }
            }
            action {
                action-type accept
            }
        }
        entry 2 {
            from {
                protocol {
                    name [ospf]
                    instance 1
                }
            }
            to {
                neighbor {
                    ip-address 10.10.0.91
                }
                protocol {
                    name [ospf]
                }
            }
            action {
                action-type accept
            }
        }
        default-action {
            action-type accept
            damping "flaptest"
            next-hop 10.10.10.104
            as-path {
                add "test"
            }
            community {
                add ["365"]
            }
        }
    }
classic CLI
A:node-2>config>router>policy-options# info
----------------------------------------------
...
            policy-statement "1"
                entry 1
                    to
                        neighbor 10.10.10.104
                    exit
                    action accept
                    exit
                exit
                entry 2
                    from
                        protocol ospf instance 1
                    exit
                    to
                        protocol ospf
                        neighbor 10.10.0.91
                    exit
                    action accept
                    exit
                exit
                default-action accept
                    as-path add "test"
                    community add "365"
                    damping "flaptest"
                    next-hop 10.10.10.104
                exit
            exit
----------------------------------------------

The following example displays entry command option configurations and includes the default-action configuration that is shown in Configuring a default action.

MD-CLI
[ex:/configure policy-options]
A:admin@node-2# info
...
    policy-statement "1" {
        entry 1 {
            to {
                neighbor {
                    ip-address 10.10.10.104
                }
                protocol {
                    name [bgp]
                }
            }
            action {
                action-type accept
            }
        }
        entry 2 {
            from {
                protocol {
                    name [ospf]
                    instance 1
                }
            }
            to {
                neighbor {
                    ip-address 10.10.0.91
                }
                protocol {
                    name [ospf]
                }
            }
            action {
                action-type accept
            }
        }
        default-action {
            action-type accept
            damping "flaptest"
            next-hop 10.10.10.104
            as-path {
                add "test"
            }
            community {
                add ["365"]
            }
        }
    }
classic CLI
A:node-2>config>router>policy-options# info
----------------------------------------------
...
            policy-statement "1"
                entry 1
                    to
                        protocol bgp
                        neighbor 10.10.10.104
                    exit
                    action accept
                    exit
                exit
                entry 2
                    from
                        protocol ospf instance 1
                    exit
                    to
                        protocol ospf
                        neighbor 10.10.0.91
                    exit
                    action accept
                    exit
                exit
                default-action accept
                    as-path add "test"
                    community add "365"
                    damping "flaptest"
                    next-hop 10.10.10.104
                exit
            exit
----------------------------------------------

Configuring a community list

Community lists are composed of a group of destinations which share a common property. Community lists allow you to administer actions on a configured group instead of having to execute identical commands for each member.

Note: In the classic CLI, before configuring community lists, you must enter edit mode, as described in Beginning the policy statement in the classic CLI.

Use the commands in the following context to configure community lists:

  • MD-CLI

    configure policy-options community
  • classic CLI

    configure router policy-options community

The following example displays a community list configuration.

MD-CLI
[ex:/configure policy-options]
A:admin@node-2# info
    community "eastern" {
        member "100:200" { }
    }
    community "headquarters" {
        member "100:1000" { }
    }
    community "northern" {
        member "100:400" { }
    }
    community "southern" {
        member "100:500" { }
    }
    community "western" {
        member "100:300" { }
    }
    policy-statement "1" {
        entry 1 {
            to {
                neighbor {
                    ip-address 10.10.10.104
                }
                protocol {
                    name [bgp]
                }
            }
            action {
                action-type accept
            }
        }
    }
classic CLI
A:node-2>config>router>policy-options# info
----------------------------------------------
            community "eastern"
                members "100:200"
            exit
            community "western"
                members "100:300"
            exit
            community "northern"
                members "100:400"
            exit
            community "southern"
                members "100:500"
            exit
            community "headquarters"
                members "100:1000"
            exit
            policy-statement "1"
                entry 1
                    to
                        protocol bgp
                        neighbor 10.10.10.104
                    exit
                    action accept
                    exit
                exit
            exit
----------------------------------------------

Configuring damping

The following considerations apply for damping:

  • For each damping profile, all command options must be configured.

  • The value of the suppress command must be greater than that of the reuse command (see Damping example).

  • Damping can be enabled at the global BGP level, BGP group level, and BGP neighbor level.

    Use the following command to enable damping at the global BGP level.

    configure router bgp damping

    Use the following command to enable damping at the BGP group level.

    configure router bgp group damping

    Use the following command to enable damping at the BGP neighbor level:

    • MD-CLI

      configure router bgp neighbor damping
    • classic CLI

      configure router bgp group neighbor damping

    Use the commands in the following context to configure a damping profile:

    Note: In the classic CLI, before configuring a damping profile, you must enter edit mode, as described in Beginning the policy statement in the classic CLI.
    • MD-CLI

      configure router bgp neighbor damping
    • classic CLI

      configure router policy-options damping

    If damping is enabled, but the route policy does not specify a damping profile, the default damping profile is used. This profile is always present and its command default values are configured as follows:

    • half-life – 15 minutes

    • max-suppress – 60 minutes

    • suppress – 3000

    • reuse – 750

The following example displays a damping configuration.

MD-CLI
[ex:/configure policy-options]
A:admin@node-2# info
    damping "damptest123" {
        half-life 15
        max-suppress 60
        reuse 750
        suppress 1000
    }
classic CLI
A:node-2>config>router>policy-options# info
----------------------------------------------
            damping "damptest123"
                half-life 15
                max-suppress 60
                reuse 750
                suppress 1000
            exit
----------------------------------------------

Configuring a prefix list

Note: In the classic CLI, before configuring prefix lists, you must enter edit mode, as described in Beginning the policy statement in the classic CLI.

Use the commands in the following context to configure prefix lists:

  • MD-CLI

    configure policy-options prefix-list
  • classic CLI

    configure router policy-options prefix-list

The following example displays a prefix list configuration.

MD-CLI
[ex:/configure policy-options]
A:admin@node-2# info
    damping "damptest123" {
        half-life 15
        max-suppress 60
        reuse 750
    }
    prefix-list "western" {
        prefix 10.10.0.1/32 type exact {
        }
        prefix 10.10.0.2/32 type exact {
        }
        prefix 10.10.0.3/32 type exact {
        }
        prefix 10.10.0.4/32 type exact {
        }
    }
classic CLI
A:node-2>config>router>policy-options# info
----------------------------------------------
            prefix-list "western"
                prefix 10.10.0.1/32 exact
                prefix 10.10.0.2/32 exact
                prefix 10.10.0.3/32 exact
                prefix 10.10.0.4/32 exact
            exit
            damping "damptest123"
                half-life 15
                max-suppress 60
                reuse 750
            exit
----------------------------------------------

Route policy configuration management tasks

This section discusses route policy configuration management tasks.

Editing policy statements in the classic CLI

Route policy statements can be edited to modify, add, or delete options.

In the classic CLI, to enter the mode to edit route policies, you must enter the begin keyword at the config>router> policy-options prompt. Other editing commands include:

  • the commit command saves changes made to route policies during a session

  • the abort command discards changes that have been made to route policies during a session

The following example displays a changed configuration:

classic CLI

A:node-2config>router>policy-options>policy-statement# info
----------------------------------------------
                description "Level 1"
                entry 1
                    to
                        protocol ospf
                        neighbor 10.10.10.104
                    exit
                    action accept
                    exit
...
A:node-2>config>router>policy-options# begin
*A:node-2>config>router>policy-options# policy-statement "Level 1"
*A:node-2>config>router>policy-options>policy-statement$ entry 1
*A:Dut-AE>config>router>policy-options>policy-statement>entry$ to protocol bgp
*A:Dut-AE>config>router>policy-options>policy-statement>entry# exit
*A:Dut-AE>config>router>policy-options>policy-statement# exit
*A:Dut-AE>config>router>policy-options# commit
A:node-2config>router>policy-options>policy-statement# info
----------------------------------------------
                description "Level 1"
                entry 1
                    to
                        protocol bgp
                        neighbor 10.10.10.104
                    exit
                    action accept
                    exit
                exit
                entry 2
                    from
                        protocol ospf
                    exit
                    to
                        protocol ospf
                        neighbor 10.10.0.91
                    exit
                    action accept
                    exit
                exit
...
----------------------------------------------

Deleting an entry

In the classic CLI, before deleting a route policy statement entry, you must enter edit mode, as described in Beginning the policy statement in the classic CLI.

Use the following command to delete a policy statement entry:

  • MD-CLI

    configure policy-options policy-statement delete entry
  • classic CLI

    configure router policy-options policy-statement no entry

Deleting a policy statement

In the classic CLI, before deleting a route policy statement, you must enter edit mode, as described in Beginning the policy statement in the classic CLI.

Use the following command to delete a policy statement:

  • MD-CLI

    configure policy-options delete policy-statement
  • classic CLI

    configure router policy-options no policy-statement