WilliamLam.com

Managing Distributed Firewall Rules in VMC using PowerShell & NSX-T Policy API

by // Leave a Comment

Back in November 2018, VMware Cloud on AWS (VMC) SDDC 1.5 Patch 1 was released and it was one of the most highly anticipated release by our customers. Although this was a "patch" release, it included a ton of new features and also brought the full power of the NSX-T platform to VMC as a generally available feature!

With NSX-T, customers also now have access to the highly requested Distributed Firewall (DFW) capability which enables granular control over East-West traffic between application workloads. In addition to enabling micro-segmentation in VMC, customers can now easily manage DFW rules using a number of grouping constructs (Tags, Virtual Machines & Conditional Statements) to create dynamic policies which follow their workloads.


Customers can configure DFW (as well as Edge Firewall) rules using the VMC Console UI but many of you have been asking for an automated method, especially if you need to create a large number of policies for more than a couple of workloads. After returning from the holiday, I spent the last couple of days updating my NSX-T Policy PowerShell Module which now includes basic support for managing DFW. For those of you who are new to using the NSX-T Policy API and PowerCLI, be sure to give these two articles a read here and here before proceeding further.

[Read more...]

Getting started with the new NSX-T Policy API in VMC

by // 26 Comments

Today, when you deploy a new SDDC on VMware Cloud on AWS (VMC), NSX-T is now the default networking stack and NSX-V is no longer used for net new deployments. In fact, we are about to start migrating existing VMC customers who have an NSX-V SDDC and converting them to an NSX-T SDDC. Humair Ahmed who works over in our Networking & Security Business Unit has an excellent blog post here that goes into more details on what NSX-T brings to VMC.


Upon first glance, you might think that this is the exact same version of NSX-T that we have been shipping to our on-premises customers but in fact, it is actually a brand new and improved version. Similar to vSphere (vCenter and ESXi) and VSAN, VMC is always running a newer version of our software than our on-prem customers. One immediate difference that you should be aware of when using NSX-T in VMC is that the current NSX-T API is not available and instead a new NSX-T Policy API has been introduced to help simplify the consumption of NSX-T. All functionality in the current on-prem NSX-T API can be consumed using the new Policy API.

At VMworld, I spoke to a number of current and upcoming customers with NSX-T based SDDCs and they were really interested in using the new NSX-T Policy API and as the title of this blog post suggests, this will be a quick primer on how to do that. Before we get started, confirm that you have an NSX-T based SDDC deployed. If you are not sure, there are a few ways to determine this using either the VMC Console UI or API, instructions can be found here and here.

[Read more...]

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