WilliamLam.com

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

by // 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/sites/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

Building your own Virtual Appliances using OVF properties Part 1

by // 5 Comments

This has been a topic I have been wanting to write about for quite some time, especially as I get asked about this on fairly regular basis from both partners and customers. I normally point folks over to our official Virtual Appliance (VA) authoring tool, VMware Studio which includes a number of development resources to help get started. Studio is used by many of our partners when creating their VA offerings, although it may not be the easiest thing to get started with, it does provide a complete end-to-end solution.

Most recently, I found myself building out a couple of VAs for my own day to day use, including a custom PhotonOS OVA that allows me to configure a static network address during deployment through the use of custom OVF properties. The official PhotonOS OVA that VMware ships does not provide this option and automatically defaults to DHCP. If you want to setup a static IP Address, you would need to first deploy the VM and then login to the console or SSH (if you have DHCP enabled) and then manually update the networking settings.


For my use case, Studio was going to be overkill and not to mention it may not even support PhotonOS or other modern OSes in general. However, everything that is needed to build your own VA is actually available right in vCenter Server. This was the perfect opportunity and excuse for me to finally document *my* process, in case it can help others wanting to do the same, especially for a home lab setup. In Part 1, I will take you through the two important concepts of building your own VA and then in Part 2 and Part 3, we will take a look at building both a Linux and Windows VA. I will also publish a reference Linux and Windows implementation so that you can use that as a basis to build your own VA, which is not limited to just Linux or Windows, it can be ANY GuestOS that vSphere supports.

[Read more...]

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

by // 3 Comments

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.

[Read more...]