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

Alexander Arseniev arseniev at btinternet.com
Sat Jan 17 05:16:51 EST 2015

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

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.

More information about the juniper-nsp mailing list