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

[Tobias Heister]

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.

-- 
Kind Regards
Tobias Heister