In part 1 of this series of post we’ve looked on the basics of HCX, and we’ve discussed the HCX installation process. In part 2 will have a closer look at the network extension capability of HCX.

The network extension service of HCX provides a 4-6 Gbps layer 2 extension capability. This capability is provided through the HCX Network Extension Virtual Appliance, and permits virtual machines to keep their IP & MAC address during a virtual machine migration. We will look at the network extension service within the context of an on-premises datacenter in combination with VMware Cloud on AWS.

It’s possible to extend both VLAN and NSX overlay networks. With Network Extension, the default gateway for extended networks exists at the origin site. We can use Proximity Routing in some scenario’s, but this is currently not supported with VMConAWS. Read more about Proximity Routing at the end of the article.

HCX Network Extension Virtual Appliance

You will need a HCX Network Extension Virtual Appliance (HCX-NE) at both the on-premises site as well as in VMConAWS. The on-premises virtual appliance will be deployed automatically during the Create a Service Mesh process in HCX, at the VMConAWS side the HCX-NE appliance is managed by VMware. You will see both virtual appliances in the inventory view of the vCenter Servers. The VMConAWS HCX-NE appliance is deployed to the Mgmt-ResourcePool at the VMC side.

Creating an extended network

Creating an L2 extended network is actually the most simple task in the world! You will need an on-premises L2 segment that you want to extend to VMConAWS. Extending the network consists of three simple steps:

Open the HCX option in the vSphere client menu; Select the Network Extension service; Choose the Extend Network option.

…and that’s it!

So, choose the Network Extension option and select Extend network:

Specify the network properties and select the Edge you want to connect to. For VMConAWS deployment this is the CGW (=Compute GateWay):

The configured gateway is the IP address of the existing on-premises router.

Click Extend and you’re all set. The destination network is automatically created and L2 stretching is enabled.

In this example the “L2E..” network name is generated by HCX. Notice that these screenshots are taken from Hands On Lab HOL-2081-01-HBD, that you can take for free through labs.hol.vmware.com. Exactly the same steps apply to VMConAWS, with the difference that an NSX-T segment is created in VMConAWS.

As part of this process, the HCX-NE appliance at the source site is connected to the viktorious01 network, the HCX-NE appliance at the destination site is connected to the L2E_VM-RegionA01-vDS-COM-0-ec20aaf1 network.

For the communication between the sites the HCX Network Extension WAN link is leveraged, which is a IKEv2/Certificate based link between your sites. Notice that the source site will initiate this connection to the destination site. Click the diagram on the right to get some additional details on this link.

At ports.vmware.com you will find all the requirements ports/connections that HCX needs to operate:

Testing HCX Network Extension

So let’s give the Network Extension service a shot! We’re going to do a migration of a virtual machine from a datacenter in Austin to VMConAWS in London:

We will be using the HCX migration service, which will be topic to discuss in a future post. We’re going to migrate (HCX vMotion + storage relocation) a VM with IP 172.80.2.156 that is connected to Stretch-VLAN in Austin, to VMConAWS in London. The stretched network in London is called XYZ. The settings for the migration are detailed in the next diagram:

Notice that we’re using the migrate option of HCX and not the default migrate option in vSphere. The relocation/migration of the VM make take a while, depending on the available bandwidth, size of the virtual disk(s) and amount of memory in use. A change in the RTT tells us that the VM is running at “the other side”:

As you can see the RTT increases from 87ms to 174ms. This is because my desktop is at the VMConAWS site in London, and the routing is still taking place in Austin (we have some hair pinning here). The VM is automatically connected to the stretched network segment in VMConAWS.

HCX with Proximity Routing

HCX comes with Proximity Routing when you’re using NSX for vSphere (NSX-V).

Proximity Routing builds on VMware HCX Network Extension by integrating with NSX Routers at the VMware HCX Cloud destination site. By dynamically injecting Virtual Machine routes into the existing routed topology, proximity routed network traffic always traverses a symmetric path to the network target.

So with Proximity Routing the routing for the stretched L2 network segment is managed by the local router at each site by injecting VM routes into the dynamic routing protocol (OSPF, BGP – this only applies to the target/cloud side of course). The result is that you will have optimised routes, and no more hair pinning at your primary site. At this point Proximity Routing is not supported with VMConAWS and only available if you’re running NSX for vSphere. More details on HCX with Proximity Routing is available in the documentation.

This concludes part 2 of my series on HCX, stay tuned for part 3 that will focus on the HCX Migration service.