[j-nsp] Merging routes from VRF to inet.0
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:
> 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