[j-nsp] Merging routes from VRF to inet.0

[Alexander Arseniev]

There is a way but You may not like it :-)
Basically, You need to announce same route twice - as "inet-vpn unicast" 
and as "inet unicast" from originating PE.
On receiving PE, you have to do 2 things:
1/ adjust nexthop resolution
set routing-options resolution rib inet.0 resolution-ribs  [ 
L3VPNname.inet.0 inet.0 ]
2/ in BGP import policy, manipulate nexthop for "inet unicast" route in 
such a way that it uniquely resolves via
L3VPNname.inet.0, maybe via another MP-BGP route from originating PE.
Also make sure all ordinary inet unicast routes in inet.0 on receiving 
PE do not resolve via L3VPNname.inet.0.
Hope this makes sense
Thanks
Alex

On 16/01/2015 20:15, Tobias Heister wrote:
> Hi,
>
> Am 16.01.2015 um 20:49 schrieb Tom Eichhorn:
>> I have found an answer why my rib-groups and everything is not working:
>> All fiddling with RIB-groups is for PE-CE, and not for PE-PE.
>> As the primary route is in bgp.l3vpn.0, I cannot leak from 
>> vrf.inet.0, which is the secondary table for the route.
>>
>> (If somebody asks why I can't do the leaking on the CE-PE router - 
>> there is non. The other side of the
>> VPN is a contrail controller, which only speaks inet-vpn.).
>>
>> I also discussed with this my SE, and they didn't had a quick answer 
>> but have to discuss internally,
>> but I hope that our community here maybe also has an idea howto leak 
>> routes received via inet-vpn to inet.0...
>
> From my research there is no way to leak routes that were learned via 
> inet-vpn to inet.0 besides running routing protocols between instances.
>
> I did a dirty hack the other day where i needed to move routes from 
> inet.0 to vrf.inet.0 and leaking was no option (do not ask) It is the 
> other way around from your setup but the concept should be similar.
>
> I configured a static route (e.g. something from the documentation 
> prefix or other "bogus" prefix) with next-table statement (in your 
> case in inet.0 with next-table vrf.inet.0), setup BGP via lt- between 
> the instances and used an import policy to change the next-hop to 
> point to the prefix of the static route configured earlier. The BGP 
> needs to be multihop or to have the accept-remote-nexthop knob 
> configured because the next-hop is "remote". You will need to be able 
> to match the routes you want to leak/export via policy to do so.
>
> This way forwarding is done directly to/from inet.0 (without) using 
> the lt- interface and all the bandwidth constraints it suffers. Also 
> 1G tunneling is basically always free (on MX) even with DPCs so you 
> will not loose any interfaces when activating tunnels.
>
> Maybe you can derive something from that for your setup. This will not 
> work if there is already a static route with next table from 
> vrf.inet.0 to inet.0 because the config parser will deny it for 
> possible loops. But maybe you can use rib-groups or other leaking 
> methods for that direction.
>