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.
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
