NSX-T

Which NSX-T Policy APIs are used in the NSX-T UI in VMC?

02/20/2019 by William Lam Leave a Comment

As the adoption of VMware Cloud on AWS (VMC) continues to accelerate, one of the very first UI interface that customers must interact with is the NSX-T UI, for enabling basic connectivity. By default the Edge Gateway has a Deny All Firewall Rule, so you will need to come to this screen to setup connectivity from your on-premises environment including a Direct Connect (DX) or Route/Policy-Based VPN. For some customers who have familiarize themselves with the NSX-T UI and its capabilities, usually the next order of business is how do I go about automating these various aspects from Day 0 setup all the way to Day N where I am migrating in or creating additional workloads.

A very common set of questions that I have been getting lately is which API do I need to look at to do X in the NSX-T UI in VMC?

Having spent some time with the NSX-T Policy API, I figure it would be useful to share the categories of NSX-T Policy API that maps back to what you see in the NSX-T UI in VMC. The list below is not exhaustive, but should it should point you in the right direction when needing to automate a particular operation.

How to retrieve the NSX-T Overview Info (SDDC Public IP, Appliance & Infra Subnet, etc.) in VMC?

02/08/2019 by William Lam Leave a Comment

I recently a question from one of our VMware Cloud on AWS (VMC) field folks who was looking to programmatically retrieve the SDDC Public IP Address which is shown under the NSX-T Networking & Security Overview page within the VMC Console as shown in the screenshot below.

This actually had me stumped for a bit as I was not able to find anything mentioned in the NSX-T Policy API documentation. My last resort before pinging the NSX Engineers was to use one of my favorite browser tool, Chrome Developer Tools, which allows me to inspect all requests made to a specific web page and can also be helpful in figuring out which REST APIs the UI is using.

It turns out for this particular page, the information was not actually coming from the NSX-T Policy API but rather from another endpoint and specifically /cloud-service/api/v1/infra/sddc-user-config which I am guessing has to do with the fact that some of this information is really AWS specific information such as the Public IP Address for example. In any case, once I realized what the endpoint was and that I could still use the VMC NSX-T Reverse Proxy to retrieve the details, it was pretty straight forward.

Using NSX-T Policy API to retrieve the Routing Table in VMC

02/04/2019 by William Lam Leave a Comment

When configuring connectivity from your on-premises environment to your VMware Cloud on AWS (VMC) NSX-T SDDC, you can either use a Direct Connect (DX) or a Route/Policy-based VPN. During the configuration, it can really be useful to have insights into the network routing table, especially if you need to verify a specific route or for general network debugging. Today, the NSX-T routing table in VMC is not currently available in the Network and Security UI, however this information can be retrieved using the NSX-T Policy API, which I have written about quite extensively here, here, here and here.

The NSX-T routing table can be retrieved by performing a GET operation on /policy/api/v1/infra/tier-0s/vmc/routing-table?enforcement_point_path=/infra/deployment-zones/default/enforcement-points/vmc-enforcementpoint By default, you will get the entire routing table, but you also filter out specific route sources such as BGP, Static or Connected routes by appending the following query parameter to the request URL ?route_source={BGP,CONNECTED,STATIC}

To demonstrate how this API works, I have created a new function in my VMC NSX-T PowerShell Module as well as a quick shell script sample using cURL.

For PowerShell/PowerCLI users, I have a new Get-NSXTRouteTable function which will list the entire routing table by default as shown in the screenshot below.

You can also filter on a specific route source such as BGP, CONNECTED or STATIC routes by simply providing the -RouteSource argument and the route source type. In the screenshot below, I am only interested in the BGP routes.

Here is the output when running the list_vmc_nsxt_route_table.sh script which requires a valid CSP Refresh Token, OrgId and SDDCId

Changing the default behavior of the NSX-T Distributed Firewall (DFW) in VMC to Deny All

01/30/2019 by William Lam Leave a Comment

In VMware Cloud on AWS (VMC), the default behavior of the NSX-T Distributed Firewall (DFW) is to currently allow all traffic between compute workloads even across different logical networks (Segments). Today, the default behavior is currently not configurable and is something the NSX team is looking into with a few update of the VMC Service.

Having said that, it is actually pretty straight forward to create a new Deny All policy that would achieve the same desired behavior of blocking all traffic by default. Since this topic has come up a few times, I figure it would be useful to share the quick fix and big thanks to Michael Kolos, one of our VMC Customer Success Engineers who shared the original tidbit with me.

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

01/04/2019 by William Lam 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.

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

09/17/2018 by William Lam 12 Comments

Today, when you deploy a new SDDC on VMware Cloud on AWS (VMC), it is based on NSX-V by default, nothing ground breaking. However, customers also have the option to request an NSX-T based SDDC, which actually came as a surprise to a couple of folks who I spoke with at VMworld. Back in August, Early Access for NSX-T based SDDC was announced and customers can take advantage of the additional networking and security capabilities provided by NSX-T within VMC. Humair Ahmed who works over in our Networking & Security Business Unit has an excellent blog post here that goes into more details. If you are interested in an NSX-T based SDDC, please reach out to your local VMware account team for more information.

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.