Filter
Top Products
Implementing Routing Policy on Cisco IOS XR Software
Information About Implementing Routing Policy
RC-218
Cisco IOS XR Routing Configuration Guide
Policy four could be rewritten in an equivalent way as follows:
route-policy four-equivalent
set weight 100
set med 200
set community (2:666) additive
pass
end-policy
Note The pass statement is not required and can be removed to represent the equivalent policy in another way.
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.