cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
145605
Views
50
Helpful
141
Comments
xthuijs
Cisco Employee
Cisco Employee

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)

 

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 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

Comments
xthuijs
Cisco Employee
Cisco Employee

hi denis the attach point for the RPL is at the import of routes received through MP BGP. So the routes that are being received from a remote PE we will be able to modify via that RPL.

the prefix that you have in your table is what seems to be a locally injected route because the next hop is 0.0.0.0 and possibly pulled in via a redistribute or network command.

If you want to modify the prefix, then that needs to be done there at the network statement or redistribute attach point.

regards!

xander

Denis Mulyalin
Beginner
Beginner

Hi Alexander, thanks for reply,

 

My bad, here is additional info - there are two routers PE1 and PE2 - the output provided above from PE1, on PE2 I inject into bgp prefix 2.2.2.2/32 and while importing this prefix on PE1 I want to change the next-hop value.

So here is the prefix that I received on PE1 from PE2 and that I want to import into vrf with next-hop changing:

PE1#show bgp vpnv4 un rd 10.69.72.3:1234 2.2.2.2/32
Tue Jul  7 12:34:49.810 msk
BGP routing table entry for 2.2.2.2/32, Route Distinguisher: 10.69.72.3:1234
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker           24828298    24828298
Last Modified: Jul  6 09:36:42.402 for 1d02h
Paths: (3 available, best #3)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    10.69.72.3 (metric 20) from 10.3.72.4 (10.69.72.3)
      Received Label 18655
      Origin IGP, metric 0, localpref 100, valid, internal, not-in-vrf
      Received Path ID 1, Local Path ID 0, version 0
      Extended community: RT:1234:1234
      Originator: 10.69.72.3, Cluster list: 10.3.72.4

so, as you can see the RT is correct, however PE1 does not perform importing of this prefix into VRF test1234:

PE1#show bgp vrf test1234
Mon Jul  6 10:18:02.667 msk
BGP VRF test1234, state: Active
BGP Route Distinguisher: 10.69.72.0:1234
VRF ID: 0x6000001d
BGP router identifier 10.69.72.0, local AS number 39374
BGP table state: Active
Table ID: 0xe000002c   RD version: 24837099
BGP main routing table version 24841947

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
Route Distinguisher: 10.69.72.0:1234 (default for vrf test1234)
*> 1.1.1.1/32         0.0.0.0                  0         32768 i

xthuijs
Cisco Employee
Cisco Employee

it sounds like the RPL is not matching the if clause.

and since there is no else, it will end up in a drop and discard of the route.

basically this RPL wants to rewrite all received routes for that RT with the new next hop, so why dont we simplify this rpl without that if ext comm rt is blabla to just set the

next hop of the route without that "if".

doable?

or add the following to your existing rpl:

else

set next-hop x.x.x.x

pass

end if

 

cheers!

xander

Denis Mulyalin
Beginner
Beginner

Hi again,

I've tryed this but with the same outcome

PE1#show run route-policy IMPORT_to_vrf_test1234
route-policy IMPORT_to_vrf_test1234
  set next-hop 3.3.3.3
  pass
end-policy
!

PE1#show run vrf test1234
vrf test1234
 address-family ipv4 unicast
  import route-policy IMPORT_to_vrf_test1234
  export route-target
   1234:1234
  !
PE1#show bgp vpnv4 un rd 10.69.72.3:1234 2.2.2.2/32
BGP routing table entry for 2.2.2.2/32, Route Distinguisher: 10.69.72.3:1234
Paths: (3 available, best #3)
  Not advertised to any peer
  Path #3: Received by speaker 0
  Not advertised to any peer
  Local
    10.69.72.3 (metric 20) from 10.69.72.3 (10.69.72.3)
      Received Label 18655
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, not-in-vrf
      Received Path ID 0, Local Path ID 1, version 24828298
      Extended community: RT:1234:1234

PE1#show bgp vrf test1234                          
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 10.69.72.0:1234 (default for vrf test1234)
*> 1.1.1.1/32         0.0.0.0                  0         32768 i

Processed 1 prefixes, 1 paths
PE1#show route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "static", distance 1, metric 0 (connected)
  Installed Jul  7 12:54:49.298 for 21:41:32
  Routing Descriptor Blocks
    directly connected, via tunnel-te1234
      Route metric is 0
  No advertising protos.

PE1#show route vrf test1234

L    1.1.1.1/32 is directly connected, 2d01h, Loopback1234
S    3.3.3.3/32 is directly connected, 00:02:04, Null0

PE1#

Bryan Garland
Cisco Employee
Cisco Employee

Denis,

Apply the RPL policy under the bgp neighbor, not in the vrf definition.  That should work then.

 

Thanks,

Bryan

Denis Mulyalin
Beginner
Beginner

Hi,

maybe it will be useful for somebody, I have opened a case in Cisco TAC and found out that this config works fine for me:

vrf test1234
 address-family ipv4 unicast
  import route-policy IMPORT_to_vrf_test1234
  import route-target
   1234:1234
!

  export route-target
   1234:1234

!
route-policy IMPORT_to_vrf_test1234
  set next-hop 3.3.3.3
  pass
end-policy
!
router static
 address-family ipv4 unicast
  3.3.3.3/32 tunnel-te1234

PE1# show route vrf test1234
L    1.1.1.1/32 is directly connected, 4d06h, Loopback1234
B    2.2.2.2/32 [200/0] via 3.3.3.3 (nexthop in vrf default), 00:20:40

PE1#ping vrf test1234 2.2.2.2 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

and the output of cef is perfectly correct, the ultimate goal of steering traffic into the rsvp tunnel on ingress pe is archived:
RP/0/RSP0/CPU0:EK000023-BBR01#     show cef vrf test1234 2.2.2.2        
Fri Jul 10 16:06:34.180 msk
2.2.2.2/32, version 12, internal 0x14004001 0x0 (ptr 0x718fe6b4) [1], 0x0 (0x0), 0x410 (0x722d9440)
 Updated Jul 10 15:35:40.349
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
   via 3.3.3.3, 3 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x723d03a4 0x0]
    next hop VRF - 'default', table - 0xe0000000
    next hop 3.3.3.3 via 19118/0/21
     next hop 0.0.0.0/32 tt1234       labels imposed {ImplNull 18655}
RP/0/RSP0/CPU0:EK000023-BBR01#

ipv6 B
Beginner
Beginner

So, actually there is a difference (as you explained to wblackcenic 5 months ago)

 

>Great explanation of the RPL function, however, I was hoping you could help clarify one thing.  >If there are multiple elseif statements in a policy and two or more elseif statements match a >particular route, which statement gets applied? 

>For example:

...

...

>In case you do the same thing, but then with an elseif:

>if TEST-1 then

> set SOMETHING to "X"

> elseif TEST-2 then

> set SOMETHING to "Y"

>end

...

In that case if both TEST-1 and TEST-2 are both true again, after the TEST-1 setting, you'll end up with "X" since the elseIF is not interpreted anymore.

Best Regards,

xthuijs
Cisco Employee
Cisco Employee

hey vladov, yes the if/else vs if/elseif have a different flow obviously,

for the example that was given/asked about, the outcome is the same:

since evaluating MED will only result in one if case being executed as set. (I mean the MED cannot have 2 values or resulting in 2 set actions).

So yes there is a difference, but for the callfow asked about the outcome is the same between the 2 options.

cheers!

xander

ipv6 B
Beginner
Beginner

Dear Alexander,

Yes, for simple number comparison , there should be no real difference, and you're correct.

But for for complex (text/other) comparison it might be very different.

I just wanted to show this subtle difference.

Best Regards,

Z.Vladov

xthuijs
Cisco Employee
Cisco Employee

ok perfect, yeah I could have been more clear indeed Vladov and thanks for the contribution/addition!!!

that's what makes forums like this valuable!!

cheers!

xander

mjgarate
Beginner
Beginner

Hi Xander, is there a way to optimize the rpl execution time.I'm using the next rpl as a conditional advertisement in bgp,

route-policy DEFAULT_ROUTE
  if rib-has-route in NET1 and rib-has-route in NET2 and rib-has-route in default_route then
    set community COMM
  endif
end-policy

However, the neighbor is taking so long to get the bgp update to remove the default route, the time is about 40 seconds after the condition is met, once we could notice there is not NET1 or NET2 or default route in the rib.

It doesn't seems to be a bgp or other routing protocol problem because other updates takes 3 seconds to refresh.

any help is really appreciated.

regards

Mario

 

 

xthuijs
Cisco Employee
Cisco Employee

hi mario,

there is always a delay between the trigger for the rib has route to the execution of it.

few things are in play here:

1- reception/update of the rib-has-route particular route

2- rib installation of that

3- trigger sent to the application/client

4- rpl processing of that trigger and

5- bgp updating its based on the rpl execution.

The last 2 pieces (4&5) are generally very fast, usecs.

I suspect that a delay might be in 2 or 3.

This needs some further investigation that probably is best handled via a tac case to collect some traces etc and see if there is something that is amiss or requires change whether it be in sw or config.

regards

xander

fcotofaj
Community Member

Xander thank you let me just make sure.

The RPL permit is not needed for eBGP confederation peers, is that correct?

We need to explicitly permit prefixes with external neighbors, but what about confederation peers? Does this apply? Thanks,

Fede.
 

eberd
Beginner
Beginner

Hello Xander, 

I was wondering whether we can define a parameterized route-policy and have one or more of the parameters as optional.

e.g

route-policy set_comm($as,$comm1,$comm2,..,$commN)

   set community($as:$comm1,$as:$comm2,...,$as:$commN)

end-policy

and use it to set at least one community to a route by not entering values for $comm2 up to $commN. 

Thank you, 

Eirini

xthuijs
Cisco Employee
Cisco Employee

I see what you want to do Eirini, but it is like a programming function: if the function wants to receive 5 variables, you need to pass them all.

You could do something like this:

($com1, $com2, $com3) and if you call the function like (100,0,0) or (200,10,0) then you can check on the value being (non) zero and add only the non zero values.

would that work?

or we also have some global vars that you may want to play with (in 513 onwards).

xander

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers
Quick Links