[j-nsp] advertise-from-main-vpn-tables and Hub&Spoke VRFs

[Tobias Heister]

Hi,

On 29.05.2018 11:15, Sebastian Wiesinger wrote:
> So, I'm still stuck on this.
> 
> When using 'advertise-from-main-vpn-tables' Hub&Spoke VRFs with a
> downstream hub[1] break.
> 
> In my mind the problem is that the downstream hub instance does not
> advertise the hub routes to the bgp.l3vpn.0 table. Route
> redistribution should work like this:
> 
> a) without advertise-from-main-vpn-tables
> 
> [Hub instance] -> [Downstream hub instance] -> MP-BGP neighbors
> 
> This *works*
> 
> 
> 
> b) with advertise-from-main-vpn-tables
> 
> [Hub instance] -> [Downstream hub instance] -XXXX-> [bgp.l3vpn.0] -> MP-BGP neighbors
> 
> And there it breaks. Routes from the hub instance that get import into
> the downstream hub instance are not exported to the bgp.l3vpn.0 table
> and thus do not get advertised to other MP-BGP neighbors.
> 
> I tried various options with auto-export and explicit rib-groups but I
> can't find any working scenario.
> 
> If anyone has a working config for this please let me know.

I had similiar problems a while ago when we tried to leak routes from inet.0 into a VPN Instance. This works fine on a router which is not a RR (so no bgp.l3vpn.0). As soon as you add RR to that scenario it will no longer announce the leaked routes via L3VPN and/or leak/export them to bgp.l3vpn.0

The reason for it not working is that routes are only allowed to be "leaked" once in Junos architecture. In Scenario b they would need to be exported/leaked twice before being send out to L3VPN peers.

Our workaround back in the day was a BGP Session between inet.0 and vpn.inet.0 via lt- interface + BGP Policy to rewrite next-hop directly to inet.0. This way the routes are exchanged via the lt- but forwarding is done directly. Not sure if that is feasible/applicable for your scenario.

-- 
Kind Regards
Tobias Heister