Describes how RPL evaluates statements in order, applies inline policy behavior, enforces default drop semantics, delays attribute changes until testing completes, and handles repeated attribute modifications.
Policy execution is the process of evaluating a route policy that
-
processes policy statements sequentially in the order they appear in the configuration
-
runs an applied policy and then returns to the calling policy unless the route is dropped, and
-
treats an applied policy as if its contents are inserted inline at the point where the policy uses apply statement.
Order of policy execution
The system processes the policy statements sequentially, as they appear in the configuration.
If a policy uses the apply statement, execution proceeds into the applied policy. It then returns to the calling policy, unless the route is dropped.
When you apply a policy, its contents are treated as if they are inserted inline at the point where you use the apply statement.
Example:
route-policy one
set weight 100
end-policy
route-policy two
set med 200
end-policy
route-policy three
apply two
set community (2:666) additive
end-policy
route-policy four
apply one
apply three
pass
end-policy
Policy four is equivalent to:
route-policy four-equivalent
set weight 100
set med 200
set community (2:666) additive
pass
end-policy
You may remove the pass statement while preserving equivalent behavior, depending on the context.
Default drop disposition
By default, if you do not add a policy action, the route is dropped. All route policies have an implicit drop disposition, unless the route:
-
is modified by a policy action, or
-
is explicitly passed using the pass statement.
Consider this example:
route-policy two
if destination in (10.0.0.0/8 ge 8 le 32) then
set local-preference 200
endif
end-policy
route-policy one
apply two
end-policy
Although policy one does not explicitly pass routes, it inherits the disposition from policy two . Routes in network 10 that are modified by setting the local preference are passed; all other routes are dropped.
Attribute modification timing
The system does not modify route attributes until all tests in your policy are complete. All comparison operators evaluate the original route data. If you make intermediate modifications, they do not affect subsequent conditional tests.
Example:
if med eq 12 then
set med 42
if med eq 42 then
drop
endif
endif
The second test evaluates the original MED value, not the modified value. Therefore, the drop statement is never executed.
Multiple modifications of the same attribute
If you modify an attribute multiple times within a policy, the result depends on the attribute type.
Scalar attributes
For attributes that contain only one value, such as MED, your last assignment takes effect.
Example:
set med 9
set med 10
set med 11
set med 12
The resulting MED value is 12.
Example with conditional modification:
set med 8
if community matches-any cs1 then
set local-preference 122
if community matches-any cs2 then
set med 12
endif
endif
The route has a MED of 8 unless your policy matches both cs1 and cs2 . In this case, MED is 12.
Cumulative attributes
Additive and array attributes support cumulative behavior rather than replacing prior values.
Additive attribute example:
route-policy community-add
set community (10:23)
set community (10:24) additive
set community (10:25) additive
end-policy
Your resulting community list contains all three values: 10:23 , 10:24 , and 10:25 .
Array-type attribute example:
route-policy prepend-example
prepend as-path 2.5 3
prepend as-path 666.5 2
end-policy
This configuration prepends 666.5 666.5 2.5 2.5 2.5 to the AS path. Each prepend operation is applied, because the AS path is an array-type attribute.