RPL: change prefix attributes based on other prefixes

[rtrunk]

I want to change the local preference (or any other attribute) on incoming prefixes based on the existence of another prefix.

In other words,

if TEST-PREFIX in BGP table,
then set local preference on incoming routes to 200

Something like

IF destination in prefix-set-a
then IF prefix-set-test "In-TABLE"
        set local-preference 200
       else 
        pass
       endif
endif

The conditional "In_Table" doesn't exist, but I was hoping someone had another way to accomplish this.

[xthuijs]

yeah you're looking for the rib_has_route directive. this wokrs only at the default originate attachpoint currently.

we're working on extending this for other RPL operations also, but it is not there yet.

one thing that you can do is using EEM to test some show command and if something changes you reconfigure the rpl from within EEM?

xander

[rtrunk]

Thanks for the reply.  I looked at EEM, but management feels it's too much of a hack to use in production.  Any idea when you might add the directive?  6 months?  Year?  Longer?

[xthuijs · Accepted solution]

we're looking at XR63 which is about a year about, although trying to get it in earlier since its been such a long standing ask already from so many.

cheers!

xander

[Richard Gallagher]

Xander, the add to Ron's question, if we vary what we want to do, in this case, match on an incoming VPNv4 prefixes RT.

Then if the RT match is true apply the local pref changes to another prefix.

What I was testing was something like this:

RP/0/0/CPU0:IOX-1#show rpl route-policy RT detail 
Sat Aug 20 18:25:18.879 UTC
prefix-set DEF
 0.0.0.0/0
end-set
!
route-policy DEF
 if destination in DEF then
 set local-preference 200
 endif
end-policy
!
route-policy RT
 if extcommunity rt matches-any (1:1) then
 apply DEF
 endif
end-policy
!

I am receiving 100.0.0.1 via VPNv4 and the 0.0.0.0/0 is being imported from the default-vrf. I tried attaching as a VRF import map:

vrf VPN1
 address-family ipv4 unicast
 import route-policy RT
 import from default-vrf route-policy PASS advertise-as-vpn
 import route-target
 100:100
 !
 export route-target
 100:100
 !
 !
!

Before apply the above config:

RP/0/0/CPU0:IOX-1#sho bgp vpnv4 unicast vrf VPN1 | b Route
Sat Aug 20 18:23:05.208 UTC
Route Distinguisher: 100:102 (default for vrf VPN1)
*> 0.0.0.0/0 4.0.0.1 0 104 i
* i 10.0.0.3 100 0 105 i
*>i100.0.0.1/32 10.0.0.1 0 100 0 ?

Processed 2 prefixes, 3 paths
RP/0/0/CPU0:IOX-1#

RP/0/0/CPU0:IOX-1#sho bgp vpnv4 unicast vrf VPN1 100.0.0.1
Sat Aug 20 18:23:08.318 UTC
BGP routing table entry for 100.0.0.1/32, Route Distinguisher: 100:102
Versions:
 Process bRIB/RIB SendTblVer
 Speaker 35 35
Last Modified: Aug 20 18:19:36.019 for 00:03:32
Paths: (1 available, best #1)
 Not advertised to any peer
 Path #1: Received by speaker 0
 Not advertised to any peer
 Local
 10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
 Received Label 21
 Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
 Received Path ID 0, Local Path ID 1, version 35
 Extended community: RT:1:1 RT:100:100 
 Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 100:101
RP/0/0/CPU0:IOX-1#

Then after applying the config:

RP/0/0/CPU0:IOX-1#
RP/0/0/CPU0:IOX-1#sho bgp vpnv4 unicast vrf VPN1 | b Route
Sat Aug 20 18:26:54.533 UTC
Route Distinguisher: 100:102 (default for vrf VPN1)
*> 0.0.0.0/0 4.0.0.1 0 104 i

Processed 1 prefixes, 1 paths
RP/0/0/CPU0:IOX-1#

But this doesn't work, as you can see the 100.0.0.1 prefix is just dropped from the BGP table.

Is there some RPL magic that's currently supported that could enable this to work?

[Richard Gallagher]

To answer half of my own question I presume it's dropping the prefix as the nested apply is not matching and therefore without a pass we remove the route. 

So aside from EEM/TCL any other options?

[xthuijs · Accepted solution]

yeah your try was very nice, but this won't work either: an RPL is really like a run to completion on its own prefix while not looking at other prefixes. you can mess around with variables in the policy that we mark a variable to save/store an info, and that would work for your scenario, but ONLY if the "tripping" prefix to set the variable is received first.

we would not rewalk the list back to touch other prefixes who were handled before the "trip" was set. only prefixes after this trip will get the application.

a set will provide a pass. in your example if the prefix is not getting the local pref, the pass is not there and therefore dropped.

it is an EEM approach or the rib-has-route for neighbor attachpoint that we really need.

xander