Policy Verification; Range Checking; Incomplete Policy And Set References; Attached Policy Modification - Cisco ASR 9000 Series Configuration Manual

Implementing Routing Policy

Policy Verification

Several different types of verification occur when policies are being defined and used.

Range Checking

As policies are being defined, some simple verifications, such as range checking of values, is done. For
example, the MED that is being set is checked to verify that it is in a proper range for the MED attribute.
However, this range checking cannot cover parameter specifications because they may not have defined values
yet. These parameter specifications are verified when a policy is attached to an attach point. The policy
repository also verifies that there are no recursive definitions of policy, and that parameter numbers are correct.
At attach time, all policies must be well formed. All sets and policies that they reference must be defined and
have valid values. Likewise, any parameter values must also be in the proper ranges.

Incomplete Policy and Set References

As long as a given policy is not attached at an attach point, the policy is allowed to refer to nonexistent sets
and policies, which allows for freedom of workflow. You can build configurations that reference sets or policy
blocks that are not yet defined, and then can later fill in those undefined policies and sets, thereby achieving
much greater flexibility in policy definition. Every piece of policy you want to reference while defining a
policy need not exist in the configuration. Thus, a user can define a policy sample that references the policy
bar using an apply statement even if the policy bar does not exist. Similarly, a user can enter a policy statement
that refers to a nonexistent set.
However, the existence of all referenced policies and sets is enforced when a policy is attached. If you attempt
to attach the policy sample with the reference to an undefined policy bar at an inbound BGP policy using the
neighbor 1.2.3.4 address-family ipv4 unicast policy sample in command, the configuration attempt is
rejected because the policy bar does not exist.
Likewise, you cannot remove a route policy or set that is currently in use at an attach point because this
removal would result in an undefined reference. An attempt to remove a route policy or set that is currently
in use results in an error message to the user.
A condition exists that is referred to as a null policy in which the policy bar exists but has no statements,
actions, or dispositions in it. In other words, the policy bar does exist as follows:
route-policy bar
end-policy
This is a valid policy block. It effectively forces all routes to be dropped because it is a policy block that never
modifies a route, nor does it include the pass statement. Thus, the default action of drop for the policy block
is followed.

Attached Policy Modification

Policies that are in use do, on occasion, need to be modified. Traditionally, configuration changes are done
by completely removing the relevant configuration and then re-entering it. However, this allows for a window
of time in which no policy is attached and the default action takes place. RPL provides a mechanism for an
atomic change so that if a policy is redeclared, or edited using a text editor, the new configuration is applied
immediately—which allows for policies that are in use to be changed without having a window of time in
which no policy is applied at the given attach point.
OL-30423-03
Cisco ASR 9000 Series Aggregation Services Router Routing Configuration Guide, Release 5.1.x
Semantics of Policy Application
485