VMware Cloud on AWS SDDC 1.7: New NSX Features

The latest version of VMware Cloud on AWS SDDC (SDDC Version 1.7) was released recently and is being rolled out to customers. In this post, I’ll discuss the new NSX Networking and Security features.

Looking at the features released in VMware Cloud on AWS SDDC 1.7 in the below diagram, we can see the features can be grouped into three categories: Connectivity, Services, and Operations. Further below I go into more detail in each of these specific NSX features. For a complete list of all new features in VMware Cloud on AWS SDDC 1.7 in general, check out the release notes here.

Figure 1: VMware Cloud on AWS SDDC 1.7 NSX Features

Connectivity

1.) Direct Connect with VPN as Standby

This feature enables customers to utilize Direct Connect Private VIF with Route Based IPSEC VPN as Standby. To enable this, Direct Connect Private VIF can be configured with Route Based IPSEC VPN as Standby for non-ESXi and non-vMotion traffic. Prior to VMware Cloud on AWS SDDC 1.7, customers could not use VPN as standby for Direct Connect Private VIF.

Typically customers want to leverage the high bandwidth, low latency Direct Connect Private VIF connectivity for all traffic and use VPN as standby. However, prior to SDDC 1.7 and also default behavior in SDDC 1.7 is that when the same network is learned over both Direct Connect Private VIF and Route Based IPSEC VPN, routes learned over Route Based IPSEC VPN are preferred; this is because routes learned over Route Based IPSEC VPN are given a better administrative distance. This enables topologies such as the below where customers can configure Route Based IPSEC VPN over Direct Connect Private VIF providing for encryption over Direct Connect for Compute and Management Appliance traffic.

It’s important to note that whenever Direct Connect Private VIF is used, ESXi Management and vMotion traffic always goes over Direct Connect Private VIF; this is true even if route based IPSEC VPN is used in conjunction with Direct Connect Private VIF. ESXi Management traffic and vMotion traffic will always go over the high bandwidth, low latency Direct Connect Private VIF connection by design and cannot be rerouted over the Route Based IPSEC VPN connection.

Figure 2: VMware Cloud on AWS with Route Based IPSEC VPN over Direct Connect Private VIF

With VMware Cloud on AWS SDDC 1.7, under the Direct Connect tab as shown below, customers can enable the Use VPN as backup to Direct Connect option.

Figure 3: VPN as backup to Direct Connect Option Enabled

By enabling the Use VPN as backup to Direct Connect option, routes learned over Direct Connect Private VIF are given better administrative distance than routes learned over Route Based IPSEC VPN. This allows for the below topology where Route Based IPSEC VPN can be used as backup to Direct Connect Private VIF. Note, as mentioned prior, ESXi management and vMotion traffic will always go over the Direct Connect Private VIF connection, so this feature is really providing backup for management appliance traffic (Ex: vCenter) and compute/workload traffic which is typically what customers are most concerned about.

Figure 4: VPN being used as backup to Direct Connect for management appliance and compute traffic

It’s also important to note that when the Use VPN as backup to Direct Connect option is enabled, the traffic egressing the SDDC is preferring the Direct Connect Private VIF connection over the Route Based IPSEC VPN connection. However, on-prem, for traffic ingressing the SDDC, customers must also prefer the routes learned over Direct Connect Private VIF over the routes learned over the Route Based IPSEC VPN connection.

This is a great new feature for VMware Cloud on AWS SDDC, however, it’s important to understand when this feature should be used.

Below points are important to note:

Typically when customers have 2 x Direct Connect (DX) Private VIFs, they will be going to different Direct Connect (DX) circuits and customer already has redundancy/backup.
- Route Based IPSEC VPN as standby is not very useful in this scenario
If customer is trying to save cost and only has 1 x Direct Connect (DX) Private VIF, VPN as standby can be very useful for providing backup to Direct Connect Private VIF.
- Customer should note bandwidth used by workloads on Direct Connect Private VIF to ensure VPN bandwidth is sufficient

2.) ECMP for Route Based IPSEC VPN

Another great feature for connectivity provided in the 1.7 SDDC release is ECMP for Route Based IPSEC VPN. This feature is primarily targeted for use with AWS Transit Gateway (TGW). If you are not familiar with AWS TGW, please read my prior post, VMware Cloud on AWS with Transit Gateway Demo.

Prior to 1.7 SDDC, customers could use VPN attachments to VMware Cloud on AWS but had to deploy Route Based IPSEC VPN in Active/Standby mode in VMware Cloud on AWS SDDC; the TGW also had to be deployed without ECMP enabled.

Now that VMware Cloud on AWS SDDC supports ECMP with route based IPSEC VPN, customers can deploy TGW with ECMP and leverage up to 4 Route Based IPSEC VPN tunnels doing ECMP for increased bandwidth and resiliency; an example deployment using 4 Route Based IPSEC VPN tunnels from VMware Cloud on AWS SDDC to native AWS VPC is shown below.

Figure 5: 4 x Route Based IPSEC VPN tunnels doing ECMP with AWS TGW

Services

3.) DHCP Relay

Prior to 1.7 SDDC, customers could only use the native NSX DHCP capability where simple configurations such as defining IP ranges for workloads on specific network segments could be done. With the recent 1.7 SDDC release, customers can now leverage DHCP relay to allow for using their own advanced 3rd party DHCP server. On the VMware Cloud on AWS console below, you can see a new menu item on the left called DHCP.

Figure 6: DHCP Relay Menu Item on VMware Cloud on AWS SDDC Console

Below you can see DHCP Relay being configured.

Figure 7: VMware Cloud on AWS SDDC – DHCP Relay Configuration

A few important things to note about DHCP Relay:

Customers have a choice to use the native NSX DHCP capabilities in VMware Cloud on AWS or to use DHCP Relay to leverage an advanced external/3rd party DHCP server; it is not possible to use both
To enable DHCP Relay, the Attach to Compute Gateway option must be checked; it is unchecked by default. DHCP Relay cannot be enabled if there are any network segments using the native NSX DHCP capabilities; those respective network segments must be deleted first
DHCP Server can sit in the SDDC on a NSX network segment, on-prem, or even in connected VPC – requirement is that it must be routable to
Multiple DHCP Server IP addresses can be configured for DHCP Relay; the first server IP address listed will be tried first; if destination is unreachable, the second IP address will be tried and so on

Below, you can see a network segment is being created; note, DHCP has to also be enabled on this network segment as shown below. Also, DHCP IP Range needs to be entered here; however, this IP range is only for documentation on what IP addresses are used for the network segment. The actual IP address is received and managed from the 3rd party DHCP Server configured in the DHCP Relay configuration.

Figure 8: VMware Cloud on AWS SDDC – Network Segment Using DHCP Relay

The new DHCP Relay functionality is useful for many important use cases like VDI where desktops are quickly provisioned for use and effective IP address management is critical.

Operations

4.) NSX-T APIs available in API Explorer

With VMware Cloud on AWS 1.7 SDDC, the NSX-T APIs can be found and used within the VMware Cloud on AWS SDDC’s API Explorer. Customers can easily lookup and test NSX-T APIs directly from API Explorer.

You can see from the below screenshot, there are two NSX-T APIs, NSX VMC Policy API and NSX VMC AWS Integration API. NSX VMC Policy API includes all the NSX Networking and Security APIs for the NSX capabilities within the SDDC. NSX VMC AWS Integration API includes APIs that are specific to AWS like Direct Connect.

Figure 9: VMware Cloud on AWS SDDC NSX APIs

Below you can see, from API Explorer, customers can see a list of respective API calls and even enter parameters and execute the call on the respective SDDC.

Figure 10: API Explorer – NSX-T API call to display CGW firewall rules

Figure 11 below displays API Explorer and the execution and results of a NSX-T API call to display CGW firewall rules. Note, customer can quickly test and execute API calls directly from the API Explorer.

Figure 11: API Explorer – Execution and results of NSX-T API call to display CGW firewall rules

From the below screenshot, you can see the NSX-T API call executed returned specific CGW firewall rules and respective details.

Figure 12: API Explorer – Exploring API call results of NSX-T API call to display CGW firewall rules

The above example used the NSX VMC Policy API which includes all the NSX Networking and Security APIs for the NSX capabilities within the SDDC. The below example uses the NSX VMC AWS Integration API which includes APIs that are specific to AWS like Direct Connect. You can see an API has been executed to retreive Direct Connect BGP related information. The results show that routes learned over VPN are preferred over routes learned via Direct Connect Private VIF. Thus, the Use VPN as backup to Direct Connect option is not enabled and VPN is not being used as Standby for Direct Connect Private VIF.

Figure 13: API Explorer – Executing API to retreive Direct Connect BGP related information

Additionally, as shown below, it is easy to search for APIs in API Explorer. Below, the APIs are searched for tag, and an NSX-T API is returned for applying NSX Security Tags to workloads.

Figure 14: API Explorer – API search capability

Finally, the VMware Cloud on AWS NSX-T API documentation has been updated. At this link you can see NSX-T APIs for VMware Cloud on AWS; the structure/layout is the same as seen in API Explorer where you have both NSX VMC Policy API and NSX VMC AWS Integration API.