Loading...

Virtual Wan Traffic Flow Patterns

Virtual Wan Traffic Flow Patterns

Virtual Wan Traffic Flow Scenarios

 

This guide offers an exploration of the essential elements related to vWAN traffic flows, including their significance in shaping flow topology patterns. At the heart of the vWAN branch architecture lie pivotal components such as VPN, SD-WAN, and ExpressRoute. Within the vHub ecosystem, the routing instances hold the crucial role in managing traffic flows, employing BGP for communication. These routing instances, concealed from the end user within the vHub, serve as the linchpin of the vWAN system. The routing instances bear the responsibility of intercepting and directing traffic flows, ensuring the smooth transmission of data packets. If packet flow inspection is also required, these can be aided by an Azure Firewall (AzFW) or Network Virtual Appliance (NVA) inside the vHub. The moment an NVA or AzFW is incorporated into the vHub, they gain control over the data plane packet interception. To enable this inspection, Routing Intent must be enabled on multi-vhub scenarios, or Private/Internet Traffic must be enabled via Firewall policy if an Azure Firewall is deployed within the vHub(s). The subsequent diagrams offer a pictorial depiction of the various flow patterns observed for single and multiple hubs within the vWAN infrastructure. The intent of this article is to provide a more detailed depiction of flow patterns than currently available in the Azure public documents, vWAN Flow PatternsUnderstanding the flows and components involved in vWAN pricing is also essential, and this can help explain how vWAN pricing works. For details on vWAN pricing, please refer to the vWAN Pricing Page

 

Single vWAN Hub

 

Single Region.png

Traffic Flows  Traffic Flow Paths
Flow A Spoke VM-->Routing Instances-->Spoke VM 
Flow B Spoke VM-->vHub VPN-->Branch VPN Concentrator
Flow C Spoke VM-->MSEE IP-->Branch Customer Edge (CE) (Egress flows for ExR bypass the ExR GW!)
Flow D Branch Customer Edge (CE)-->MSEE IP-->ExpressRoute GW-->Spoke VM
Flow E Branch Customer Edge (CE)-->MSEE IP-->ExpressRoute GW-->vHub VPN Gateway-->Branch VPN Concentrator
Flow F Branch VPN Concentrator-->vHub VPN--->MSEE IP-->Branch Customer Edge (CE) (Egress flows for ExR bypass the ExR GW!)

 

Quick Take-Aways

 

In the aforementioned flow paths, it's pertinent to note that the Virtual Private Network (VPN) can be substituted with a Software-Defined Wide Area Network (SD-WAN) tunnels to yield identical results in the diagram above. If either an Azure Firewall or Network Virtual Appliance (NVA) is deployed within the virtual hub (vHub), they will intercept packets in lieu of the route service's Virtual IP (VIP), granted that Routing Intent is activated, or Private/Internet security via Azure Firewall policy on a single vHub!

During operations within a single vHub, it's important to realize that flows to and from branches, whether via IPSEC, SD-WAN, or ExpressRoute, do not traverse the route service instances. Instead, this pattern is only observed in Spoke to Spoke flows, which contributes towards the vHub infrastructure limit, currently capped at 50Gbps per vHub, For additional details, please refer to the linked resource. Lastly, it should be mentioned that Branch to Branch flows also bypass the route service instances.

 

Multiple vWAN Hubs

 

Multi-Hub.png

Traffic Flows  Traffic Flow Paths
Flow A Spoke VM-->Routing Instances-->Remote Routing Instances-->Remote Spoke VM
Flow B Spoke VM-->Routing Instances--->Remote vhub VPN-->Remote Branch VPN Concentrator
Flow C Spoke VM-->Routing Instances-->Remote MSEE IP--->Remote Branch Customer Edge (CE) (Egress flows for ExR bypass the ExR GW!)
Flow D Branch Customer Edge (CE)-->MSEE IP-->ExpressRoute GW-->Remote Routing Instances-->Remote Spoke VM
Flow E Branch Customer Edge (CE)-->MSEE IP-->ExpressRoute GW-->Remote vHub VPN GW-->Remote Branch VPN Concentrator
Flow F Branch VPN Concentrator-->Remote MSEE IP-->Remote Branch Customer Edge (CE) (Egress flows for ExR bypass the ExR GW!)

 

Quick Take-Aways

The same principles apply to multiple vHubs in terms of SD-WAN tunnels and Azure Firewall/NVA behavior as they do a single vHub.

In the flow patterns for multiple vHubs, we note that Spoke-to-Spoke communication across hubs invariably involves the routing instances. Traffic moving from Spoke to Branch and vice versa also traverses a single set of routing instances. However, Branch-to-Branch traffic does not pass through the routing instances, just like single vHub behavior.

 

Note:

It's important to acknowledge that Azure Virtual WAN does not natively provide transit for ExpressRoute-to-ExpressRoute flows. To facilitate this, Global Reach is required. For Global Reach details, please refer to the linked resource. Alternatively, an Azure Firewall or NVA can be deployed in each vHub, combined with activation of routing intent and engagement with Microsoft Support. Information on Routing Intent can be found here to facilitate transit between ExR CircuitsUnder this configuration, we effectively push down RFC1918 prefixes to each ExpressRoute branch, thereby providing a supernet of transit connectivity.

 

Conclusion

I hoped this guide helped shed more light on the comprehension of packet flow dynamics within the services employed in vWAN. Armed with this understanding, users are enabled to make informed decisions regarding the infrastructure units, in terms of (Gbps), that should be allocated to each respective vHub, and also the size of their branch gateways (VPN/ExpressRoute) and SD-WAN devices. 

Published on:

Learn more
Azure Networking Blog articles
Azure Networking Blog articles

Azure Networking Blog articles

Share post:

Related posts

Power Automate – Integrate Copilot in Process Mining analysis

We are announcing the Integrate Copilot in Process Mining analysis feature for Power Automate. This feature enables you to create views and dr...

2 days ago

How to capture user questions asked to Copilot in Dynamics 365 CRM using Power Automate

As Microsoft’s Copilot becomes an integral part of the Dynamics 365 CRM ecosystem, understanding how users interact with it has become essenti...

3 days ago

Use SDK for .NET to bypass Dataverse power automate flows

In this blog post, we’ll explore how to use the SDK for .NET (via Plug-ins or Console Applications) to bypass Power Automate flows with ...

3 days ago

Microsoft Power Automate – Flow run history is missing from the Automation Center

Reports notified us that as of April 1, 2025, at 12:00 AM UTC, some flow run history may be missing from the Automation Center. How does this ...

3 days ago

How to Fix Missing Line Breaks in Power Automate Desktop for RPA, Email, and Web Automation

If you’ve ever used Power Automate Desktop (PAD) for robotic process automation (RPA), you might have encountered missing line breaks in your ...

3 days ago

Set ‘Regarding’ to any (eligible) table in single update action in Power Automate

A helpful little tip for working with the ‘Regarding’ column in Dataverse Activities & Notes with Power Automate. Setting the value of the ‘...

4 days ago

Power Automate – Create and edit expressions with Copilot

We are announcing the Create and edit expressions feature for Power Automate. This feature allows you to create, edit, and fix your Power Auto...

4 days ago

Power Automate – Upcoming changes to flow sharing experience

Starting in June 2025, we are updating the prerequisites for sharing cloud flows. With this update, users must be members of the environment w...

10 days ago
Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy