ASR9000/XR: Understanding and using RPL (Route Policy Language) - Page 10

xthuijs · ‎01-20-2012

Introduction

In this document I'll discuss the operation, use and some examples on RPL, or the route policy language.

Route policies are mandatory for E-BGP peers, at least a "pass-all" like RPL is required in order to import and export routes.

Core Issue

In IOS we used to have route-maps to control the import, export and manipulation of routes. IOS-XR doesn't have route-maps but something more powerful called route policy language. It is a very programmatic approach in route-maps.

Where as IOS route-maps operate as a series of statements which are executed sequentially, Route-policies not only operate sequentially but provide the ability to invoke other route-policies much like a ‘C’-program is able to call separately defined functions. This enables to creation of hierarchical policies. In addition, and most importantly into respect the scope of this paper, route-policies are ‘compiled’ into a run-time executable portion of code.

Editing route policies

When you have configured a route policy that you want to edit afterwards, you need to restart from scratch or copy paste the existing RPL as entering the route-policy configuration would wipe the existing one out:

RP/0/RSP0/CPU0:A9K-BNG(config)#route-policy test

RP/0/RSP0/CPU0:A9K-BNG(config-rpl)#if med eq 100 then

RP/0/RSP0/CPU0:A9K-BNG(config-rpl-if)#set local-preference 100

RP/0/RSP0/CPU0:A9K-BNG(config-rpl-if)#endif

RP/0/RSP0/CPU0:A9K-BNG(config-rpl)#end-policy

RP/0/RSP0/CPU0:A9K-BNG(config)#commit

RP/0/RSP0/CPU0:A9K-BNG(config)#

RP/0/RSP0/CPU0:A9K-BNG(config)#route-policy test

Fri Jan 20 14:58:39.900 EDT

% WARNING: Policy object route-policy test' exists! Reconfiguring it via CLI wil

l replace current definition. Use 'abort to cancel.

RP/0/RSP0/CPU0:A9K-BNG(config-rpl)#

RP/0/RSP0/CPU0:A9K-BNG(config-rpl)#if local-preference eq 123 then

RP/0/RSP0/CPU0:A9K-BNG(config-rpl-if)#set origin incomplete

RP/0/RSP0/CPU0:A9K-BNG(config-rpl-if)#endif

RP/0/RSP0/CPU0:A9K-BNG(config-rpl)#end-policy

RP/0/RSP0/CPU0:A9K-BNG(config)#commit

RP/0/RSP0/CPU0:A9K-BNG(config)#do sh run route-policy test

Fri Jan 20 14:59:53.705 EDT

route-policy test

if local-preference eq 123 then

set origin incomplete

endif

end-policy

!

As you can see the previous if statement is completely gone, copy pasting and offline editing are also not very easy to use! There is a solution!

RP/0/RSP0/CPU0:A9K-BNG#edit route-policy test ?

emacs to use Emacs editor

nano to use nano editor

vim to use Vim editor

<cr>

I tend to prefer VI and then you can edit your RPL in a VI like manner:

Editting screen:

route-policy test

if local-preference eq 123 then

set origin incomplete

else if med eq 100 then

set weight 44

endif

end-policy

!

~

I am inserting the bold italic lines and press "ZZ" to exit and save the VI editor. (Note I made a config error in RED)

~

"/dev/shmem/rpl_edit.115790135" 8 lines, 149 characters written

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

Now the config error here by splitting "else if" and look what happens when I try to commit:

Parsing.

149 bytes parsed in 1 sec (148)bytes/sec

% Syntax/Authorization errors in one or more commands.!! SYNTAX/AUTHORIZATION ER

RORS: This configuration failed due to

!! one or more of the following reasons:

!! - the entered commands do not exist,

!! - the entered commands have errors in their syntax,

!! - the software packages containing the commands are not active,

!! - the current user is not a member of a task-group that has

!! permissions to use the commands.

else if med eq 100 then

set weight 44

endif

end-policy

Continue editing? [no]:yes

"/dev/shmem/rpl_edit.115790135" 8 lines, 145 characters written

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

Parsing.

145 bytes parsed in 1 sec (144)bytes/sec

Committing.

Prepared commit in 0 sec

1 items committed in 1 sec (0)items/sec

Updating.RP/0/RSP0/CPU0:Jan 20 15:04:20.101 : config[65848]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'root'. Use 'show configuration commit changes 1000000522' to view the changes.

Updated Commit database in 1 sec

RP/0/RSP0/CPU0:A9K-BNG#

So from now one when you want to edit RPL's, prefix sets or as-sets or community sets, use this editor

RP/0/RSP0/CPU0:A9K-BNG#edit ?

as-path-set edit an as-path-set

community-set edit a community-set

extcommunity-set edit an extended-community-set

policy-global edit policy-global definitions

prefix-set edit a prefix-set

rd-set edit a rd-set

route-policy edit a route-policy

RPL operation

RPL Actions

The route policy requires a "ticket" for the route to be accepted or dropped. These are the different operatators

• Pass – prefix allowed if not later dropped

pass grants a ticket to defeat default drop

Execution continues after pass

• Set – value changed, prefix allowed if not later dropped

Any set at any level grants a ticket

Execution continues after set

Values can be set more than once

• Done – prefix allowed, stop execution

• Drop – prefix is discarded

Explicit drop stops policy execution

Implicit drop (if policy runs to end without getting a ticket)

One thing important to add is here that if you have a policy that is "sequential" like

if med 10 then

set med 20

endif

if med 20 then

drop

endif

the execution will NOT drop prefixes with MED10. The reason for that is, although somewhat counter intuitive, that the sequence of operation uses the ORIGINAL value during processing, hence the second if statement will not match for the what was original med of 10...

If you like to get the behavior that both 10 and 20 are dropped, you could do something like this:

if med 10 then drop

else if med 20 then drop

else pass

endif

Don't forget the final pass, as there is an implicit deny.

Hierachical policies

The ability to reference one policy in another

route-policy one

set weight 100

end-policy

route-policy two

set med 200

end-policy

route-policy three

apply two

set community (2:666) additive

end-policy

route-policy four

apply one

apply three

pass

end-policy

Parameter Passing

The ability to call one policy with a variable to be used in another policy:

route-policy one ($med)

set med $med

end-policy

route-policy two

apply one (10)

end-policy

Or with 2 variables:

route-policy three ($med,$origin)

set med $med

set origin $origin

end-policy

route-policy four

apply three (10, incomplete)

end-policy

Inline vs. Named sets

In your RPL you can put the prefix set or as-path etc in the IF statement construction or you can reference a separate set with the AS-list.

They look like the following:

Inline:

route-policy use_inline

if as-path in (ios-regex '_42$', ios-regex '_127$') then

pass

else

drop

endif

end-policy

Named-Set:

as-path-set named_set

ios-regex '_42$',

ios-regex '_127$'

end-set

route-policy use_named

if as-path in named_set then

pass

else

drop

endif

end-policy

There is a performance difference between teh two. the Named Set is obviously slightly slower, but is easier to manage especially when the list gets long. I would personally recommend for short lists to use inline and for longer lists to use the named-set.

Each individual set element results in a separate call to the expression engine:

as-path-set as_51

ios-regex ‘_2129$’,

ios-regex ‘_2147$’,

ios-regex ‘_2856$’,

ios-regex ‘_3486$’,

ios-regex ‘_6432$’,

ios-regex ‘_6468$’,

ios-regex ‘_7310$’,

ios-regex ‘_7768$’,

ios-regex ‘_7862$’,

ios-regex ‘_8296$’

end-set

The same set can be written as follows:

as-path-set as_51

ios-regex '_(2129|2147|2856|3486|6432|6468|7310|7768|7862|8296)$'

end-set

Example AS-Path-Set, Community-Set and Prefix-Set

AS-PATH

as-path-set aset1

ios-regex ’_42$’,

ios-regex ’_127$’

end-set

Prefix-Set

prefix-set galaga

171.68.118.0/24,

192.168.0.0/16 ge 16 le 30

end-set

Community-Set

community-set cset1

12:34,

12:78,

internet

end-set

•Match by value, wildcard, or regular expression

•2 16 bit values separated by colons

•Support for common community keywords

internet

local-AS

no-advertise

no-export

private-as

Show commands

show bgp policy route-policy <name>

Only display prefixes matching policy – filter show command

RP/0/0/CPU0:XR#show rpl route-policy states

ACTIVE -- Referenced by at least one policy which is attached

INACTIVE -- Only referenced by policies which are not attached

UNUSED -- Not attached (directly or indirectly) and not referenced

Working with Prefix-Sets

Here some examples of using prefix-sets. The use of the variable masks is not easy to understand and I found the CCO documentation not very explanatory, so here a few extra words on that.

Prefix: Explanation:

10.0.1.1, match only one possible value, 10.0.1.1/32, mask omitted means 32.

10.0.2.0/24, match only one possible value, 10.0.2.0/24

10.0.3.0/24 ge 28, match a range of prefix values, from 10.0.3.0/28 to 10.0.3.255/32

10.0.4.0/24 le 28, match a range of values, from 10.0.4.0 to 10.0.4.240 (eg we can’t “reach” the last 4 bits)

10.0.5.0/24 ge 26 le 30, matches prefixes in the range from 10.0.5.0/26 to 10.0.5.252/30

10.0.6.0/24 eq 28 match any prefix of length 28 in the range from 10.0.6.0/28 through 10.0.6.240/28

10.0.7.2/32 ge 16 le 24, matches any prefix of length 32 in the range 10.0.[0..255].2/32 (from 10.0.0.2/32 to 10.0.255.2). This is a little funky given the “7” in the 3^rd octet which effectively becomes don’t care.

10.0.8.0/26 ge 8 le 16 matches any prefix of length 26 in the range 10.[0..255].8.0/26 (from 10.0.8.0/26 to 10.255.8.0/26)

Let me visualize it with some real outputs.

I am using an RPL that sets the local pref to 1234 if it matches the prefix set, and that prefix set is as per the above sample list.

10.0.3.0/24 ge 28, match a range of prefix values, from 10.0.3.0/28 to 10.0.3.255/32

=> What is excluded here ? Is 10.0.3.128 excluded from the prefix range ?

Whether the .128 is excluded or not, depends on the mask of the prefix being advertised.

Basically what this means is that if the mask of the route is larger or equal than 28 (so 29,30,31,32) then it matches:

Network Next Hop Metric LocPrf Weight Path

*>i10.0.3.0/28 8.1.1.1 100 1234 0 2 3 {4} i

*>i10.0.3.16/28 8.1.1.1 100 1234 0 2 {3,4} i

*>i10.0.3.32/28 8.1.1.1 100 1234 0 2 3 {4,5} i

*>i10.0.3.48/28 8.1.1.1 100 1234 0 2 i

*>i10.0.3.0/26 8.1.1.1 100 300 0 2 3 {4} i

*>i10.0.3.64/26 8.1.1.1 100 300 0 2 {3,4} i

*>i10.0.3.2/31 8.1.1.1 100 1234 0 2 {3,4} i

*>i10.0.3.4/31 8.1.1.1 100 1234 0 2 3 {4,5} i

*>i10.0.3.6/31 8.1.1.1 100 1234 0 2 i

*>i10.0.3.0/24 8.1.1.1 100 300 0 2 3 {4} i

10.0.4.0/24 le 28, match a range of values, from 10.0.4.0 to 10.0.4.240 (eg we can’t “reach” the last 4 bits)

=> What is excluded here ? 10.0.4.1, .2, .3, .17, .18,.19,.20, etc?

Same as before, but now where the mask is less than 28, so routes in the 10.0.4.x range that have a mask that is shorter 28 will get “hit”.

The mask on the prefix itself sets the “base”. Eg 10.0.3 would not match here as it is not part of the 10.0.4.0/24. Seems obvious but just to be clear ...

Network Next Hop Metric LocPrf Weight Path

*>i10.0.4.0/24 8.1.1.1 100 1234 0 2 3 {4} i

*>i10.0.4.0/26 8.1.1.1 100 1234 0 2 3 {4} i

*>i10.0.4.64/26 8.1.1.1 100 1234 0 2 {3,4} i

*>i10.0.4.128/26 8.1.1.1 100 1234 0 2 3 {4,5} i

*>i10.0.4.48/28 8.1.1.1 100 1234 0 2 i

*>i10.0.4.64/28 8.1.1.1 100 1234 0 2 3 {4,5} i

*>i10.0.4.24/30 8.1.1.1 100 300 0 2 3 i

*>i10.0.4.28/30 8.1.1.1 100 300 0 2 {3} i

10.0.5.0/24 ge 26 le 30, matches prefixes in the range from 10.0.5.0/26 to 10.0.5.252/30

Combining the previous two together on the .5.0 range:

*>i10.0.5.4/30 8.1.1.1 100 1234 0 2 {3,4} i

*>i10.0.5.8/30 8.1.1.1 100 1234 0 2 3 {4,5} i

*>i10.0.5.12/30 8.1.1.1 100 1234 0 2 i

*>i10.0.5.4/31 8.1.1.1 100 300 0 2 3 {4,5} i

*>i10.0.5.6/31 8.1.1.1 100 300 0 2 i

*>i10.0.5.5/32 8.1.1.1 100 300 0 2 3 {4,5,6} i

*>i10.0.5.6/32 8.1.1.1 100 300 0 2 3 i

*>i10.0.5.0/25 8.1.1.1 100 300 0 2 3 {4} i

*>i10.0.5.128/25 8.1.1.1 100 300 0 2 {3,4} i

*>i10.0.5.64/26 8.1.1.1 100 1234 0 2 {3,4} i

*>i10.0.5.128/26 8.1.1.1 100 1234 0 2 3 {4,5} i

10.0.7.2/32 ge 16 le 24, matches any prefix of length 32 in the range 10.0.[0..255].2/32 (from 10.0.0.2/32 to 10.0.255.2). This is a little funky given the “7” in the 3^rd octet which effectively becomes don’t care.

*>i10.0.7.2/32 8.1.1.1 100 1234 0 2 3 {4} i

*>i10.0.7.3/32 8.1.1.1 100 300 0 2 {3,4} i

*>i10.0.0.2/32 8.1.1.1 100 1234 0 2 3 {4} i

*>i10.0.0.3/32 8.1.1.1 100 300 0 2 {3,4} i

*>i10.1.7.2/32 8.1.1.1 100 300 0 2 3 {4} I <<doesn’t match because of 2^nd octet

If I slightly change the prefix statement to: 10.0.7.4/32 ge 16 le 24

*>i10.0.7.0/30 8.1.1.1 100 300 0 2 3 {4} i

*>i10.0.7.4/30 8.1.1.1 100 300 0 2 {3,4} i

*>i10.0.7.8/30 8.1.1.1 100 300 0 2 3 {4,5} i

Still no match as the base mask is not met on the prefixes received.

So the /<whatever> determines the MASK of the route I wanted to match. whereas the GE/LE provide me the variance in either that mask (if bigger) or from the other octects (if smaller then the /mask)

Verifying performance of your RPL

To determine what in your route-policy is consuming the majority of the time, you can use route profiling.

It allows some data collection in the background with minimal impact on the execution of the rpl. After the collection has been running for some time you can use show commands to find out which steps take a lot of time in the execution and make some improvements.

Once we figure out which portion of the policy is performance drag, its much easier to try out an alternative. Something like regex match always failing means we need to evaluate route using prefix match prior to validating its as-paths.

Example usage:

debug pcl profile detail

then

Router# show pcl protocol bgp 10 neighbor-in-dflt default-IPv4-Uni-1.2.3.4 policy profile

Policy execution profile

Protocol : bgp 10

Attachpoint : neighbor-in-dflt

AP Instance : default-IPv4-Uni-1.2.3.4

Policy Name : rpl_profile(nexthop)

Pass : 10

Drop : 5

Total : 15

Avg execution time : 110usec

Router#sh rpl route-policy rpl_profile detail

route-policy test

apply test2

done

end-policy

!

route-policy test2

delete extcommunity rt all

end-policy

!

route-policy rpl_profile($p_nexthop)

if next-hop in $p_nexthop then

set local-preference 155

set med 155

else

set local-preference 77

set med 77

endif

set community (0:0)

apply test

set extcommunity rt (1:1)

end-policy

!

Router# show pcl protocol bgp 10 neighbor-in-dflt default-IPv4-Uni-1.2.3.4 policy profile detail

Policy execution profile

Protocol : bgp 10

Attachpoint : neighbor-in-dflt

AP Instance : default-IPv4-Uni-1.2.3.4

Policy : rpl_profile(nexthop)

Pass : 15

Drop : 0

Total : 15

Avg execution time : 110usec

Node Id Num visited Avg exec time Policy operation

--------------------------------------------------------------------------------

15 0usec route-policy rpl_profile

PXL_0_5 15 99usec if next-hop pfxmatch ... then

PXL_0_3 10 0usec set local-preference 155

PXL_0_4 10 0usec set med 155

PXL_0_6 15 0usec community assign

15 0usec route-policy test

15 0usec route-policy test2

PXL_0_1 15 0usec rt delete-all

15 0usec

PXL_0_2 15 0usec

PXL_0_8 0 0usec rt assign

0 0usec

PXL_0_1 5 0usec set local-preference 77

PXL_0_2 5 0usec set med 77

GOTO : PXL_0_6

0 0usec

Router#

Usable attachpoints for RPL

Changing or modifying Route policies (or prefix/community sets)

As you have noticed when editting RPL's you need to reconfigure the complete policy in the regular CLI. An easier method is using the "edit" option described above.

When you are changing your RPL or prefix-set or any other list that RPL is using, it will trigger a few things:

If the RPL is used for BGP and your peer is not REFRESH capable, it will restart your BGP session.

If the peer is REFRESH capable a full table refresh is executed.

The reason for that is, that the RPL change or say prefix set change could have excluded some routes before that now may need to be imported.

On the Receiving Side:

For BGP, routes that are filtered are completely discarded and are NOT kept in memory with some kind of mark that says bgp rpl filtered.

We will use route refresh to obtain the routes again from the neighbor whenever there is a change in inbound route policy.

For this the neighbor has to be refresh capable, else we have to do clear bgp.

When the BGP peer receives a route refresh request it sends the complete table again to the requesting peer. While asking for the table they ask for the relevant (AFI, SAFI) table. When the routes are received from the peer an inbound filter if any is applied and the routes are aggregated.

On the sending side:

if I apply an RPL basically removing some previously advertised route, would BGP send withdraws for these now filtered routes?

What would rpl/bgp do when the RPL is modified to:

1) do advertise some previously filtered routes

To advertise previously filtered routes it is similar to regular advertising of routes

2) stop advertising previously advertised routes

BGP will send withdraws when it stops advertising previously filtered routes.

Xander Thuijs, CCIE #6775

Sr. Tech Lead ASR9000

jmarque2 · ‎06-21-2018

Hi Team,

My customer is trying to implement PBR on ASR9K (as I could see now PBR is not supported on IOS XR) but I'm not completely understanding PRL. The request is as follow:

Customer has an specific subnet that he needs to go to an specific host ignoring the routing protocol running on the ASR9K. Can I anyone provide some guidance?

Marco Marzetti · ‎10-05-2018

Hello Xander,

As per my understanding Cisco sort o recommends to use declarative syntax like originates-from or neighbor-is instead of ios-regex because of the latter is more CPU intensive

Here's a quote from one of your docs:

Spoiler

Regular expression matching is CPU intensive. The policy performance can be substantially improved by
either collapsing the regular expression patterns together to reduce the total number of regular expression
invocations or by using equivalent native as-path match operations such as ‘as-path neighbor-is’, ‘as-path
originates-from’ or ‘as-path passes-through’.

Regular expression matching is CPU intensive. The policy performance can be substantially improved byeither collapsing the regular expression patterns together to reduce the total number of regular expressioninvocations or by using equivalent native as-path match operations such as ‘as-path neighbor-is’, ‘as-pathoriginates-from’ or ‘as-path passes-through’.

With that in mind i am trying to write the less-taxing policy to check if a peer is sending routes with only 1 given AS in the as-path.

Here's what i came up with so far:

IOS-REGEX:

as-path-set ASPATH_64496
 ios-regex '^64496+$'
end-set

Declarative:

route-policy ASPATH_64496
 if as-path originates-from '64496' and as-path unique-length eq 1 then
  pass
 else
  drop
end-policy

Now if i understand the paragraph above correctly i'd say in this case IOS-REGEX could be more efficient then Declarative because of the single invocation.

Does it make sense?

Thank you

Regards

3Dg4RIP · ‎10-25-2018

Thanks for sharing this information, very useful in my activities.

feableee123 · ‎02-03-2020

Hello Xander,

I would like to prepend only one local prefix and the rest prefixes advertise without prepending,
Is the configuration below correct ?

route-policy prepend-prefix-X
if destination in (x.x.x.x/20) then
prepend as-path AS-NUMBER-YYYY 2
else
pass
endif
end-policy

philclemens1835 · ‎02-03-2020

I'm no Xander, but that looks good. I suggest making your prefix part of a prefix set, even if it only contains one.

prefix-set prepend-prefix-X

x.x.x.x/20

end-set

So, your first line becomes:

if destination in prepend-prefix-X then

That way you can add to it later with vi: edit prefix-set prepend-prefix-X vim

It can look something like this:

prefix-set prepend-prefix-X

x.x.x.x/20 ge 20,

y.y.y.y/16 ge 16

end-set

feableee123 · ‎02-04-2020

Thanks philclemens1835

it works.