Allow transitive network flow between peered VNET's
if we assume Three networks.
VNET1 <> VNET2 <>VNET3
<> denotes vnet peering
A machine on VNET1 cannot directly see a machine in VNET3
We would like this facility to enable us to build a network design without having to use vitual network appliances to make this happen.
Transitive network flow between peered vnets is on our roadmap but we have no dates to share at this time.
Was this ever addressed? Its been two years almost since this sat on your roadmap
Nick Childs commented
This would definitely be a very nice feature to have; any and all workarounds create a bit of an unnecessary mess.
Moritz Schürmann commented
It's already possible:
1. Create a gatewaysubnet in the VNET2 (Hub) with a basic vpn in it - no connection needed
2. Enable "Gateway Transit" in the peering from VNET2 to VNET1 / VNET2 to VNET3
3. Enable "Use Remote Gateways"
4. Create custom routes for VNET3 in VNET1 / VNET1 in VNET3 with next hop Virtual Gateway
Easily the biggest VNet routing gap we face. Our workarounds have created a spiderweb that is hard to visualize and maintain.
Catalin Magher commented
REconsider this please and give us a Status Update - would be very benefic for some architectures!!
Any update regarding transitive network flow between peered VNETs? This would enable mixing Hub/Spoke with Mesh network topology. Many thanks!
Eric Tacik commented
Transitive routing enables multiple use cases, including:
- “Choke” point for all routing across enterprise – we can use central hub or hubs to see all “east-west” traffic by using features like NSG flow logs. Without transitive routing, this information is distributed and hard to correlate
- Flexible VNet access - The network can now emulate how I have network design working on-premises. If there is an unanticipated change in network design, I currently need to add yet another VNet peer – this becomes unwieldy over time
- Scalability – when networks get too big I need to refactor and grow them. Without transit routing, I need to use third party products to provide transit routing overlay – not very efficient. For very large customers the overlay does not provide enough bandwidth to scale up/out. That makes Azure not a viable solutions unfortunately.
I have run into all of these problems with previous customers. When AWS announced Transit Gateway last year, it was a big deal and every cloud infrastructure team started using it. That is a killer service, and something that Azure needs to offer as well.
This would solve several problems with some larger customers, please make this a priority.
This would be highly beneficial. Would love to see an update on timeline. It's been 1 year and 3 months since the admin said "Transitive network flow between peered vnets is on our roadmap but we have no dates to share at this time.". Any timeline to share here in the future on 3/19/2019?
Hello Microsft, May possible to have an update ? Thanks.
Really need this, any update?
Amudha Palani commented
any update on this?
Any updates on this?