Policy Chaining and Logical Expressions
This chapter provides information about policy chaining and logical expressions.
Topics in this chapter include:
Applicability
This chapter was initially written for SR OS Release 14.0.R4, but the MD-CLI in the current edition is based on SR OS Release 21.7.R1. In SR OS releases earlier than 14.0.R1, only policy chaining was supported. SR OS Release 14.0.R1 introduced support for route policy logical expressions using the logical operators AND, OR, and NOT, and parentheses.
Overview
Multiple policies can be chained together for sequential evaluation. For more complex evaluation logic, logical expressions can be used with operators: AND, OR, and NOT, and with parentheses. A logical expression can be included in a larger policy chain. Route policy logical expressions are supported in the following contexts:
-
BGP export
-
BGP import
-
BGP leak-import (RIB leaking)
-
VRF import
-
VRF export
-
GRT export (GRT leaking)
Policy chaining versus policy logical expressions shows a comparison between examples of policy chaining and policy logical expressions.
|
Policy chaining example |
Policy logical expressions example |
|---|---|
|
configure router bgp import policy ["A" "B" "C"] |
configure router bgp import policy "[A]OR[B]" |
|
For each route, policy A is evaluated first.
|
Several logical operators can be used. This example shows an OR relationship between policy A and policy B. For each route, policy A is evaluated first. A true/false result is determined for policy A:
The final result is mapped back to a policy action (accept, next-policy, and so on). |
To configure policy chaining that may or may not include a policy logical expression, the syntax is:
[ex:configure router "Base" bgp export]
A:admin@PE-1# policy
policy <value>
policy [<value>...] - 1..15 user-ordered values separated by spaces enclosed by
brackets
<value> - <string>
<string> - <1..255 characters>
Export policy name
When the import/export policy command has a single value, the value is either a policy or a logical expression. The policy may or may not be enclosed in double quotes. When enclosed in double quotes, all characters (including blanks) are considered part of the policy. The logical expression must be enclosed in double quotes. The logical expression accepts between 1 and 16 policies. In the logical expression:
-
each policy must be enclosed in square brackets and must not be enclosed in double quotes.
-
the operand may or may not be separated with spaces from the policies.
-
the operand must be in uppercase (AND, OR, NOT).
-
parentheses may be used to influence the logic. When used, nesting is limited to a maximum of 3 levels.
A policy is accepted with and without double quotes enclosing it.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy A
}
(leads to: ["A"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "A"
}
(leads to: ["A"])
In a policy that is enclosed in double quotes, spaces before and after the policy are not allowed, as they are considered part of the policy name. The following message is raised when spaces are present before and after a policy that is enclosed in double quotes.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy " A "
}
MINOR: MGMT_CORE #224: configure router "Base" bgp import policy - Entry does not exist - configure policy-options policy-statement " A "
A logical expression is accepted only when each policy is enclosed in square brackets and not in double quotes, while the logical expression itself is enclosed in double quotes.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "[A]AND[B]"
}
(leads to: ["[A]AND[B]"])
In a logical expression, spaces before and after the operand are allowed.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "[A] AND [B]"
}
(leads to: ["[A] AND [B]"])
In a logical expression, spaces before and after the square brackets that enclose a policy are allowed.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy " [A] AND [B] "
}
(leads to: [" [A] AND [B] "])
In a logical expression, spaces inside the square brackets that enclose a policy are allowed.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "[ A ]AND[ B ]"
}
(leads to: ["[ A ]AND[ B ]"])
The following message is raised when the logical expression is not enclosed in double quotes.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A]AND[B]
}
A:admin@PE-1# import policy [A]AND[B]
^^^
MINOR: MGMT_CORE #2201: Unknown element - 'AND'
The following message is raised when there are double quotes inside the square brackets that enclose a policy in a logical expression that is not enclosed in double quotes.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["A"]AND["B"]
}
A:admin@PE-1# import policy ["A"]AND["B"]
^^^
MINOR: MGMT_CORE #2201: Unknown element - 'AND'
The following message is raised when a policy is enclosed in double quotes instead of square brackets in a logical expression that is not enclosed in double quotes.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "A"AND"B"
}
A:admin@PE-1# import policy "A"AND"B"
^^^
MINOR: MGMT_CORE #2201: Unknown element - 'AND'
The following message is raised when there are double quotes inside the square brackets that enclose a policy in a logical expression.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "["A"]AND["B"]"
}
A:admin@PE-1# import policy "["A"]AND["B"]"
^
MINOR: MGMT_CORE #2201: Unknown element - 'A'
The following message is raised when a policy is enclosed in double quotes instead of square brackets in a logical expression.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ""A"AND"B""
}
A:admin@PE-1# import policy ""A"AND"B""
^
MINOR: MGMT_CORE #2301: Invalid element value - 'policy' expected string '<1..255 characters>' or reference '<1..64 characters>' (configure policy-options policy-statement <name>)
The operand in a logical expression must be in uppercase.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "[A]AND[B]"
}
(leads to: ["[A]AND[B]"])
The following message is raised when an operand in a logical expression is not in uppercase.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "[A]and[B]"
}
A:admin@PE-1# import policy "[A]and[B]"
^^^^^^^^^
MINOR: MGMT_CORE #2301: Invalid element value - 'policy' expected string '<1..255 characters>' or reference '<1..64 characters>' (configure policy-options policy-statement <name>)
A logical expression may use parentheses (nesting up to a maximum of 3 levels) to influence the logic.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "((([P1]AND[P2])OR[P3])AND[P4])OR[P5]"
}
(leads to: ["((([P1]AND[P2])OR[P3])AND[P4])OR[P5]"])
The following message is raised when the parentheses nesting exceeds 3 levels.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "(((([P1]AND[P2])OR[P3])AND[P4])OR[P5])AND[P6]"
}
A:admin@PE-1# import policy "(((([P1]AND[P2])OR[P3])AND[P4])OR[P5])AND[P6]"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
MINOR: MGMT_CORE #2301: Invalid element value - 'policy' expected string '<1..255 characters>' or reference '<1..64 characters>' (configure policy-options policy-statement <name>)
The following message is raised when the parentheses are not balanced.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "((([P1]AND[P2])OR[P3])AND[P4]"
}
A:admin@PE-1# import policy "((([P1]AND[P2])OR[P3])AND[P4]"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
MINOR: MGMT_CORE #2301: Invalid element value - 'policy' expected string '<1..255 characters>' or reference '<1..64 characters>' (configure policy-options policy-statement <name>)
A logical expression accepts a maximum of 16 policies.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "[P1]AND[P2]AND[P3]AND[P4]AND[P5]AND[P6]AND[P7]AND[P8]AND[P9]AND[P10]AND[P11]AND[P12]AND[P13]AND
[P14]AND[P15]AND[P16]"
}
(leads to: ["[P1]AND[P2]AND[P3]AND[P4]AND[P5]AND[P6]AND[P7]AND[P8]AND[P9]AND[P10]AND[P11]AND[P12]AND[P13]
AND[P14]AND[P15]AND[P16]"])
The following message is raised when there are too many policies in the logical expression.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy "[P1]AND[P2]AND[P3]AND[P4]AND[P5]AND[P6]AND[P7]AND[P8]AND[P9]AND[P10]AND[P11]AND[P12]AND[P13]
AND[P14]AND[P15]AND[P16]AND[P17]"
}
A:admin@PE-1# import policy "[P1]AND[P2]AND[P3]AND[P4]AND[P5]AND[P6]AND[P7]AND[P8]AND[P9]AND[P10]AND[P11]AND[P12]AND[P13]
AND[P14]AND[P15]AND[P16]AND[P17]"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
MINOR: MGMT_CORE #2301: Invalid element value - 'policy' expected string '<1..255 characters>' or reference '<1..64 characters>' (configure policy-options policy-statement <name>)
When the import/export policy command has multiple values, the values are separated with spaces and ordered in a policy chain that must be enclosed in square brackets. The policy chain accepts between 1 and 15 values. In the policy chain:
-
each value is either a policy or a logical expression and must be formatted in the same way as the single value above.
-
only 1 logical expression is allowed.
-
policies and the logical expression may be repeated. Only the first occurrence of duplicate policies and duplicate logical expressions is retained in the resulting policy chain.
-
a logical expression with a length that does not exceed 64 characters may be in any location. Otherwise, the logical expression with a length that does not exceed 255 characters must be in the first location.
A policy chain must be enclosed in square brackets.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A]
}
(leads to: ["A"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["A"]
}
(leads to: ["A"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A B]
}
(leads to: ["A" "B"])
The following message is raised when the policy chain is not enclosed in square brackets.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy A B
}
A:admin@PE-1# import policy A B
^
MINOR: MGMT_CORE #2201: Unknown element - 'B'
A policy chain is accepted with and without double quotes enclosing the policies.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A]
}
(leads to: ["A"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["A"]
}
(leads to: ["A"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A B]
}
(leads to: ["A" "B"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["A" B]
}
(leads to: ["A" "B"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A "B"]
}
(leads to: ["A" "B"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["A" "B"]
}
(leads to: ["A" "B"])
A policy chain can contain policies and a logical expression.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A B "[C]OR[A]"]
}
(leads to: ["A" "B" "[C]OR[A]"])
In a policy chain, policies and the logical expression may be repeated. Only the first occurrence of duplicate policies and duplicate logical expressions is retained in the resulting policy chain.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A A "A"]
}
(leads to: ["A"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [C A A C B A C B C A B C A]
}
(leads to: ["C" "A" "B"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [C A "A" "C" B A C "B" "C" "A" B C A]
}
(leads to: ["C" "A" "B"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["[A]AND[B]" "[A]AND[B]"]
}
(leads to: ["[A]AND[B]"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["[A]AND[B]" C "[A]AND[B]"]
}
(leads to: ["[A]AND[B]" "C"])
A policy chain accepts a maximum of 15 policies.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15]
}
(leads to: ["P1" "P2" "P3" "P4" "P5" "P6" "P7" "P8" "P9" "P10" "P11" "P12" "P13" "P14" "P15"])
The following message is raised when there are too many policies in the policy chain.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16]
}
MINOR: MGMT_CORE #253: configure router "Base" bgp import policy - Reached maximum number of entries - number of entries must be between 1-15 but has 16
A policy chain has 1 logical expression at maximum. The following message is raised when the policy chain has more than 1 (different) logical expression.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["[A]AND[B]" "[B]OR[C]"]
}
MINOR: BGP #12: configure router "Base" bgp import policy - Inconsistent Value error - Policy chain exceeds maximum number of expressions - configure
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["[A]AND[B]" C "[B]OR[C]"]
}
MINOR: BGP #12: configure router "Base" bgp import policy - Inconsistent Value error - Policy chain exceeds maximum number of expressions - configure
A logical expression with a length that does not exceed 64 characters can be anywhere in the policy chain (but the result can be different).
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A B "[C]AND[A]"]
}
(leads to: ["A" "B" "[C]AND[A]"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A "[C]AND[A]" B]
}
(leads to: ["A" "[C]AND[A]" "B"])
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["[C]AND[A]" A B]
}
(leads to: ["[C]AND[A]" "A" "B"])
When the length of the logical expression exceeds 64 characters, the logical expression must be at the start of the policy chain.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]" A B]
}
(leads to: ["[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]" "A" "B"])
The following message is raised when a logical expression with a length that exceeds 64 characters is not at the start of a policy chain.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy [A B "[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]"]
}
MINOR: BGP #8: configure router "Base" bgp import policy - Wrong Length error - Policy entry 3 exceeds maximum length (64) - configure
The following message is raised when a logical expression with a length that exceeds 255 characters is at the start of a policy chain.
# on PE-1:
configure {
router "Base" {
bgp {
delete import # to remove already existing import policies
import {
policy ["[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AN
D[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AN
D[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AN
D[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]"
A B]
}
A:admin@PE-1# import policy ["[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]A
ND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]A
ND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]A
ND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]AND[A]AND[B]AND[C]"
A B]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
MINOR: MGMT_CORE #2301: Invalid element value - 'policy' expected string '<1..255 characters>' or reference '<1..64 characters>' (configure policy-options policy-statement <name>)
Route policy logical expressions
Logical expressions are evaluated to be true or false. Boolean values for the policy actions shows the mapping of policy actions to Boolean values.
|
Policy action |
Boolean value |
|---|---|
|
Accept |
True |
|
Next-entry |
True |
|
Next-policy |
True |
|
Reject |
False |
Actions for the logical operators shows the evaluation actions for the logical operators NOT, OR, and AND.
|
Logical operator |
Action |
|---|---|
|
NOT <expr> |
Swaps the true/false result of the expression. |
|
<expr1> OR <expr2> |
If expr1 is true, the result is true and expr2 is not evaluated. If expr1 is false, expr2 must be evaluated. The final result is true if either expression is true; otherwise, it is false. |
|
<expr1> AND <expr2> |
If expr1 is false, the result is false and expr2 is not evaluated. If expr1 is true, expr2 must be evaluated. The final result is true only if both expressions are true. |
Mapping the final result of an expression to a policy action shows the mapping of the final result of an expression to a policy action. Routes are rejected when the entire expression is false.
|
Final result |
Action |
|---|---|
|
True |
accept, next-entry, or next-policy (depending on the last entry evaluated) |
|
False |
reject |
Configuration
Example topology shows the example topology including the advertised route.
The initial configuration of the routers includes:
-
Cards, MDAs, ports
-
Router interfaces
-
IS-IS
-
LDP
-
BGP
-
Export policy "export-bgp" accepting routes for prefix 2.2.2.2/32 on PE-2.
It is possible to configure VPRNs and assign policies to BGP in the VPRN, although in this chapter, all the examples are for BGP in the base router.
Policy chaining and policy logical expressions
In this section, three route policies are configured that will add a community and set the local-preference (LP): only policy C does not set LP. Policy C has action next-policy, and policies A and B have action accept. The configuration is:
# on PE-1, PE-2:
configure {
policy-options {
community "A" {
member "1:1" { }
}
community "B" {
member "2:2" { }
}
community "C" {
member "3:3" { }
}
policy-statement "A" {
entry 10 {
action {
action-type accept
local-preference 110
community {
add ["A"]
}
}
}
}
policy-statement "B" {
entry 10 {
action {
action-type accept
local-preference 220
community {
add ["B"]
}
}
}
}
policy-statement "C" {
entry 10 {
action {
action-type next-policy
community {
add ["C"]
}
}
}
}
Initially, policy chaining is configured without a logical expression. Subsequently, policy chaining is configured with only one policy logical expression and no other policies in the chain, as described in the following sections.
Policy chaining without logical expression
Policy chaining may include one logical expression, except in this example, there is no policy logical expression in the chain.
Policy chaining is configured on PE-1:
# on PE-1:
configure {
router "Base" {
bgp {
import {
policy ["C" "A" "B"]
}
PE-1 receives route 2.2.2.2/32 from PE-2. For each route, PE-1 evaluates policy C first. This policy adds community C (3:3) and has action next-policy, which implies that the next policy must also be evaluated. Policy A adds community A (1:1) and sets the LP to a value of 110 (by default, the local-preference equals 100). Policy A has action accept and, therefore, the evaluation is completed. The local-preference and the community are shown in the following output:
[/]
A:admin@PE-1# show router bgp routes hunt brief
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
Path Id : None
From : 192.0.2.2
Res. Protocol : ISIS Res. Metric : 10
Res. Nexthop : 192.168.12.2
Local Pref. : 110 Interface Name : int-PE-1-PE-2
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : None
AIGP Metric : None IGP Cost : 10
Connector : None
Community : 1:1 3:3
---snip---
Policy logical expressions with two policies
In the following examples, the policy chain contains only a policy logical expression. When both policy A and policy B must be executed, the logical operator used is: AND. The sequence is important in this case, because both policies A and B set the LP and the last executed policy will set the final value for the LP. The following import policy expression is configured on PE-1:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["[A]AND[B]"]
}
Policy A is evaluated first and it adds community A (1:1) and sets LP 110. Then, policy B is evaluated, which adds community B (2:2) and sets LP 220.
[/]
A:admin@PE-1# show router bgp routes hunt brief | match "Local Pref."
Local Pref. : 220 Interface Name : int-PE-1-PE-2
[/]
A:admin@PE-1# show router bgp routes hunt brief | match "Community"
Community : 2:2 1:1
When the policy expression is [B]AND[A], the order is reversed. First, policy B sets LP 220, then policy A sets LP 110:
[/]
A:admin@PE-1# show router bgp routes hunt brief | match "Local Pref."
Local Pref. : 110 Interface Name : int-PE-1-PE-2
[/]
A:admin@PE-1# show router bgp routes hunt brief | match "Community"
Community : 1:1 2:2
When the policy expression contains operator OR instead of AND, the first true expression results in a completed evaluation. Because both policy A and policy B result in a true expression, whichever policy is evaluated first is executed and the second one is skipped. For example, when policy A is evaluated first and the result is true, policy B is skipped. Therefore, the community is A (1:1) and the LP 110:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["[A]OR[B]"]
}
[/]
A:admin@PE-1# show router bgp routes hunt brief | match "Local Pref."
Local Pref. : 110 Interface Name : int-PE-1-PE-2
[/]
A:admin@PE-1# show router bgp routes hunt brief | match "Community"
Community : 1:1
Likewise, when policy B is evaluated first and the result is true, policy A is skipped. The added community is B (2:2) and the LP 220:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["[B]OR[A]"]
}
[/]
A:admin@PE-1# show router bgp routes hunt brief | match "Local Pref."
Local Pref. : 220 Interface Name : int-PE-1-PE-2
[/]
A:admin@PE-1# show router bgp routes hunt brief | match "Community"
Community : 2:2
The logical operator NOT swaps the result from true to false, and vice versa. When policy A is evaluated as true, NOT[A] is false. A false expression in an AND relationship leads to a false result. The next policy in the logical expression is not evaluated. No communities are added and no LP is set (the default value for LP is 100). The route is rejected as invalid:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["NOT[A]AND[B]"]
}
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 100 Interface Name : int-PE-1-PE-2
---snip---
Community : No Community Members
---snip---
Flags : Invalid IGP Rejected
---snip---
However, a false NOT[A] expression in an OR relationship may still lead to the expression being evaluated to true:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["NOT[A]OR[B]"]
}
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 220 Interface Name : int-PE-1-PE-2
---snip---
Community : 2:2 1:1
---snip---
Flags : Used Valid Best IGP In-RTM
---snip---
Policy B is evaluated as true for the route and, therefore, the entire logical expression "NOT[A]OR[B]" is true, and the route is accepted. Every policy in the expression that was evaluated, before the entire logical expression was recognized to be true, is executed, including policy A. This implies that policy A adds community A (1:1) to the route and sets LP to a value of 110. Then, policy B adds community B (2:2) to the route and overwrites the LP to a value of 220.
The import policy "[B] OR NOT[A]" is true after the first policy is evaluated as true. Only policy B is executed, the assigned community is B (2:2) and the LP is 220:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["[B] OR NOT[A]"]
}
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 220 Interface Name : int-PE-1-PE-2
---snip---
Community : 2:2
---snip---
Flags : Used Valid Best IGP In-RTM
---snip---
Assigned LP and communities for the import logical expressions summarizes the results for these different scenarios.
|
Import logical expression |
Assigned LP |
Assigned community |
|---|---|---|
|
import "[A]AND[B]" |
220 |
2:2 1:1 |
|
import "[B]AND[A]" |
110 |
1:1 2:2 |
|
import "[A]OR[B]" |
110 |
1:1 |
|
import "[B]OR[A]" |
220 |
2:2 |
|
import "NOT[A]AND[B]" |
None |
None (Route rejected) |
|
import "NOT[A]OR[B]" |
220 |
2:2 1:1 |
|
Import "[B] OR NOT[A]" |
220 |
2:2 |
Policy logical expressions with three policies
In policy chaining, the next policy in the chain is evaluated when the action is next-policy. In policy logical expressions, the next policy is evaluated depending on the logical operator and the Boolean value for the previous policies in the expression.
Policy C has action next-policy instead of accept and adds community C (3:3), but does not set the LP.
Several logical expressions can be made with policies A, B, and C. The following import policy has all three policies in an AND relationship. The expression is evaluated as true and all policies are executed: three communities are added and the LP is set.
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["[C]AND[A]AND[B]"]
}
The first policy adds community C (3:3), the second policy adds community A (1:1) and sets LP 110, and the third policy adds community B (2:2) and sets LP 220:
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 220 Interface Name : int-PE-1-PE-2
---snip---
Community : 2:2 1:1 3:3
---snip---
Flags : Used Valid Best IGP In-RTM
---snip---
The import policy "[C]AND[A]OR[B]" results in the first two being executed. Policy C is evaluated as true, and the logical operation is AND. Therefore, the next policy must be evaluated too. Policy A is also evaluated as true and the next operation is OR. The final result is evaluated as true without evaluating policy B. The communities added are C and A (3:3 and later 1:1) and the LP is 110.
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["[C]AND[A]OR[B]"]
}
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 110 Interface Name : int-PE-1-PE-2
---snip---
Community : 1:1 3:3
---snip---
Flags : Used Valid Best IGP In-RTM
---snip---
The import policy "[C]OR[A]OR[B]" is evaluated as true after the first policy is evaluated as true. Even though the action in policy C is next-policy, the next policy in this expression is not evaluated, because the expression is already true. Only policy C is executed and it adds the community C (3:3), but does not configure the LP:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["[C]OR[A]OR[B]"]
}
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 100 Interface Name : int-PE-1-PE-2
---snip---
Community : 3:3
---snip---
Flags : Used Valid Best IGP
---snip---
However, if the policy chain contains not only a logical expression, but also single policies, the action next-policy ensures that a following policy in the chain is executed; for example, policy D in the following policy chain:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["[C]OR[A]OR[B]" "D"]
}
The expression "[C]OR[A]OR[B]" is true after policy C has been evaluated, but policy C has action next-policy and policy D is the next policy to be evaluated.
The import policy "[C]OR[A]AND[B]" expression evaluates policy C as true. Policy C has an OR relationship with policy A in the logical expression ‟[C]OR[A]”, and therefore, policy A is not evaluated. There is an AND relationship with policy B and policy B is evaluated as true. Therefore, the entire logical expression "[C]OR[A]AND[B]" is true and the route is accepted. Both policy C and B are executed. First, policy C adds community C (3:3), then policy B adds community B (2:2) and sets LP 220:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["[C]OR[A]AND[B]"]
}
[/]
A:admin@PE-1# show router bgp routes hunt brief
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 220 Interface Name : int-PE-1-PE-2
---snip---
Community : 2:2 3:3
---snip---
Flags : Used Valid Best IGP In-RTM
---snip---
Assigned LP and communities for the import logical expressions summarizes the results for these different scenarios.
|
Import logical expression |
Assigned LP |
Assigned community |
|---|---|---|
|
import "[C]AND[A]AND[B]" |
220 |
2:2 1:1 3:3 |
|
import "[C]AND[A]OR[B]" |
110 |
1:1 3:3 |
|
import "[C]OR[A]OR[B]" |
None |
3:3 |
|
import "[C]OR[A]AND[B]" |
220 |
2:2 3:3 |
Combinations of policy logical operations using brackets
For this section, the following communities and policies are configured on PE-1. All these policies have a from condition that matches a community (D, E, F, G). Besides these policies, there are also export policies on PE-2 that add one or more communities (D, E, F, G) to the advertised routes. On PE-1, incoming route 2.2.2.2/32 will have one or more communities that may or may not match the from condition in the following route policies.
# on PE-1 and PE-2:
configure {
policy-options {
community "D" {
member "4:4" { }
}
community "E" {
member "5:5" { }
}
community "F" {
member "6:6" { }
}
community "G" {
member "7:7" { }
}
policy-statement "D" {
entry 10 {
from {
community {
name "D"
}
}
action {
action-type accept
local-preference 4
}
}
default-action {
action-type reject
}
}
policy-statement "E" {
entry 10 {
from {
community {
name "E"
}
}
action {
action-type accept
local-preference 5
}
}
default-action {
action-type reject
}
}
policy-statement "F" {
entry 10 {
from {
community {
name "F"
}
}
action {
action-type accept
local-preference 6
}
}
default-action {
action-type reject
}
}
policy-statement "G" {
entry 10 {
from {
community {
name "G"
}
}
action {
action-type accept
local-preference 7
}
}
default-action {
action-type reject
}
}
The received routes have community E (5:5) present. The following import policy is configured on PE-1:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["([D]AND[E])OR([F]AND[G])"]
}
The first policy that is evaluated requires community D (4:4) to be present. This is not the case and the expression between brackets, ([D]AND[E]), is false. Policy E is not evaluated. The next policy to be evaluated is F and it requires community F (6:6), which is not present. The second expression between brackets, ([F]AND[G]), is therefore also false and policy G is not evaluated. The entire policy logical expression is false and the route is rejected.
The following commands show what policy evaluation caused the route to be rejected. For the entire logical expression "([D]AND[E])OR([F]AND[G])", the last policy that was evaluated, and that caused the route to be rejected, was policy F:
[/]
A:admin@PE-1# show router bgp policy-test plcy-or-long-expr "([D]AND[E])OR([F]AND[G])" family ipv4 prefix 0.0.0.0/0 longer display-rejects brief
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Network
-------------------------------------------------------------------------------
Rejected by Logical expression last policy F Default action
2.2.2.2/32
-------------------------------------------------------------------------------
Total Routes : 1 Routes rejected : 1
===============================================================================
For the logical expression "[D]AND[E]", the last policy that was evaluated, and that led to the conclusion that the expression was false, was policy D:
[/]
A:admin@PE-1# show router bgp policy-test plcy-or-long-expr "[D]AND[E]" family ipv4 prefix 0.0.0.0/0 longer display-rejects brief
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Network
-------------------------------------------------------------------------------
Rejected by Logical expression last policy D Default action
2.2.2.2/32
-------------------------------------------------------------------------------
Total Routes : 1 Routes rejected : 1
===============================================================================
For the logical expression "[F]AND[G]", the last policy that was evaluated, and that led to the conclusion that the expression was false, was policy F:
[/]
A:admin@PE-1# show router bgp policy-test plcy-or-long-expr "[F]AND[G]" family ipv4 prefix 0.0.0.0/0 longer display-rejects brief
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Network
-------------------------------------------------------------------------------
Rejected by Logical expression last policy F Default action
2.2.2.2/32
-------------------------------------------------------------------------------
Total Routes : 1 Routes rejected : 1
===============================================================================
The logical expression "([D]AND[E])OR([F]AND[G])" is false and, therefore, the route is rejected. No LP is set. Community E (5:5) was already present in the incoming route.
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 100 Interface Name : int-PE-1-PE-2
---snip---
Community : 5:5
---snip---
Flags : Invalid IGP Rejected
---snip---
In the second example, the incoming route contains communities D (4:4) and E (5:5). The same policy logical expression "([D]AND[E])OR([F]AND[G])" is evaluated as true because both policy D and policy E are true. There is an OR relationship with the rest of the expression and, therefore, the entire logical expression is true. Policy E is the last policy to be evaluated:
[/]
A:admin@PE-1# show router bgp policy-test plcy-or-long-expr "([D]AND[E])OR([F]AND[G])" family ipv4 prefix 0.0.0.0/0 longer display-rejects brief
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Network
-------------------------------------------------------------------------------
Accepted by Logical expression last policy E Entry 10
2.2.2.2/32
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
The route is accepted as valid and gets LP 5. The communities D (4:4) and E (5:5) were already present for the incoming route. The first policy that was executed, was policy D and it set the LP to a value of 4. Policy E was the second and last policy that was executed and it set the LP to a value of 5:
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 5 Interface Name : int-PE-1-PE-2
---snip---
Community : 5:5 4:4
Cluster : No Cluster Members
Originator Id : None Peer Router Id : 192.0.2.2
Fwd Class : None Priority : None
Flags : Used Valid Best IGP In-RTM
---snip---
For the third example, the incoming route contains communities D (4:4) and E (5:5). The logical expression "([D]OR[E])AND([F]OR[G])" is evaluated as false and the route is rejected:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["([D]OR[E])AND([F]OR[G])"]
}
First, policy D is evaluated as true because community D (4:4) is present. Policy D has an OR relationship with policy E, which is true without the need to evaluate policy E. The next policy to be evaluated is F. Policy F requires the community F (6:6) to be present, which is not the case. The logical expression ‟[F]OR[G]” can only be true if policy G is true. Policy G requires community G (7:7) to be present, which is false. The last policy that was evaluated before the route was rejected was policy G:
[/]
A:admin@PE-1# show router bgp policy-test plcy-or-long-expr "([D]OR[E])AND([F]OR[G])" family ipv4 prefix 0.0.0.0/0 longer display-rejects brief
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Network
-------------------------------------------------------------------------------
Rejected by Logical expression last policy G Default action
2.2.2.2/32
-------------------------------------------------------------------------------
Total Routes : 1 Routes rejected : 1
===============================================================================
The route was rejected and, therefore, no policy was executed. The LP kept its default value of 100:
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 100 Interface Name : int-PE-1-PE-2
---snip---
Community : 5:5 4:4
---snip---
Flags : Invalid IGP Rejected
---snip---
For the fourth example, the incoming route has communities E (5:5) and G (7:7). The logical expression "([D]OR[E])AND([F]OR[G])" is evaluated as true and the route is accepted. First, policy D is evaluated as false. Policy D has an OR relationship with policy E, which is evaluated as true. Consequently, the expression ‟[D]OR[E]” is true. This expression has an AND relationship with the expression ‟[F]OR[G]”.
The next policy to be evaluated is F. Policy F requires the community F (6:6) to be present, which is false. The logical expression ‟[F]OR[G]” can only be true if policy G is true. Policy G requires community G (7:7) to be present, which is true. This makes [F]OR[G] true as well as the entire expression "([D]OR[E])AND([F]OR[G])".
The last policy that was evaluated before the route was accepted was policy G:
[/]
A:admin@PE-1# show router bgp policy-test plcy-or-long-expr "([D]OR[E])AND([F]OR[G])" family ipv4 prefix 0.0.0.0/0 longer display-rejects brief
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Network
-------------------------------------------------------------------------------
Accepted by Logical expression last policy G Entry 10
2.2.2.2/32
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
The route was accepted and has the changes of all policies that were evaluated: initially, policy D set the LP to 4. This value was overwritten by policy E to 5, by policy F to 6, and finally by policy G to a value of 7:
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 7 Interface Name : int-PE-1-PE-2
---snip---
Community : 5:5 7:7
---snip---
Flags : Used Valid Best IGP In-RTM
---snip---
Assigned LP for the import logical expressions summarizes the results for these different scenarios.
|
Ingress community |
Import logical expression |
Assigned LP |
|---|---|---|
|
5:5 |
import "([D]AND[E])OR([F]AND[G])" |
Prefix rejected |
|
5:5 4:4 |
import "([D]AND[E])OR([F]AND[G])" |
5 |
|
5:5 4:4 |
import "([D]OR[E])AND([F]OR[G])" |
Prefix rejected |
|
5:5 7:7 |
import "([D]OR[E])AND([F]OR[G])" |
7 |
Modification of attributes while processing
During the policy evaluation process, some prefix attributes can be modified while processing, and these modified attributes can be used as criteria for other policies in the logical expression.
In the following example, two route policies are configured:
-
Policy X adds a new community Y (11:11) to the incoming route update.
-
Policy Y uses community Y (11:11) as the only match criterion and removes communities X and Y. Policy Y also sets the LP to a value of 9, which is used here as an indication that policy Y was executed.
An export policy on PE-2 adds community X (10:10) to prefix 2.2.2.2/32 (not shown here).
Route policies X and Y are configured on PE-1:
# on PE-1:
configure {
policy-options {
community "X" {
member "10:10" { }
}
community "Y" {
member "11:11" { }
}
policy-statement "X" {
entry 10 {
from {
community {
name "X"
}
}
action {
action-type accept
community {
add ["Y"]
}
}
}
}
policy-statement "Y" {
entry 10 {
from {
community {
name "Y"
}
}
action {
action-type accept
local-preference 9
community {
remove ["X" "Y"]
}
}
}
}
When no import policy is applied on PE-1, the received route 2.2.2.2/32 has community 10:10 and the default LP:
[/]
A:admin@PE-1# show router bgp routes hunt brief
---snip---
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 100 Interface Name : int-PE-1-PE-2
---snip---
Community : 10:10
---snip---
Flags : Used Valid Best IGP In-RTM
---snip---
The import policy "[X]AND[Y]" is configured on PE-1:
# on PE-1:
configure {
router "Base" {
bgp {
delete import
import {
policy ["[X]AND[Y]"]
}
The route update contains community X (10:10) and policy X is evaluated as true. Policy X adds community Y (11:11) to the route. Policy Y requires this community and is evaluated as true. Therefore, the entire logical expression "[X]AND[Y]" is true and the route is accepted. Policy Y removes communities X (10:10) and Y (11:11), and sets the LP to a value of 9:
[/]
A:admin@PE-1# show router bgp routes hunt brief
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 2.2.2.2/32
Nexthop : 192.0.2.2
---snip---
Local Pref. : 9 Interface Name : int-PE-1-PE-2
---snip---
Community : No Community Members
---snip---
Flags : Used Valid Best IGP In-RTM
---snip---
Conclusion
Route policy chaining and logical expressions allow complex route processing logic to be broken into smaller components. These policy components are reusable and facilitate the process of updating route control logic. Logical expressions offer more flexible combinations of policy statements.