VMware SD-WAN in Azure vWAN

Bandwith usage is increasing exponentially, especially for companies moving fast to cloud services. At Michelin we have struggled to optimize network traffic routing as our usage of cloud services has increased.

Context

As many Microsoft Azure clients, we dispatch our cloud workloads to several regions to improve performance and redundancy, and access these cloud regions through on-premise regional network hubs then Express Route circuits.

Even if it helps enforcing security filtering by limiting connectivity paths, it constrains internal cloud access by:

• preventing any latency gain of deploying new Cloud regions closest to developers and users
• increasing Express Route and globally on-premise hubs bandwith usage

The combination of Azure virtual WAN and VMware SD-WAN (or any other SD-WAN solution) that we already deployed independently has been tested together to brings more flexibility thus improving Cloud connectivity.

What is VMware SD-WAN ?

VMware SD-WAN is a Software Defined WAN solution allowing WAN link aggregation (MPLS, FTTx, Radio, 4G, 5G) and selecting the best path based on business policies and link quality.

To make this happen, Edge appliances (hardware-based or virtual) called SD-WAN Edge create an overlay based on secured tunnels (DMPO for Dynamic Multipath Optimization) to build a mesh network between every hub and branch sites.

All of these appliances are provisioned and managed through one orchestrator (SaaS platform in our case).

What is Azure vWAN ?

Azure vWAN is a managed network service, grouping scalable network services from Azure into hubs:

• Virtual router: gateway including BGP capability
• Express Route gateways: endpoint of Express Route connections
• VPN S2S gateways: secured tunnel for site-to-site connectivity
• VPN P2S gateways: secured tunnel for user-to-site connectivity
• Azure Firewall: native managed firewall

It also allows integration of NVA (Network Virtual Appliances) like other Firewall solution and SD-WAN Edge.

But the key feature of virtual WAN is the ability to use the Azure backbone to mesh all active regions by deploying a vWAN hub in each of them.

VMware SD-WAN + Azure vWAN

By using these components together we can leverage Cloud connectivity from regional ...

...  to local breakout.

This design open new opportunities of workload decentralization to serve requirements like performance and Cyber law by deploying new regions faster at a lower cost.

Where should it be deployed

Many architecture patterns are exist to join Azure vWAN and SD-WAN Edge, including direct S2S VPN or S2S VPN through SD-WAN regional gateways.

We decided to deploy virtual SD-WAN Edges in vWAN hubs for the following reasons:

• keep Quality of Service embedded into DMPO from point to point
• benefit from a direct access to Cloud without any regional or additional WAN peering dependency

Build it

Considering that Azure virtual WAN and VMware SD-WAN are already deployed, let's focus on how to deploy SD-WAN Edges in vWAN hubs as NVA.

These appliances must be installed from Azure Marketplace in each vWAN hub as a pair of scalable VMware SD-WAN Edges, and rely automatically to a specified SD-WAN Orchestrator.

Two Edges are then created as a managed application into a managed resource group, including network interfaces into vWAN hub VNET.

These virtual SD-WAN Edges are managed like others with two specificities in our context:

• set as a Cluster (active/active) instead of High Availability
• use BGP instead of static routes

Route it

Having all of these components and connectivities creates multiple paths where priority must be defined.

A BGP peering is created between SD-WAN Edge and vWAN ASN to dynamically get routes from every vWAN hub. The next hop of these routes (192.168.100.0/24 in the next example) in the default hub routing table is VPNS2SGateway even for an NVA like the SD-WAN Edge.

The vWAN hub routing preference is set by default to Express Route. However, because routes announced from branches are smaller than ones announced from on-premise hubs, using alternative preferences like AS Path is not mandatory.

On the SD-WAN side things are quite similar, receiving routes from vWAN for each VNET when routes from Express Route are aggregated.

Branch sites can then access any Cloud region by using DMPO tunnels and keep Express Route as a fallback path.

Next steps

Some technical improvements will be studied before moving to production, such as:

• moved virtual SD-WAN Edges from Branch to Hub mode in order to get permanent tunnels between Azure regions and branch sites
• optimize routing to reach, from a branch site, any Azure region through the closest one

Following our multicloud strategy, the same kind of implementation could be deployed into Amazon Web Services using AWS Cloud WAN in the future.

The deployment of VMware SD-WAN in Azure vWAN is documented here