Routing Policy Language Overview

RPL was developed for Cisco IOS XR Software to replace and improve the route maps used in Cisco IOS or IOS XE Software, and to
better support large-scale routing configurations.

RPL has the following characteristics:

 Simple, yet powerful language for processing both IGP and BGP routing updates.
 Replaces route map functionality in Cisco IOS XR Software.
 A case-sensitive name identifies each policy.
 The entire policy is defined within the route-policy configuration block.
 Modular design that allows optimization and better reusability of policies.
 Support for parameterization, referencing objects such as sets, and policy nesting.

RPL has several fundamental capabilities that differ from the ones present in Cisco IOS and IOS XE route maps, access lists, and prefix
lists:

 Modular Construction: Common blocks of policy can be defined and maintained independently, and can be applied from
other policies to build a complete final policy—reducing the amount of configuration that needs to be maintained. In
addition, these common blocks of policy can be parameterized. Parameterization allows for policies that share the same
structure, but have different values, to be maintained as independent blocks of policy. For example, three policies, all
identical 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.
 Policy Attachment and Application: The policies you create do not automatically have any effect on the routing processes,
so the policies must be attached to the routing protocol entities in the Cisco IOS XR Software. The policy attach point is the
point in which an association is formed between a specific protocol entity, for example, a BGP neighbor, and a specific
named policy. RPL policies can be attached to OSPF, OSPFv3, IS-IS, EIGRP, RIP, Protocol Independent Multicast (PIM), and
BGP protocols at various points. The attach-points for various protocols will vary, depending on the structure and operation
of a specific protocol. The policies' syntax will also be limited to a specific protocol, for example, BGP communities do not
make sense in an IGP like OSPF, so policies are checked by the OS at the moment of attachment.
 BGP Operation: In Cisco IOS XR Software, external BGP sessions by default won’t exchange any prefixes unless a policy is
configured. This default prevents unintended prefix exchange between external BGP peers before a proper routing policy
can be put in place. Internal BGP, on the other hand, is not subject to that restriction.

RPL Actions

Actions in an RPL affect the control flow of the policy.

A prefix must be given a ticket to ensure that the RPL inspects it, and then be accepted or dropped. There are four distinct actions
that can be configured in an RPL policy, with an implicit drop at the end of the policy:

 Pass: Allows the prefix (if not later dropped). Pass grants a ticket to defeat default drop, execution continues for that prefix.
 Set: Changes attributes of the prefix, allows the prefix (if not later dropped), execution continues. Values can be set more
than once.
 Drop: Discards the Prefix. Execution is stopped for that prefix.
 Done: Allows the prefix and stops the execution for that prefix.

A policy does not modify route attribute values until the entire policy processing has been completed. This means that comparison
operators always run on the initial data in the route. For example, a route enters the policy with a Multi-Exit Discriminator (MED)
attribute value of 10. If the policy includes a step to change this MED value to 20, and later checks for prefixes with a MED of 20 to
drop them, the original route will not be dropped. This behavior is because the comparison will still be made against the initial MED
value of 10.
When encountering a done statement in a policy, the prefix is allowed to pass, however the policy rule processing stops and no
further policy statements are executed. All modifications that are made to the route before the done statement are still valid. For
example, if MED is set to 30 for a prefix, followed by done, the prefix will be updated with that attribute value.

There is an implicit drop at the end of the policy. This drop means that if a prefix does not match any conditions, does not execute a
statement, or is not processed by any rules in the route policy, or more specifically, if it failed to secure a ticket, it will be dropped at
the end of the policy. Be aware that when using if statements inside the policy, it is easy to unintentionally drop other prefixes that
do not match that if statement. There is no single solution for the other prefixes.

Conditions and Operators

RPL uses the conditional statement syntax and operators like those found in many programming languages.

The basic conditional statement in RPL is the if statement. You can implement the if statement in two different ways:

 Basic conditional statement: if condition then operation1 [else operation2] endif

 if med eq 150 then
 pass
 else
 set med 200
endif

 Conditional statement with elseif branching options: if condition1 then operation1 elseif condition2 then operation2 [else
operation3] endif
 if med eq 150 then
 pass
 elseif destination in (10.0.0.8/8 ge 8)
 set med 300
 else
 set med 200
endif

The else part is optional in both variants of the if statement.

RPL conditions can use these operators:

 eq: An attribute numerically equal to a specified value

 le: An attribute numerically lower than or equal to a specified value
 ge: An attribute numerically greater than or equal to a specified value
 is: An attribute equal to a specified value (used for non-numerical values)
 in: An attribute is contained in a value set (is a part of a set)

Apart from the conditional operators, Boolean operators can be used between conditions of a statement:

 and (conjunction): Use when two or more conditions must match

 or (disjunction): Use if at least one of two or more conditions must match
 not (negation): Use to negate a condition

When using Boolean operators, make sure to use parentheses to influence the precedence of operators and achieve the desired
result. The operators have the following precedence: not is always evaluated first; and is evaluated second; or is evaluated last.

The following policy configuration example shows an if statement branching scenario using conditional operators, and Boolean
operators, where the MED attribute is used to influence the setting of the local preference attribute. The example also shows how
you can stack multiple elseif statements after the initial if statement.

route-policy SET-LOCALPREF
if med eq 10 and not local-preference eq 100 then
set local-preference 200
elseif med eq 20 or local-preference eq 200 then
set local-preference 150
elseif
set local-preference 50
endif
end-policy

The if statements can also be nested in one another as in the following policy example:

route-policy SET-COMMUNITY
if med eq 10 then
if local-preference eq 1000
set community (65000:100) additive
endif
endif
end-policy

RPL Sets

The RPL language introduces the notion of sets as an unordered collection of unique elements. Sets are containers of similar data
that can be used in route attribute matching and setting operations. Sets are used in conditional expressions and can be used inline
(directly) or as a part of a named set configuration block. The elements of the set are separated by commas, and empty sets are
allowed.

Several types of sets exist, holding the following elements:

 as-path-set: autonomous system path regular expressions

 as-set: similar to as-path-set but faster because it can only be used with as-path originates-from command in the route-
policy
 community-set: BGP community values
 extcommunity-set: BGP extended community values
 large-community-set: BGP large community values, specified as three non-negative decimal integers separated by colons
 prefix-set: groupings of IPv4 or IPv6 prefixes
  rd-set: groupings of route distinguishers
 ospf-area-set: list of OSPF areas

The previous figure shows a simple example of an RPL policy using inline sets, checking if the route that is tested against the policy
belongs to one of RFC1918 private IP ranges. If the condition evaluates as true, the route is allowed, otherwise it is dropped.

The second part of the example shows an improvement by breaking out the destinations into a prefix set named SET-RFC1918,
making it easier to update or change the policy. The prefix set can also be reused in other policies. The policy in the if statement
references the prefix set.

From the previous example,, you can see that it is easy to expand on the prefix set by adding more prefixes to it—without the need
to edit the policy itself.

RPL Nesting

The hierarchical constructs of RPL allow one policy to refer to another policy. The referenced or called policy is known as a child
policy, while the policy that references another is called the parent or calling policy. A parent policy can nest multiple child policies.
Nesting is achieved in policy configuration by using the apply <child_policy_name> command as shown in the following figure.
Wildcard apply policy is possible in RPL using wildcard-based apply nesting. The wildcard operation permits the declaration of a
generic apply statement that calls all policies that contain a defined set of alphanumeric characters, defined on the router. A
wildcard is specified by placing an asterisk (*) at the end of the policy name in an apply statement.

RPL Parameters

Parameters can be used in place of fixed values when calling nested policies. RPL supports two types of parameters, global and
policy parameters:

 Global Parameters: Optional and can be defined globally using the policy-global Cisco IOS XR command. Global parameters
are available for use in all routing policies.
 Policy or Passed Parameters: Parameters that are passed to a nested routing policy. They are defined when creating a
routing policy and are available in match and set statements within a policy or when calling another routing policy.

The left-side example in the previous figure illustrates the usage of the policy-global IOS XR configuration, where all the global
variables that are required by your BGP deployment are defined. Any routing policy can reference these variables, and in the figure,
route policy SetMED is referencing two global variables, AS1 and MyMED.

On the right side of the figure, the routing policy that is named SetMED-P is defined with two parameters: $med1 and $med2. When
you are calling this policy from within another policy, in this example, MainPolicy, use the apply command and supply two
parameters. The example shows that the SetMED-P policy can be reused many times, depending on the need for it. In MainPolicy,
SetMED-P is conditionally used two times. It will be called with different parameters depending on the autonomous system of the
neighboring router that sent you the prefixes.
Answer

The correct answer is It enables independent maintenance and reuse of policy blocks. This answer is correct because RPL’s modular
design allows for the independent maintenance and reuse of policy blocks, optimizing policy management.

The: "It allows for direct manipulation of hardware settings." option is incorrect because RPL does not manipulate hardware settings
directly.

The: "It requires all policies to be stored in a single configuration block." option is incorrect because RPL does not mandate storing all
policies in a single configuration block; it supports modular design.

Finally, the "It restricts the use of global parameters across policies." option is incorrect because the modular design does not restrict
the use of global parameters; it supports them for flexibility.