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

Document

Feb 23, 2015 6:34 AM
Jan 20th, 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

1_RPL_elements.jpg

2_RPL_boolean.jpg

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)

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 3rd 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 3rd 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 2nd 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

attacpoint.PNG

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

Overall Rating: 5 (3 ratings)
Alessio Andreoli Wed, 05/02/2012 - 09:10

Very nice doc!

I am looking for something more extensive and with more syntax than your article to be hones but yours is a very helpful and clear guide. thanks again

PS: If you know very good books about IOS XR and RPL please just let me know!

Alessio

Alexander Thuijs Wed, 05/02/2012 - 11:24

Alessio, thanks for your comment, I'd love to provide some more content, but can you let me know with a few examples what you are looking for?

Some sample RPL policies that do XYZ or...?

xander

Alessio Andreoli Wed, 05/02/2012 - 13:52

Hi Alexander,

of course i am writing only to answer to you and there is no purpose to let you write a manual of RPL!!! I assume we can say that RPL is a scripting language and as such there will be some structures and building blocks which will be used each time we write down what a policy can or can't do. it would be interesting to read a bit of theory about RPL to (at least for me) reuse the concepts learned to build new policies and enable new applications. In my opinion you just did an excellent work .. i just would like to master the ideas beyond RPL to use it in the craziest (and most useful) ways.Thanks anyway, i am not tired to repeat that i really enjoyed your article
Alessio

bedgewor Fri, 01/16/2015 - 11:35

Hi Alessio,

 

As a supplement to this awesome article that Alexander put together, I recommend that you pick up a copy of my book IP Routing on Cisco IOS, IOS XE, and IOS XR  ( http://goo.gl/7FNfVr ).   Chapter 11 (~82 pages) goes into detail on IOS XR's RPL in the back half of the chapter.

Happy Labbing,

-brad

Purwo Hidayat Mon, 10/08/2012 - 21:03

Hi Alex,

Thanks for the sharing, its very good article.

but there is a question in my mind after read about editing the RPL.

here is what i've been curious.

Let say i've configured an eBGP connection with RPLs below

extcommunity-set rt rt-asbr-in

65200:100

end-set

!

extcommunity-set rt rt-asbr-out

65200:100

end-set

!

route-policy rp-rt-asbr-in

if extcommunity rt matches-any rt-asbr-in then

  pass

endif

end-policy

!

route-policy rp-rt-asbr-out

if extcommunity rt matches-any rt-asbr-out then

  pass

endif

end-policy

will the running traffics(vrf with 65200:100) drop when editing(add) new RT in those RPL?

Thanks in advance, and sorry for my bad English

Purwo

Alexander Thuijs Tue, 10/09/2012 - 04:15

hi Purwo,

In this configuration you will only allow the ext comm 65200:100 to be imported/received and you will only advertise these comms to your peer. Everything else will be dropped.

When you modify the outbound policy, we send updates to the peer and withdraws.

When you modify tthe inbound policy, if the peer is route refresh capable we'll use that, otherwise if osft reconfig inbound is configured, we use that shadow table, or finally as last resort clear the peering.

Clearing the peering will result in traffic drops directly.

All the others are done inline.

xander

Purwo Hidayat Tue, 10/09/2012 - 04:35

hi Xander,

Thanks for your kindly answer.

As for now i'm looking to know about route-refresh more detail. I'll search in this forum.

Have a nice day Xander,

Purwo

budilasmono Wed, 10/31/2012 - 20:28

Hi Alexander,

Can you explain about RPL testing ?

Because i still dont understand about rpl instance name, instance id ? and searching thru cisco doc, i cant get the example.

If the customer got :

route-policy testing

apply policy-new

!

route-policy policy_new

   if as-path in as-23700 then

     if destination in Pfx_AKAMAI then

       set community (65503:18705)

     elseif destination in Pfx_P01 then

       set community (7632:1118, 65503:18705)

     endif

   endif

end-policy

router bgp 23700

  add ipv4 uni

   neigh 1.2.

    add ipv4 uni

      route-policy testing out

!

how the debug command will be, and how the show command to measure route-policy testing performance ?

Thanks a lot,

Budi

jeanmariengokgwem Tue, 07/01/2014 - 16:32

Hello Xander,

 

I am converting Junos Policies to IOS-XR policies could you please help achieving this task ? Or at least advise how to proceed ? 

 

Thanks,

Jean-Marie (J-M)

Alexander Thuijs Wed, 07/02/2014 - 03:38

Hi JeanMarie, we can possibly help with that of course.

Either you can post your junos policy here so we can review it and post back an XR RPL equivalent, or if you prefer not to have your policy public, which I can understand too of course, maybe it is best to open a tac case and mention our discussion to the tac engineer in case he needs a pointer with the conversion for you.

regards

xander

tomek0001 Wed, 10/08/2014 - 12:31

Would you be able to clarify using "apply" keyword in the if statement?

Using the example from the link below:

 

If apply policyA and apply policyB then
 Set med 100
Else if not apply policyD then
 Set med 200
Else
 Set med 300
Endif
End-policy

what would be considered TRUE return from policyA or policyB for the first if condition to match setting the med to 100?

I

http://www.cisco.com/c/en/us/td/docs/routers/xr12000/software/xr12k_r4-2/routing/command/reference/b_routing_cr42xr12k/b_routing_cr42xr12k_chapter_01000.html#wp8617808920

 

Thank you.

Alexander Thuijs Thu, 10/09/2014 - 06:59

great question and I had to do some research on that one :)

I verified some behavior that I cross checked with our RPL dev group and this is the outcome:

To enter in else path, the conditional policy execution should not execute any set statement or pass statement.

A drop will always cause the route to drop. If you set or pass in the "if apply <POLICY>" then it enters the true path on return. If you have a "done" in the "if apply <POLICY>" you will enter the FALSE path.

cheers

xander

tomek0001 Wed, 10/08/2014 - 12:37

For the performance testing of RPLs can you verify RPLs attached to other address-families such as VPNv4/v6 etc. I could only find info on default-IPv4-Uni-1.2.3.4 or is it not address-family dependent? I'm looking for commands to verify vpnv4, vpnv6, ipv6, attached RPLs ...etc.

AP Instance : default-IPv4-Uni-1.2.3.4

 

Thank you.

Alexander Thuijs Thu, 10/09/2014 - 04:31

If the neighbor configuration in your router bgp has a vpnv4 AF configured, then it will show also in the command, in this case only neigh 123.1.1.2 has a vpvn4 AF defined:

RP/0/RSP0/CPU0:A9K-BNG#show pcl protocol bgp speaker-0 neighbor-in-dflt ?
  default-IPv4-Uni-54.1.1.2         Attachpoint instance
  default-IPv4-Uni-123.1.1.2        Attachpoint instance
  default-VPNv4-Uni-123.1.1.2       Attachpoint instance
  default-IPv4-Uni-131.1.1.2        Attachpoint instance
 

from this BGP config:

 neighbor 54.1.1.2
  remote-as 64524
  address-family ipv4 unicast
   route-policy pass-all in
   maximum-prefix 4294967295 75
   route-policy t out
  !
 !
 neighbor 123.1.1.2
  remote-as 300
  ebgp-multihop 5
  dmz-link-bandwidth
  update-source Loopback123
  address-family ipv4 unicast
   multipath
   route-policy pass-all in
   route-policy pass-all out
  !
  address-family vpnv4 unicast
  !
 !
 neighbor 131.1.1.2
  remote-as 100
  address-family ipv4 unicast
   route-policy pass-all in
   route-policy private-as-check out
   remove-private-AS
  !
 !

xander

racarvalho Thu, 10/16/2014 - 04:50

Hi,

I'm trying to create a extcommunity-set rt  with ios-regex but i can´t create the regular expression, the cli doesn't accept any expression:

RP/0/RSP0/CPU0:A9K-LAB01(config)#extcommunity-set rt PAR

 

RP/0/RSP0/CPU0:A9K-LAB01(config-ext)#?
  #-remark        Remark beginning with '#'
  *               Wildcard (any community or part thereof)
  <1-4294967295>  32-bit decimal number
  <1-65535>       16-bit decimal number
  A.B.C.D/M:N     Extended community - IPv4 prefix format
  A.B.C.D:N       Extended community - IPv4 format
  ASN:N           extended community - ASPLAIN format
  X.Y:N           Extended community - ASDOT format
  abort           Discard RPL definition and return to top level config
  dfa-regex       DFA style regular expression
  end-set         End of set definition
  exit            Exit from this submode
  ios-regex       Traditional IOS style regular expression
  show            Show partial RPL configuration


RP/0/RSP0/CPU0:A9K-LAB01(config-ext)#ios-regex ?
  extcomm-regex  Enter a extcommunity regular expression enclosed in single quotes


RP/0/RSP0/CPU0:A9K-LAB01(config-ext)#ios-regex '65535_.*[13579]$'
                                               ^
% Invalid input detected at '^' marker.

 

Looks like it doesn't accept the single quote as a delimiter.

Using IOS-XR 4.3.4

Thanks,

RAC

Alexander Thuijs Thu, 10/16/2014 - 04:55

I think the problem is that the format that you follow for the ext community doesn't line up.

it needs to be <xxx>:<xxx> type way.

Example:

!! IOS XR Configuration 5.1.2
!
extcommunity-set rt comm_101
  ios-regex '15404:4637_',
  ios-regex '8220:18150_'
end-set
!
end

 

xander

racarvalho Thu, 10/16/2014 - 10:15

Hi Xander,

 

That's it !!!

i was missing the ":", I've read that the underscore was the symbol to use in regular expressions.

 

_ (underscore)

 

Matches a comma (,), left brace ({), right brace (}), the beginning of the string, the end of the string, or a space.

 

http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/getting_started/configuration/guide/gs42crs/gs42aexp.html

 

Thanks

RAC

 

 

Alexander Thuijs Thu, 10/16/2014 - 10:23

Sweet! great to hear that it is the solution! :)

cheers!

xander

imadhassan Sat, 10/18/2014 - 09:17

Thank you for this doc. Very well defined and easy grasp the examples.

 
 
Alexander Thuijs Sat, 10/18/2014 - 09:36

and thank you for the nice comment!! :)

cheers!

xander

mberend Thu, 01/22/2015 - 01:11

Nice article, thanks.

I was wondering is it now impossible to do a route policy on odd and even routes in IOS XR, lets say in the third octet, like it is I believe possible with ACLs/route maps? Basically I don't see the ability to use wildcard masks, only bit length in the prefix sets.

I hope I am making sense with this question :)

 

bedgewor Thu, 01/22/2015 - 03:17

I've never seen this used on a production network before, but yes it is possible.   RPL only allows for the referencing of RPL sets, but inline logic can use wildcard matching.   It gets the trick done, but is not as scalable.

 

Here is the RPL:

 

 

RP/0/RSP0/CPU0:ASR9006-B#show rpl route-policy ACL
route-policy ACL
  if destination in (82.210.0.0 0.0.254.255 ) then
    pass
  endif
end-policy
 

 

BGP Table Before Hand:

 

RP/0/RSP0/CPU0:ASR9006-B#show bgp
<SNIP>
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 82.210.208.124/30  82.210.208.125           0             0 8151 i
*> 82.210.211.4/30    82.210.208.125           0             0 8151 i

Processed 2 prefixes, 2 paths

 

And after testing RPL

 

RP/0/RSP0/CPU0:ASR9006-B#show bgp route-policy ACL
<SNIP>
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 82.210.208.124/30  82.210.208.125           0             0 8151 i

Processed 1 prefixes, 1 paths

 

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

Brad Edgeworth

Author of:  IP Routing on Cisco IOS, IOS XE, and IOS XR 

CCIE# 31574         Routing/Switching & Service Provider

 

 

 

mberend Fri, 01/23/2015 - 02:12

Brad,

 

Thanks, this is great. Didn't know you could do that.

I did once used it in production to influence the uplink destinations to multiple service providers in an attempt to get the most bw in the uplink direction on multiple links. The usefulness is debatable, but it is good to know you can do it :)

 

 

pichet.p@dcs.pr... Mon, 02/23/2015 - 01:58

Hi Xander

 Could you explain me what's the difference between rpl-test1 and rpl-test2 in term of performance or any term. And which one you recommend to deploy it?

==================================
route-policy rpl-test1
 if med eq 100 then
     set local-preference 100 
 elseif med eq 200 then
     set local-preference 200
 elseif med eq 300 then
     set local-preference 300
 elseif med eq 400 then
     set local-preference 400
 else
     set local-preference 0
 endif
==================================
route-policy rpl-test2
 if med eq 100 then
     set local-preference 100 
 endif
 if med eq 200 then
     set local-preference 200 
 endif
 if med eq 300 then
     set local-preference 300 
 endif
 if med eq 400 then
     set local-preference 400 
 else
     set local-preference 0
 endif
end-policy
==================================

 

 

Thank you

Pichet

Alexander Thuijs Mon, 02/23/2015 - 04:15

hi pinchet,

yeah functionally they do the exact same thing. There is also compiler wise not much difference in the way these will get installed. I feel that option 1 is a bit more clear in terms of reading/understanding the operation, but that is a personal thing and has no bearing on the technical aspects of it :).

cheers!

xander

pichet.p@dcs.pr... Mon, 02/23/2015 - 06:34

Thank you. 

 

^_^

Actions

Login or Register to take actions

This Document

Posted January 20, 2012 at 10:47 AM
Updated June 6, 2013 at 9:04 AM
Stats:
Comments:26 Overall Rating:5
Views:31899 Contributors:11
Shares:25
Tags: No tags.