WilliamLam.com

Quick Tip - How do I tell if NSX-V or NSX-T is installed?

by // 1 Comment

This question came up last week asking for a programmatic method to identify whether NSX-V or NSX-T is deployed in your environment. With NSX-V, vCenter Server is a requirement but for NSX-T, vCenter Server is not a requirement, especially for multi-hypervisor support. In this post, I will assume for NSX-T deployments, you have configured a vCenter Compute Manager.

Both NSX-V and NSX-T uses the ExtensionManager API to register themselves with vCenter Server and we can leverage this interface to easily tell if either solutions are installed. NSX-V uses the com.vmware.vShieldManager string to identify itself and NSX-T uses the com.vmware.nsx.management.nsxt string to identify itself.

Here is a quick PowerCLI snippet that demonstrates the use of the vSphere API to check whether NSX-V or NSX-T is installed and provides the version shown in the registration:

$extensionManager = Get-View ExtensionManager

foreach ($extension in $extensionManager.ExtensionList) {
    if($extension.key -eq "com.vmware.vShieldManager") {
        Write-Host "NSX-V is installed with version"$extension.Version
    } elseif($extension.key -eq "com.vmware.nsx.management.nsxt") {
        Write-Host "NSX-T is installed with version"$extension.Version
    }
}

Here is a screenshot from my environment which has both NSX-V (6.4) and NSX-T (2.1) installed:


Note: Due to some current testing, I have not upgraded my NSX-T deployment to the latest 2.2 release, so I do not know if the version gets bumped to match the actual released version

VPN Configuration to VMware Cloud on AWS using pfSense

by // 1 Comment

Provisioning a new SDDC on VMware Cloud on AWS (VMC) is not an operation that I perform on a regular basis. Usually, one of the first tasks after a new SDDC deployment is setting up a VPN connection between your on-premises datacenter and your VMC environment. Given this is not a frequent activity, I always forget the specific configurations required for my particular VPN solution and figure I would document this for myself in the future as well as anyone else who might also have a simliar setup.

Since the VMC Gateways are just NSX-v Edges, any VPN solution that supports the NSX-v configurations will also work with VMC. In my environment, I am using pfSense which is a popular and free security Virtual Appliance that many folks run in their VMware home lab. Before getting started, it is also important to note that there are two gateway endpoints that you can setup separate VPN connections to. The first is the Management Gateway which provides access to the management infrastructure such vCenter Server, NSX and ESXi hosts and the second is the Compute Gateway which provide access to the VM workloads running within VMC. Since the instructions are exactly the same for setting up the VPN for either gateways, I am just going over the Management Gateway configuration and where applicable, I will note the minor differences.

Step 1 - Login to the VMC Portal (vmc.vmware.com) and select one of your deployed SDDCs. Click on the Network tab and you should be taken to a page like the one shown in the screenshot below. Here is where you will be applying your VPN configuration from the VMC side. Start off by making a note of the public IP Address for the Management Gateway (highlighted in yellow), this will needed when configuring the VPN configuration on the on-prem side. It is probably a good idea to also note down the Compute Gateway IP Address if you plan on configuring that as well.


[Read more...]

ESXi Learnswitch – Enhancement to the ESXi MAC Learn DvFilter

by // 23 Comments

The ESXi MAC Learn dvFilter Fling was released a little over two years ago and it has become a must have when it comes to running our ESXi Hypervisor within a VM, also referred to as Nested ESXi. The reason this Fling has become such a popular hit amongst our customers and partners is that it greatly improves the performance when “Promiscuous Mode” is enabled on a Virtual or Distributed Virtual Portgroup, which is a requirement for using Nested ESXi. Although this Fling works great, there are a couple of limitations with this solution today. The first of which is called out in the original Fling release notes, that once a MAC Address has been learned, it never ages out which is not ideal for long running Nested ESXi environments that generates a large amount of new MAC Addresses. The second, is the lack of vMotion support where the learned MAC Address table is not transfered to the destination ESXi host and must be re-learned.

To help address both of these limitations, the folks over in the Network and Security Business Unit (NSBU) have been working hard to improve upon the existing solution and have developed a new native MAC Learning VMkernel module called the Learnswitch. This new Learnswitch not only helps improves Nested ESXi workloads but it can also potentially benefit other workloads such as Nested Containers or other 3rd Party network inspection software. One immediate difference from the previous MAC Learn dvFilter solution is that rather than operating on the Network IO Chain, the filtering is now performed within the outer virtual switch layer itself which will provide some additional performance gains. The other added benefit from an internal VMware standpoint is that the Learnswitch is now vmkapi compatible, which means we will have a better backwards compatible story for supporting old releases of ESXi. One downside to this new solution compared to the previous one is that because the dvFilter operated below the virtual switch layer, it could support both a Virtual Standard Switch as well as the Distributed Virtual Switch. With the new Learnswitch, a Distributed Virtual Switch will be required. If you currently do not meet the requirements of the new Learnswitch, you can continue using the dvFilter, but it is recommended that you do not mix both on a single system but you can definitely make use of both solutions across different ESXi hosts depending on the constraints of your environment.

Here are some of the new capabilities provided by the new Learnswitch module:

  • Overlay Network based that learning and filtering are done in Etherswitch forwarding check
  • MAC Address learning is based on VLAN ID or VXLAN ID on uplink and leaf port
  • Packet is filtered on uplink and leaf port if the MAC is learned on a different port
  • MAC Address table size is 32k per system
  • MAC Address aging support with default aging time of 5 minutes and configurable
  • Unknown unicast packet is flooded by default and configurable to drop
  • vMotion support that the MAC table learned on the port is transferred to destination host and RARP packet is sent
  • Standalone VMkernel module available as a VIB
  • net-learnswitch CLI to display MAC Address table, configuration and stats

[Read more...]