Azure VMware SolutionHCX

HCX L2 Network Extensions, L3 Gateway Cutover and MON: What You Need to Know Before You Start

HCX Network Extension lets you stretch your on-premises L2 networks directly into Azure VMware Solution. No re-IP. No downtime. But it comes with a set of constraints that will catch you out if you go in blind.

Cloud Stack

Mar 23, 2026 · 8 min read

HCX L2 Network Extensions, L3 Gateway Cutover and MON: What You Need to Know Before You Start

What Is HCX Network Extension?

VMware HCX Network Extension (NE) lets you stretch L2 networks from on-premises into AVS. VMs can be migrated without changing their IP addresses, which removes one of the biggest friction points in any large-scale migration project. Phased cutovers become far more manageable when you're not re-IPing hundreds of machines.

Think of a Network Extension like a VPN tunnel between two locations, but instead of just providing IP reachability between sites, it actually stretches the Layer 2 network segment itself across the wire. With a standard VPN, your on-premises network and your cloud network are separate subnets that route to each other. With HCX NE, the on-premises network and the AVS network are the same subnet, shared across both locations. A VM on-premises and a VM in AVS can sit on the same /24, use the same default gateway, and communicate as if they were plugged into the same switch. The only difference is one of them is running in Azure.

This is what makes zero-downtime, zero-re-IP migrations possible. You move the VM, it keeps its IP address, and nothing upstream needs to change. The network follows the workload.

That said, HCX NE is not a set-and-forget feature. There are constraints, sequencing requirements, and routing behaviours that will cause real problems if you're not prepared for them.

HCX Service Mesh architecture showing on-premises vSphere environment connected to Azure VMware Solution via HCX appliances and Layer 2 Network Extension over ExpressRoute

HCX Service Mesh — on-premises to AVS via Layer 2 Network Extension · Source: Microsoft · click to zoom

⚠️ Gotchas to Watch Out For

🔌

HCX NE only works with vSphere Distributed Switch port groups

Standard Switch (vSS) port groups are not supported. Neither are untagged Distributed Port Groups. If your environment hasn't moved to vDS yet, that needs to happen before you can extend any networks.

🐛

Cisco Nexus 1000v will cause you problems

If your on-premises environment still uses Nexus 1000v, don't extend networks backed by it. These virtual switches are known to be problematic with HCX NE. Check your environment before you start.

🔢

One NE appliance each side per vDS, two with HA

HCX deploys one Network Extension appliance each side per vDS you extend. If you enable High Availability, which you should, it deploys two appliances per vDS on each side. Factor this into your resource planning.

⏰

Enable HA before you extend any networks

This is probably the most operationally painful gotcha on this list. HCX NE HA must be configured before you extend networks or migrate any VMs. If you skip it and come back later, you'll need to unextend every network, enable HA, and re-extend them all. Always enable HA when building your service mesh. Don't leave it as a day-two task.

🌐

Don't extend the same network from multiple vCenters

If a VLAN spans multiple vCenters, only extend it from one of them. Extending the same network from more than one vCenter into the same AVS router creates conflicting paths and risks causing an outage. Pick one source and stick with it.

📦

Match your NE MTU to your underlying network infrastructure

Ensure your Network Extension MTU matches that of the underlying network infrastructure. Typically this will be 1500 when using the recommended method of an ExpressRoute circuit. A mismatch here can cause subtle performance issues and packet fragmentation that are frustrating to diagnose after the fact.

🔧

TCP Flow Conditioning helps, but it's not a silver bullet

HCX TCP Flow Conditioning is extremely helpful. It applies TCP MSS Clamping to the inner TCP traffic of the Network Extension, ensuring packets fit within the established tunnel MTU. But it won't help if your underlay network is misconfigured, and it does nothing for UDP traffic. Don't rely on it as a fix for a poorly configured network. Sort the underlay first.

🧪

Test a full network cutover before going near production

Before moving any production workloads, build a small test network, extend it, migrate a VM into AVS, then unextend it and let the gateway cut over into AVS. This is the exact sequence that will happen when you retire the on-premises environment and it will surface routing issues you didn't know you had.

When a network is unextended, NSX-T advertises the prefix via BGP to your connected hub. Because that prefix originally came from on-premises, your upstream routing infrastructure may have BGP filters that only accept it from on-prem, not from AVS. The AVS-originated route gets dropped, and you lose connectivity. Finding this in a test window is painful. Finding it during a production cutover is worse. Test early.

HCX NE High Availability, How It Actually Works

HCX NE provides two layers of resiliency, and it's worth understanding both before you rely on them.

Application Path Resiliency

HCX creates multiple tunnel flows between Network Extension appliances for both Interconnect and Network Extension traffic. Traffic automatically takes the optimal path and shifts dynamically if conditions change between sites.

Network Extension Appliance HA

With HA enabled, HCX deploys four Network Extension appliances per vDS — two at the source site and two at the destination. These form a unified HA group. One pair becomes Active, the other sits as Standby. If the Active pair fails, the Standby pair immediately takes over. No manual intervention required.

Worth noting: This is why enabling HA upfront matters so much. You don't want to be unextending networks to retrofit it after the fact.

HCX MON, What It Is and Why You Should Enable It

MON stands for Mobility Optimized Networking, and it's an optional HCX Enterprise feature that solves a specific problem: the trombone effect.

Here's the issue. With standard HCX NE, migrated VMs still rely on their on-premises default gateway even after they've moved to AVS. That means a VM running in AVS trying to talk to another VM also running in AVS may route all the way back to on-prem and back again. More hops, more latency, worse application performance.

MON fixes this by enabling selective cloud-side routing. Migrated VMs get a local gateway inside AVS, and traffic that should stay in AVS stays in AVS.

Without MON

VM1 in AVS routes through the on-prem gateway and back to AVS to reach VM2. Every hop adds latency.

With MON

VM1 in AVS routes directly to VM2 in AVS. Local routing, lower latency, no trombone.

Under the hood, MON uses Policy-Based Routing inside NSX-T to make these decisions. Policy routes determine whether traffic should stay within AVS via the T1 gateway, head back on-prem through the HCX NE tunnel, or exit through the T0 gateway for Azure or internet access. MON handles path selection automatically and prevents the asymmetric routing issues that would otherwise follow you into production.

To enable MON, make sure HCX Enterprise is activated in your AVS environment.

MON Policy Routes and Avoiding Asymmetric Traffic

MON is powerful, but it introduces routing decisions that need to be planned carefully. Get this wrong and you'll end up with asymmetric traffic flows, confused stateful firewalls, and connectivity problems that are painful to diagnose.

The key rule: only enable MON policy routes if your network infrastructure has been designed to handle them.

When MON is enabled and the VM gateway has been migrated to the cloud side, NSX-T advertises a /32 host route for each MON-enabled VM back to your connected hub via BGP. This is what allows other VMs in Azure and on-premises to reach the migrated VM directly without going through the Network Extension tunnel. The diagram below shows how the VM gateway migration eliminates the trombone effect for VM-to-VM traffic on stretched segments.

Diagram showing the optimization for VM to VM L2 communication when using stretched networks

VM to VM L2 optimisation with MON enabled · Source: Microsoft Learn · click to zoom

By default, all RFC 1918 addresses are included in the MON policy route definition. This means all private IP egress traffic gets tunnelled back over the Network Extension path, while internet and public traffic routes out through the T0 gateway. That sounds sensible on the surface, but it can create problems.

Here's the scenario to watch out for. A VM in Azure learns the path to an AVS VM on a MON-enabled segment. Return traffic is sent back to the T0 gateway as expected. But if the return subnet matches an RFC 1918 policy route, that traffic gets forced over the Network Extension instead, and egresses back to Azure via ExpressRoute on the on-premises side. Stateful firewalls in the path see asymmetric flows and things start breaking.

The three policy route configurations and what they do:

Default RFC 1918 policy routes — all private IP egress traffic is tunnelled over the Network Extension. Internet and public traffic routes through the T0 gateway. Use with caution and only if your infrastructure accounts for the asymmetric routing implications.

Default RFC 1918 policy routes · Source: Microsoft Learn · click to zoom

RFC 1918 egress traffic flow with default policy routes · Source: Microsoft Learn · click to zoom

No policy routes defined — all egress traffic routes through the T0 gateway. This is the safest option if you haven't specifically designed your network to handle MON policy routing. When in doubt, start here.

No policy routes — all traffic via T0 · Source: Microsoft Learn · click to zoom

Default route (0.0.0.0/0) — all egress traffic, including internet, gets tunnelled over the Network Extension path. Only use this if you specifically want all traffic going back on-premises first.

0.0.0.0/0 policy route — all traffic tunnelled over Network Extension · Source: Microsoft Learn · click to zoom

Worth noting: Policy routes are only evaluated if the VM gateway has been migrated to the cloud side. If the gateway is still on-premises, policy routes have no effect. In general, the Microsoft recommendation is to remove all default policy routes and only add them back once your infrastructure has been specifically configured to prevent asymmetric traffic.

Wrapping Up

If you're planning to use HCX for a phased migration, getting your head around NE and MON early will save you a lot of pain. The technology is solid but the sequencing, HA configuration, and BGP routing behaviour are exactly the kind of things that don't show up until you're in the middle of a cutover window.

Test everything. Enable HA first. And run that network cutover dry-run before you commit to production.

👉

Coming next: HCX migration types — RAV, Bulk, vMotion, and when to use each one.

Azure VMware SolutionHCX

HCX Migration Types: RAV, Bulk, vMotion, Cold and OSAM

Apr 2, 2026 · 10 min read

Azure VMware Solution: Gen 1 vs Gen 2 - What's Actually Changed?

Mar 19, 2026 · 7 min read