RPL Overview

© 2012 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential 1
Upon completion of this module, you will be able
to:
 Write policies in RPL
 Use hierarchical and parameterized policies
 Convert route maps to RPL policies
© 2012 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2
“Using route-maps on a CRS-1 scale
could lead to configurations on the order
of several 100k to over a million lines
depending on the number of BGP peers.”
The Routing Policy Language (RPL)
was developed to support large scale
routing configurations.
RPL was designed to reduce some of

the redundancy that is inherent in route
map configuration
• Modularization
 Common blocks of policy
 Defined and maintained independently
 Apply from other blocks to build complete policies
• Parameterization
 Same policy structure but different set or matched values
 Value passed as parameter by applying block
Looping/recursion is not allowed
As many layers of hierarchy or parameters
that you want
Parameters can be passed through a policy
block
 Configuration front-end (CLI)
 Policy Repository
 Policy Execution Engine
 Policy Client
• Compile policies for execution
• Verify Policies
• Track & manage clients/policy use
Policy Configuration Policy Repository Execution Engine
• CLI
• Editor
• Syntax Check Filter routes
Attach
policies
Clients
(Protocol)
 The policy language provides two kinds of persistent, namable objects: sets and
policies.
 There are five kinds of sets: as-path-set, community-set, extcommunity- set, prefix-set,
and rd-set
 Definition of sets and policies is bracketed by beginning and ending command lines in
standard CLI syntax.
For example:
route-policy test1
[ . . . Policy statements . . . ]
end-policy
or:
prefix-set test2
[ . . . Prefix set statements . . . ]
end-set
Route Policy
Language
Route Policies Policy Sets
Extended
Community
AS Path Sets Community Prefix Sets
Sets
Sets
 Hierarchical Policy
A Policy that is referenced by another policy with an apply
statement.
route-policy two
apply one
set community (10:100)
end-policy
 Parameterized Policy
A hierarchical policy that passes values
route-policy one ($med)

set med $med
end-policy
route-policy two
apply one (10)
end-policy
route-policy three
apply one (20)
end-policy
 RPL uses generic if-then else relationships for expressing logical
relationships.
route-policy foo
if community matches-every(12:34, 54:78) then
if med eq 8 then
drop
endif
set local-preference 100
endif
end-policy
 Boolean conditions evaluate as either true or false.
 The routing policy language provides means to build
compound conditions from simple conditions by means of
Boolean operators.
 There are three Boolean operators : negation (not),
conjunction (and), and disjunction (or).
if med eq 42 and next-hop in (1.1.1.1) then …
 Boolean operator precedence from highest to lowest is:
negation (not), conjunction (and), and disjunction (or).
Parentheses may be used to force the evaluation differently
than the normal operator precedence.
For example
med eq 10 and not destination in (10.1.3.0/24) or community is (56:78)
is evaluated differently than

med eq 10 and (not destination in (10.1.3.0/24) or community is (56:78))
 RPL has a default drop condition once a policy is applied
 If the route is not accepted it is dropped
 similar behavior to Cisco IOS route maps
 Acceptance determined by
 modifying any route attribute, or
 hitting the pass statement.
•The term set used in its mathematical sense means an
unordered collection of unique elements. The policy language
provides sets as a container for groups of values for matching
purposes.
•They are used in conditional expressions. The elements of the
set are separated by commas.
•There are four kinds of sets: as-path-set, community-set,
extcommunity-set and prefix-set.
•There are two forms for set definition: named form and inline
form.
•Named set form example:
Prefix-set pfset1
10.1.1.0/24,
10.2.2.0/24
end-set
•Inline set form example:
(10.1.1.0/24 , 10.2.2.0/24)
To convert a regular route-map into an RPL policy we will use
the following four steps:
Step 1. Do a simple (direct) syntax translation
Step 2. Nest conditionals to reduce repetitive comparisons
Step 3. Use inline sets to remove small named set references
Step 4. Parameterize to reuse common structures
ip prefix-list 101
10 permit 10.48.0.0/16 le 32
20 permit 172.48.0.0/19
30 permit 192.168.3.0/24
ip prefix-list 102
10 permit 172.16.10.0/24
20 permit 192.168.8.0/21
30 permit 192.168.32.0/21
ip community-list 1
10 permit 10:11
ip community-list 2
10 permit 10:12
ip community-list 3
10 permit 10:13
ip community-list 4
10 permit 10:14
route-map sample1 permit 10 route-map sample2 permit 10
match ip address prefix-list 101 match ip address prefix-list 102
match community 1 match community 1
set metric 11 set metric 11
set community 12:34 additive set community 12:35 additive




Convert the prefix and community lists to their
prefix-set ps101 equivalent RPL set notation.
10.48.0.0/16 le 32,
172.48.0.0/19,
192.168.3.0/24
end-set
prefix-set ps102
172.16.10.0/24,
192.168.8.0/21,
192.168.32.0/21
end-set
community-set cs1
10:11
end-set
community-set cs2
10:12
end-set
community-set cs3
10:13
end-set
community-set cs4
10:14
end-set
Convert the first route map to a RPL “route-
policy”. Use a simple condition (“if” and “else
if” in this example) for every match clause in
the route map and an action statement (in this
case “set”) for every set command in the route
map.
route-policy policy1
if destination in ps101 and community matches-any cs1 then
set med 11
set community 12:34 additive
elseif destination in ps101 and community matches-any cs2 then
set med 12
set med 13
set med 14
elseif destination in ps101
set med 100
endif
end-policy
Convert the second route map as well
using the same type of “if” and “set”
statements. Note the repetitive statements
“if destination…” and “set community..” in
both policies.
if destination in ps102 and community matches-any cs1 then
set med 11
set community (12:35) additive
set med 12
set med 13
set med 14
elseif destination in ps102
set med 100
endif
end-policy
Replace the redundant “if destination in”
conditional and “set community” statements
in the first route policy by just one instance
each.
if destination in ps101 then
if community matches-any cs1 then
set med 11
elseif community matches-any cs2 then
set med 12
set med 13
set med 14
else Leave the nested ‘if community”
set med 100 conditionals to reduce size and
endif
endif
evaluation processing.
end-policy
Perform a similar action on the second
if destination in ps102 then route policy reducing repetitive
set community (12:35) additive conditional statements.
if community matches-any cs1 then
set med 11
set med 12
set med 13
set med 14
else
set med 100
endif
endif
end-policy
Replace small named community sets with
inline sets reducing named set references
route-policy policy1 during policy evaluation.
if community matches-any (10:11) then
set med 11
elseif community matches-any (10:12) then
set med 12
set med 13
set med 14
else
set med 100
endif
endif
end-policy
Perform same replacement of named
community sets in the second route policy.
Note that the two route policies are nearly
if destination in ps102 then identical.
set med 11
set med 12
set med 13
set med 14
else
set med 100
endif
endif
end-policy
Create a parameterized policy block that
Parameter “$tag” replaces contains the common policy structure to
unique community value. be used by the route policies.
route-policy common ($tag)

set community (12:$tag) additive
set med 11
set med 12
set med 13
set med 14
else
set med 100
endif
end-policy
Apply the parameterized policy to replace
the similar policy blocks in both of the
route policies.
apply common (34)
pass
endif
end-policy
apply common (35)
pass
endif
end-policy
•The Command Line Interface (CLI) provides the means to enter
and delete route policy statements. It also provides a unique
means to edit the contents of the policy between the begin-end
brackets using a microemacs editor.
•The name of the object being edited must be included following
the object type in the edit command.
RP/0/0/CPU0:pod1#edit ?
as-path-set edit an as-path-set
community-set edit a community-set
extended-community-set edit an extended-community-set
prefix-set edit a prefix-set
route-policy edit a route-policy
RP/0/0/CPU0:pod1#edit route-policy labtesting
•Instead of each line being an individual command, one can think of each policy or set as a
configuration object that can manipulated as a unit using the edit command.
•After entering the edit route-policy command, a copy of the route-policy or set is copied to a
temporary file and the pico editor is launched. After editing, save the changes by using the
exit command, ^X (control-X). If changes have been made answer Yes and then return saves
the changes. You will then be prompted to commit the configuration changes
•Proceed with commit (yes/no/cancel)? [cancel]:
•If you answer no, the running configuration is not changed and the editing session ends.
•If you answer cancel, the editor continues on in the text buffer from where you left off.
•If you answer yes, the configuration is committed. If there is a syntax error in the policy
object, you notified of the error and also prompted to continue editing or not.
To display the configuration of a specific named route policy, use the
show rpl route-policy <name> command in EXEC mode.
RP/0/RP0/CPU0:router#sh rpl route-policy foo

Tue Nov 8 18:08:27.178 EST
route-policy foo
if destination in test then
drop
endif
end-policy
To display Border Gateway Protocol (BGP) information about networks
that match an outbound route policy, use the show bgp route-policy
<name> command in EXEC mode.
RP/0/RP0/CPU0:router#sh rpl route-policy sample

route-policy sample
if destination in dest1 then
pass
endif
end-policy
RP/0/RP0/CPU0:router#sh rpl prefix-set sample

prefix-set dest1
10.0.0.0/8,
10.0.0.0/24,
10.1.1.1/32
end-set
RP/0/RP0/CPU0:router#sh bgp route-policy sample
Tue Nov 8 18:26:01.756 EST
BGP router identifier 192.168.1.24, local AS number 100
BGP generic scan interval 300 secs
BGP table state: Active
Table ID: 0xe0000000
BGP main routing table version 4690934
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i10.0.0.0/8 172.18.104.1 0 100 0 ?
*>i10.0.0.0/24 69.2.2.2 0 100 0 200 ?
*>i10.1.1.1/32 10.20.20.1 0 100 0 ?
Processed 3 prefixes, 3 paths

show rpl route-policy <name> detail
show rpl route-policy <name> attachpoints
show rpl route-policy <name> references [summary]
show rpl route-policy <name> uses {all | policies | sets} [direct]
Thank you.
TOMORROW Starts Here

RPL Overview

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

RPL Overview

Hochgeladen von

Copyright:

Verfügbare Formate

© 2012 Cisco and/or its affiliates. All rights reserved.

RPL was designed to reduce some of

Policy Configuration Policy Repository Execution Engine

[ . . . Prefix set statements . . . ]

Route Policies Policy Sets

route-policy one ($med)

if med eq 42 and next-hop in (1.1.1.1) then …

is evaluated differently than

•Inline set form example:

Step 1. Do a simple (direct) syntax translation

Step 2. Nest conditionals to reduce repetitive comparisons

Step 3. Use inline sets to remove small named set references

Step 4. Parameterize to reuse common structures

route-map sample1 permit 20 route-map sample2 permit 20

route-map sample1 permit 30 route-map sample2 permit 30

route-map sample1 permit 40 route-map sample2 permit 40

route-map sample1 permit 50 route-map sample2 permit 50

route-policy common ($tag)

RP/0/0/CPU0:pod1#edit route-policy labtesting

•Proceed with commit (yes/no/cancel)? [cancel]:

RP/0/RP0/CPU0:router#sh rpl route-policy foo

RP/0/RP0/CPU0:router#sh rpl route-policy sample

RP/0/RP0/CPU0:router#sh rpl prefix-set sample

Status codes: s suppressed, d damped, h history, * valid, > best

Processed 3 prefixes, 3 paths

show rpl route-policy <name> attachpoints

show rpl route-policy <name> references [summary]

show rpl route-policy <name> uses {all | policies | sets} [direct]

TOMORROW Starts Here

Das könnte Ihnen auch gefallen