Route policies

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.

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

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

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

• If the evaluation of a policy terminates with an action accept, action next-entry or action next-policy, the result is TRUE. If the evaluation of a policy terminates with an action reject or action drop, then 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.

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.

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/export) and the destination and/or source protocol.

Operators can evaluate a routing policy against a BGP neighbor, routing context, or individual prefix before applying the policy to the neighbor or routing context. This command displays prefixes that are rejected by a policy and what modifications are made by a policy.

Operators can set an exclusive lock on policy edit sessions. When the exclusive flag is set by an operator 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.

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

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.

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 parameters:

• 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 two events that could trigger the route flapping algorithm are:

• 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, looks like a sawtooth waveform with the exponential rise and decay of FoM. To control flapping, the following parameters 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.

• max-suppress

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

• suppress

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

• reuse

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

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

  

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.

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

Triggered policy is not honored if a new peer added to BGP. Update with the old policy is sent to the newly added peer. 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, new addition or modification of an export policy causes the updates to send out dynamically to all peers with the new/modified export policy.

When multiple peers, say P1, P2 and P3 share the same export policy, any modifications to export policy followed by clear soft on one of the peer P1, send out routes to P1 only according to newly modified policy.

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

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 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/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 clear soft 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 clear soft issues 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.

This feature sets MED to the IGP cost of a route exported into BGP as an action in route policies. The med-out command in the bgp, group, and neighbor configuration context supports this option, but this method lacks per-prefix granularity. The enhanced metric command supported as a route policy action supports setting MED to a fixed number, or adding, or subtracting a fixed number from the received MED, and sets IGP cost option. The enhanced metric {set {igp | number1} | {add | subtract} number2} command is under config>router>policy-options>policy-statement>entry>action.

The metric set igp command, when used in a BGP export policy, have the same effect as the current med-out igp command, except that it applies only to the routes matched by the policy entry.

The effect of the metric set igp command depends on the route type and policy type as summarized in Metric set IGP effect.

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.

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.

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. Information from the show router policy-edits command can be used to see warnings about which elements do not exist.

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

Route policies are created in the config>router context. 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 to be placed in the route table which causes those routes to not forward traffic to various destinations and the routes are not advertised by the routing protocol to neighbors.

Route policies can be created to control:

• 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

Before a route policy is applied, analyze the policy’s purpose 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.

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.

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, then the default actions should be handled in the following ways.

• 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 depicts an example of the route policy process.

Route policies can also match a specific route policy entry and continue to search for other entries within either the same route policy or the next route policy by specifying the next-entry or next-policy option in the entry’s action command. Policies can be constructed to support multiple states to the evaluation and setting of various route attributes.

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

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

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 parameter values must be explicitly specified as there are no default values:

• suppress

• half-life

• reuse

• max-suppress

When a route's FoM value exceeds the suppress value, then 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 parameter. 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.

Use the following CLI syntax to begin a policy statement configuration. In order for a policy statement to be complete an entry must be specified (see Configuring an entry).

config>router>policy-options
  begin
    policy-statement name
      description text

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

A:ALA-B>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 example displays policy statement configuration command usage. These commands are configured in the config>router context.

Example:

config>router# policy-options
policy-options# begin

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

To enter the mode to create or 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 error message displays when you try to modify a policy options command without entering begin first.

A:ALA-B>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.

A:ALA-B>config>router>policy-options# info
#------------------------------------------
# Policy
#------------------------------------------

        policy-options
            begin
            policy-statement "allow all"
description "General Policy"
...
            exit
exit
----------------------------------------------
A:ALA-B>config>router>policy-options#

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

To enter the mode to create or 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 the default action configuration:

A:ALA-B>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
----------------------------------------------
A:ALA-B>config>router>policy-options#

An entry action must be specified. The other parameters in the entry action context are optional.

The following example displays entry parameters and includes the default action parameters which were displayed in the previous section.

A:ALA-B>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 1
                    exit
                    to
                        protocol ospf
                        neighbor 10.10.0.91
                    exit
                    action accept
                    exit
                exit
                default-action accept
                    . . .
                exit
            exit

The following example displays entry parameters and includes the default action parameters which were displayed in the previous section.

A:ALA-B>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 1
                    exit
                    to
                        protocol ospf
                        neighbor 10.10.0.91
                    exit
                    action accept
                    exit
                exit
                default-action accept
                    . . .
                exit
            exit

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.

The following example displays a community list configuration:

A:ALA-B>config>router>policy-options# info 
----------------------------------------------
community "eastern" members "100:200"
community "western" members "100:300"
community "northern" members "100:400"
community "southern" members "100:500"
community "headquarters" members "100:1000"
policy-statement "1"
                entry 1
                    to
                        protocol bgp
                        neighbor 10.10.10.104
                    exit
                    action accept
. . . 
----------------------------------------------
A:ALA-B>config>router>policy-options#

The following considerations apply.

• For each damping profile, all parameters must be configured.

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

• Damping can be enabled in the config>router>bgp context on the BGP global, group, and neighbor levels. If damping is enabled, but route policy does not specify a damping profile, the default damping profile is used. This profile is always present and consists of the following parameters:

  • half-life: 15 minutes

  • max-suppress: 60 minutes

  • suppress: 3000

  • reuse: 750

The following example displays a damping configuration:

*A:cses-A13>config>router>policy-options# info
----------------------------------------------
            damping "damptest123"
                half-life 15
                max-suppress 60
                reuse 750
                suppress 1000
            exit
----------------------------------------------
*A:cses-A13>config>router>policy-options#

The following example displays a prefix list configuration:

A:ALA-B>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  
----------------------------------------------
A:ALA-B>config>router>policy-options#