VMware HCX: L2 Extension Network Cutover Scenarios

VMware Hybrid Cloud eXtension (HCX) Layer 2 Network Extension cutover post covered the benefits, process and unextend procedure by moving the network to cloud. In this blog post we will discuss few other scenarios related to network extension and a small animation for each scenario.

Scenario 1 Unextend without cutting over the network

While unextending, the option to retain the network on-prem (or source) is typically used during testing. The network (default gateway) is not migrated to cloud in this scenario. This option may also be useful during some DR testing scenarios.

It is simple to execute this option and is in fact the default behavior – while unextending the network, just don’t select the checkbox  ‘Connect cloud network to cloud edge gateway’. This action does not cause interruption to the on-prem network connectivity as everything remains as-is before the extension.

But what happens to the cloud side? The backing NSX network and VMs (if any left) are retained in the cloud but they lose connectivity as the extension is now removed. Typically in this scenario, there won’t be any VMs left in the cloud as the VMs may have been moved back to on-prem after the testing. If required the backing NSX segments in the cloud can be removed by the user manually if there is no intention to re-use or re-extend the network. Visual animation of all these might help make things clearer, check out the video.

The NSX-T segments cannot be removed if VMs are attached to it –

So this behavior of leaving behind the network disconnected is convenient during temporary un-stretchings. This way the VMs don’t have to be moved every time a network is unextended.

Scenario 2 Re-extend the network from on-prem while the backing network is available disconnected in the cloud

Consider the situation where a network was unextended keeping the default gateway on-prem (as in Scenario 1). Now the requirement is to extend the same network again. This could be for any number of reasons, say the testing was successful and now the production workloads are to be moved,

The network can be re-extended just like before and if an exact match is found by the HCX extension workflow for default gateway/prefix length (e.g. 192.168.49.1/24), the matching network already on the cloud NSX-T Tier-1 is re-used for the extension i.e. a new backing L2E network will NOT be created. Other behaviors are same as a fresh extension.

Exercise caution while extending or unextending networks and understand the default behavior of each action. Test using test networks/workloads to understand these before proceeding with production components.

Scenario 3 Re-extend the network from on-prem after cutover when the network is active in the cloud

This is a rare scenario where the default gateway is already active on the cloud and the requirement is to move the network back to on-prem (i.e. the pre-migration state). This might be used to move the network from Cloud back to On-prem.

The steps for extension are the same, but this time the network has to be made available on-prem before extending. As we saw earlier, if an exact match is found by the HCX extension workflow for default gateway/prefix length, matching network already on the cloud is re-used for the extension i.e. a new backing L2E network will not be created. Check the below diagrams for reference.

• 

• 

• 

Since the extended network 192.168.49.1/24 is matching with the existing cloud segment ‘L2E_pg-app-vlan49-49-10988ca3’, it is being re-used. Note that the workflow actually disconnects the cloud side, meaning the default gateway should be made available in the on-prem (it probably can be connected to the network and advertised from on-prem, once the extension workflow completes).

Please leave a comment if you have more scenarios to discuss. Thanks for reading.