[j-nsp] advertise-from-main-vpn-tables and Hub&Spoke VRFs (was: KB20870 workaround creates problems with Hub and Spoke) downstream hubs?

[adamv0025 at netconsultings.com]

> Of Sebastian Wiesinger
> Sent: Tuesday, May 29, 2018 10:15 AM
> 
> * Olivier Benghozi <olivier.benghozi at wifirst.fr> [2018-02-15 10:33]:
> > Hi Sebastian,
> >
> > This is an old workaround by the way.
> 
> > Simpler workaround: use advertise-from-main-vpn-tables knob available
> > since 12.3 (required if you have NSR anyway):
> 
> 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.
> 
> Regards
> 
> Sebastian
> 
> [1]
> https://www.juniper.net/documentation/en_US/junos/topics/example/vp
> n-hub-spoke-topologies-one-interface.html
> --

Theirs is this split horizon rule in VPNs, 
If VPN-A leaks prefix X to VPN-B then VPN-B should not advertise this prefix
X to other PEs.
-because if you'd allow this to happen then VPN-A and VPN-B could
potentially both advertise prefix X -what would the receiving PEs think then
-did prefix X come from VPN-A or VPN-B? should I overwrite the RTs/label for
the prefix? As you can see it would create a mayhem at the receiving end.

Now, this Downstream HUB VRF feature with "no-vrf-advertise" allows you to
break this split-horizon rule if you pinky swear that VPN-A will never
advertise prefix X to any other PE.
This way then VPN-B would become the solely advertiser of prefix X to the
rest of the PEs, hence no loops are possible. 
-although the feature description seems to suggest that one can leak VPN-A's
prefix into multiple local PE VPNs -which potentially leads to the same
problem outlined above.
-so hopefully there are controls in Junos allowing you to import routes from
VPN-A only to one downstream hub VRF.

Introducing Cisco style VPNs into the mix,
My understanding is that the Junos feature "advertise-from-main-vpn-tables"
-is how VPN routing works in all Cisco platforms.
I haven't yet played with this feature so don't know if it allows VPNs to
exchange prefixes with one another cisco-style i.e. via the MP-BGP table on
a common PE, or whether the junos-style direct inter-VRF route leaking is
maintained and used instead.
However if the former is the case and VPNs are allowed to exchange routes
between each other (a free trade) via the MP-BGP table, then I can see how
the controls of Downstream HUB feature might get circumvented -as the MP-BGP
table would not enforce any such rules as to which VRF can or can not leak a
given prefix to other VRFs -other than based on matching RTs.

And I think that's the reason why the "Downstream HUB VRF" feature is
disabled in presence of "advertise-from-main-vpn-tables"  feature. 
Just thinking out loud.

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::