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.