Recently I have been having some great conversations around HCX and the mobility functionality within, allowing the migration of workloads from either legacy on-prem environments to new environments on-prem such as VCF deployment or out to a VMware Cloud platform such as VMware Cloud on AWS.

Recently, a question came up around networking, and the network extension capability of HCX. Previous work completed has mainly been between two sites, all starting with a “legacy” site, migrating workloads into new environments whether that been VCF or Cloud. This required network extensions to facilitate the migration path, which is achievable with the Network Extension function of HCX. This particular case requires the extension of a network from a legacy environment into two destination environments.

Okay, extending a network from one vSphere environment into two others, that set of two different tracks in my mind. First being “let’s tap up the documentation, is this possible?”. Well turns out, yes, it is possible, as detailed here “HCX supports one Network Extension to a maximum of 3 distinct destinations or routers.” The second track, time to lab it! It shouldn’t be too complicated using the nested and remote HCX lab’s that I have kicking about.

At a very high-level the below image shows the concept, extending VLAN-10 from VCSA-1 to VCSA-2 and VCSA-3.

I set about creating this in the lab, first thing I created a new segment within NSX to use for the extension test – ironic really given that I have just been clearing out old segments ;-), I’ll remember to delete this segment once I have completed the testing!

Time to power up the HCX labs (it’s been a while) make sure that they all come up cleanly, fortunately they did. I then confirmed that the site pairings were all in place.

For the sake of this test, I actually chose to create new service mesh’s between the sites as I was only interested in testing the network extensibility so no requirement for hybrid interconnect functions.

Confirming the topology deployment ready for the deployment into the nested HCX environment.

I then completed the same process for the remote HCX lab and created a service mesh with only network extension services enabled. Two service mesh’s deployed and ready for use.

Next step was to extend the NSX segment into each of the HCX Cloud destinations. After stepping through the network extension wizard the segment was extended to both HCX Cloud destinations.

Okay, that’s the network extension in place between the “legacy” site and two different HCX Cloud destinations, now time to test it works. In theory, I should be able to put a VM on the segment/extended segment in each location and they will be able to communicate on the same layer 2 broadcast domain – well that’s what the VMs will believe anyway :). I powered up the below components to validate the connectivity.


Using VM-3 as a GUI, I set about confirming the connectivity using ICMP. The below screenshot is a little busy but it shows a number of things.

  • The bottom two command prompt windows show a ping running from (VM-3) to (VM-1) and (VM-2) with success.
  • Top left there are two SSH sessions connected to (VM-1) this shows a ping operation going to (VM-3) and (VM-2).
  • Top right there are two SSH sessions connected to (VM-2) this shows a ping operation going to (VM-3) and (VM-1).

All tests passed, they are all in separate vSphere environments and even better one is actually in a different physical location with HCX NE Tunnels established over the internet/VPN.

I carried out a number of other tests as well, for example VM-3 is located at a different physical location as this is connected to a segment that is stretched from VCSA-1 when browsing the internet for example VM-3’s egress point is out of the internet breakout in the same location as VM-1.

All in a great test, good to see this working and I’m looking forward to seeing how the conversations progress around multi site networking extensions via HCX.

One Comment

  1. Pingback: VMware HCX Daisy-Chain "L" Network Extension - BTTECH Blog

Leave a Comment

Your email address will not be published. Required fields are marked *