Laptop User Manual

Implementing Routing Policy on Cisco IOS XR Software
Information About Implementing Routing Policy
RC-235
Cisco IOS XR Routing Configuration Guide
Attached Policy Modification
Policies that are in use do, on occasion, need to be modified. In the traditional configuration model, a
policy modification would be done by completely removing the policy and re-entering it. However, this
model allows for a window of time in which no policy is attached and default actions to be used, which
is an opportunity for inconsistencies to exist. To close this window of opportunity, you can modify a
policy in use at an attach point by respecifying it, 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.
Note A route policy or set that is in use at an attach point cannot be removed because this removal would result
in an undefined reference. An attempt to remove a route policy or set that is in use at an attach point
results in an error message to the user.
Nonattached Policy Modification
As long as a given policy is not attached at an attach point, the policy is allowed to refer to nonexistent
sets and policies. Configurations can be built that reference sets or policy blocks that are not yet defined,
and then later those undefined policies and sets can be filled in. This method of building configurations
gives 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, you can define a policy sample1 that
references a policy sample2 using an apply statement even if the policy sample2 does not exist. Similarly,
you 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. Thus, if
a user attempts to attach the policy sample1 with the reference to an undefined policy sample2 at an
inbound BGP policy using the statement neighbor 1.2.3.4 address-family ipv4 unicast policy sample1
in, the configuration attempt is rejected because the policy sample2 does not exist.
Editing Routing Policy Configuration Elements
RPL is based on statements rather than on lines. That is, within the begin-end pair that brackets policy
statements from the CLI, a new line is merely a separator, the same as a space character.
The CLI provides the means to enter and delete route policy statements. RPL provides a means to edit
the contents of the policy between the begin-end brackets using a microemacs editor.
Editing Routing Policy Configuration Elements Using the EMACS Editor
To edit the contents of a routing policy, use the following CLI command in EXEC mode:
edit {route-policy | prefix-set | as-path-set | community-set | extended-community-set}
name
A copy of the route policy is copied to a temporary file and the editor is launched. After editing, save
the changes by using the save-buffer command, C-X C-S (Control-X Control-S). To exit the editor, use
the quit command, Control-X Control-C. When you quit the editor, the buffer is committed. If there are
no parse errors, the configuration is committed: