Routing Policy Language
This section contains the following information:
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.
Routing Configuration Guide for Cisco NCS 5500 Series Routers, IOS XR Release 6.3.x
134
Implementing Routing Policy
Routing Policy Language
To Next Page
Loading...
Need help?
General
