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 Figure: 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, should an operator 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 – a significant amount of work that can result in incorrect/inconsistent policy behavior.
Using a parameter based system allows an operator 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. This feature is able to inherit some of these variables directly from the routing process (for example, ‟@peerAS@” would be the configured BGP peer-AS).
Additionally, instead of policies being fixed and requiring many statements, the use of parameters 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 two types of policy variables are supported.
Global policy variables are configured using the global-variables command and can be referenced from any policy. Use global policy variables when the variables are used by multiple policies.
Local policy variables are configured using the policy-variables command in each policy, and 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.
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@
Table: Route policy variable support in policy parameters lists route policy variables supported 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 |
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 number value-number
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 per-peer policy in which the variable names and values are defined. Using Figure: Route policy parameterization using sub-policies as the example, the following configuration would be applied:
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"
community "cm-as65535" members "7750:65535"
community "cm-as64535-rejects" members "64535:14"
community "cm-as65535-rejects" members "65535:14"
community "cm-as64535-highpref" members "7777:64535"
as-path "as63535" expression "^63535$"
as-path "as64535" expression "^64535$"
as-path "as65535" expression "^65535$"
policy-statement "peer1"
entry 5
from
policy-variables
name "@cm-reject@" value "cm-as65535-rejects"
exit
policy "std-peering-inbound-drop"
exit
action reject
entry 10
from
policy-variables
name "@localcm@" value "cm-as65535"
name "@peer-as@" value "as65535"
name "@cm-highpref@" value "cm-as65535-highpref"
name "@peer-prefix@" value "pfx-as65535"
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
policy "std-peering-inbound-drop"
exit
action reject
entry 10
from
policy-variables
name "@localcm@" value "cm-as64535"
name "@peer-as@" value "as64535"
name "@cm-highpref@" value "cm-as64535-highpref"
name "@peer-prefix@" value "pfx-as64535"
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"
exit
policy "std-peering-inbound-drop"
exit
action reject
entry 10
from
policy-variables
name "@localcm@" value "cm-as63535"
name "@peer-as@" value "as63535"
name "@cm-highpref@" value "cm-as63535-highpref"
name "@peer-prefix@" value "pfx-as63535"
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
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.