Filter
Top Products
Implementing Routing Policy on Cisco IOS XR Software
Information About Implementing Routing Policy on Cisco IOS XR Software
RC-355
Cisco IOS XR Routing Configuration Guide
OL-14356-01
• Routing Policy Language Components, page RC-360
• Routing Policy Language Usage, page RC-361
Routing Policy Language Overview
RPL was developed to support large-scale routing configurations. RPL has several fundamental
capabilities that differ from those present in configurations oriented to traditional route maps, access
lists, and prefix lists. The first of these capabilities is the ability to build policies in a modular form.
Common blocks of policy can be defined and maintained independently. These common blocks of policy
can then be applied from other blocks of policy to build complete policies. This capability reduces the
amount of configuration information that needs to be maintained. In addition, these common blocks of
policy can be parameterized. This parameterization allows for policies that share the same structure but
differ in the specific values that are set or matched against to be maintained as independent blocks of
policy. For example, three policies that are identical in every way except for the local preference value
they set can be represented as one common parameterized policy that takes the varying local preference
value as a parameter to the policy.
The policy language introduces the notion of sets. Sets are containers of similar data that can be used in
route attribute matching and setting operations. Four set types exist: prefix-sets, community-sets,
as-path-sets, and extcommunity-sets. These sets hold groupings of IPv4 or IPv6 prefixes, community
values, AS path regular expressions, and extended community values, respectively. Sets are simply
containers of data. Most sets also have an inline variant. An inline set allows for small enumerations of
values to be used directly in a policy rather than having to refer to a named set. Prefix lists, community
lists, and AS path lists must be maintained even when only one or two items are in the list. An inline set
in RPL allows the user to place small sets of values directly in the policy body without having to refer
to a named set.
Decision making, such as accept and deny, is explicitly controlled by the policy definitions themselves.
RPL combines matching operators, which may use set data, with the traditional Boolean logic operators
and, or, and not into complex conditional expressions. All matching operations return a true or false
result. The execution of these conditional expressions and their associated actions can then be controlled
by using simple if then, elseif, and else structures, which allow the evaluation paths through the policy
to be fully specified by the user.
Routing Policy Language Structure
This section describes the basic structure of RPL.
Names
The policy language provides two kinds of persistent, namable objects: sets and policies. Definition of
these objects is bracketed by beginning and ending command lines. For example, to define a policy
named test, the configuration syntax would look similar to the following:
route-policy test
[ . . . policy statements . . . ]
end-policy
Legal names for policy objects can be any sequence of the upper- and lowercase alphabetic characters;
the numerals 0 to 9; and the punctuation characters period, hyphen, and underscore. A name must begin
with a letter or numeral.