Filter
Top Products
Implementing Routing Policy on Cisco IOS XR Software
Information About Implementing Routing Policy on Cisco IOS XR Software
RC-369
Cisco IOS XR Routing Configuration Guide
OL-14356-01
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.
Verification of Attribute Comparisons and Actions
The policy repository knows which attributes, actions, and comparisons are valid at each attach point.
When a policy is attached, these actions and comparisons are verified against the capabilities of that
particular attach point. Take, for example, the following policy definition:
route-policy bad
set med 100
set level level-1-2
set ospf-metric 200
end-policy
This policy attempts to perform actions to set the BGP attribute med, IS-IS attribute level, and OSPF
attribute cost. The system allows you to define such a policy, but it does not allow you to attach such a
policy. If you had defined the policy bad and then attempted to attach it as an inbound BGP policy using
the BGP configuration statement neighbor 1.2.3.4 address-family ipv4 unicast route-policy bad in the
system would reject this configuration attempt. This rejection results from the verification process
checking the policy and realizing that while BGP could set the MED, it has no way of setting the level
or cost as the level and cost are attributes of IS-IS and OSPF, respectively. Instead of silently omitting
the actions that cannot be done, the system generates an error to the user. Likewise, a valid policy in use
at an attach point cannot be modified in such a way as to introduce an attempt to modify a nonexistent
attribute or to compare against a nonexistent attribute. The verifiers test for nonexistent attributes and
reject such a configuration attempt.