NSX Edge Services Gateway supports site to site IPSec VPN. You can create IPSec VPN between an ESG and any other network device (hardware/software) which supports IPSec or you can have ESG at both source and target site for this purpose. 

Using IPSec VPN, you can create a secure connection between two sites and route the internal subnets between those two sites. Just ensure you don’t have an overlapping subnets behind the edge gateway. You can create more than one IPSec tunnel on ESG and number of tunnels is directly dependent on size of NSX edge. 

As per VMware NSX Administration guide, Number of IPSec Tunnels that can be created per ESG is as follows:

Following are the algorithms which are supported by NSX IPSec VPN:

• AES (AES128-CBC)

• AES256 (AES256-CBC)

• Triple DES (3DES192-CBC)

• AES-GCM (AES128-GCM)

• DH-2 (Diffie–Hellman group 2)

• DH-5 (Diffie–Hellman group 5)

• DH-14 (Diffie–Hellman group 14)

• DH-15 (Diffie–Hellman group 15)

• DH-16 (Diffie–Hellman group 16)

Lets jump into lab now and learn how to configure IPsec VPN.… Read More

VMware released NSX 6.4.0. this month and this version brought many features, improvements and bug fixes which are outlined in the Release Notes

Before upgrading to NSX 6.4.1, check VMware interop matrix to make sure your underlying infrastructure is compatible with this version. Your VMware vSphere should be at 6.0 U2 or greater to upgrade to NSX 6.4

I am currently running NSX 6.3.5 in my lab and I thought to upgrade it to 6.4. I wanted to play with Rest API option for NSX manager upgrade, as from GUI I have done several times.

You can find the instructions about upgrade via Rest API on page 124 of NSX-6.3-API-Guide

Lets walk through this step by step.

1: Download the NSX upgrade bundle: NSX 6.4 upgrade bundle can be downloaded from here

2: Upload the upgrade bundle: I have downloaded the upgrade bundle on one of my linux box where I have curl installed and I will be employing curl to fire Rest API.… Read More

Configure the appropriate Load Balancer model for a given application topology

The two main drivers for deploying a load balancer are scaling out an application (by distributing workload across multiple servers), along with improving its high-availability characteristics. 

NSX provides basic form of load balancing through Edge Gateway. The NSX Edge load balancer distributes network traffic across multiple servers to achieve optimal resource utilization. 

The NSX Edge services gateway supports two kinds of load balancer  deployments:

One-armed mode (or proxy mode): In proxy mode, the load balancer uses its own IP address as the source address to send requests to a backend server. The backend server views all traffic as being sent from the load balancer and responds to the load balancer directly. Following events take place when LB is deployed in proxy mode:

1. User connects to a VIP address (LB address) that is configured on the Edge gateway.
2. The ESG performs a destination NAT to replace the VIP with one of the servers in the configured pool.

Deploy the appropriate NSX Edge (ESG/DLR) device according to a deployment plan

Method of deploying the Edge Services Gateway (ESG) and Distributed Logical Router (DLR) is same. In Fact both are NSX edges only, but difference lies in the functionality offered by ESG and DLR.

DLR optimizes East-West traffic in datacenter i.e traffic between the VM’s whereas ESG optimizes North-South traffic i.e traffic going out of datacenter. 

The ESG sits at the perimeter of your SDDC and connects to the external network. You may see sometimes ESG being referred as perimeter gateway as well.  The main services provided by ESG are: 

• NAT.
• DHCP.
• Firewall.
• Load balancing.
• L2 and L3 VPNs.

The ESG supports static, OSPF, BGP and IS-IS routing protocols. The DLR supports only BGP and OSPF protocol.

We can deploy ESG in HA mode where 2 edge VM’s are deployed in active/standby mode. The control and data plane reside inside the VM.… Read More

What is Layer 2 (L2) Bridging?

A Layer 2 (L2) Bridge allows connectivity between a logical switch (VXLAN based) and a VLAN based portgroup on vDS that shares the same IP address space i.e VMs connected to VXLAN and distributed portgroup are on same subnet. 

A possible use cases for this scenario can be, an application server on a logical switch need to reach a database server connected to the physical network or a customer wants to extend their application to the cloud but wants to keep certain components on-site and because its legacy application it cannot be re-IP’d or any other constraint.

Prior to NSX version 6.2, it was not possible to bridge a Logical Switch that was connected to a Distributed Logical Router: for that scenario it was required to connect the Logical Switch directly to an Edge Gateway.

With NSX 6.2 VMware introduced in-kernel software L2 Bridging capabilities that allow you to connect VLAN backed VMs to VMs connected VXLAN based network (virtual wires).… Read More

What is a Logical Switch?

Functionality of a Logical switch is very similar to that of a physical switch i.e they allow isolation of applications and tenants for security purpose. A logical switch when deployed, creates a broadcast domain to allow isolation of the VM’s running in infrastructure. Logical switches uses VXLAN to provide separation of duties.

The logical switch operates in the overlay and is totally independent of the physical network (the underlay). Logical switches are connected to Transport Zones which spans across one or more cluster or all cluster across a virtual datacenter.

To know more about logical switches, you can refer to this article which I wrote sometime back or can refer VMware documentation

Prerequisites for creating a Logical Switch

Before you go and start creating logical switches in your environment, you have to make sure you meet following requirements:

• vSphere distributed switches must be configured. You cannot deploy logical switches on standard switches.

A transport zone is a user defined scope for VXLAN networking traffic. Transport zones defines which hosts/clusters will be able to participate in VXLAN based virtual networking. Transport zones acts as a container to host logical switches and Esxi host uses these logical switches to communicate among themselves or with the underlying physical infrastructure.

Transport zone is a boundary where Esxi hosts create tunnels among themselves for allowing VXLAN traffic to blow. A transport zone can be associated with one or more vSphere clusters and you can have more than one transport zone in your environment.

Prerequisite: Before creating transport zone, make sure your Esxi hosts are prepared and VXLAN has been configured already. 

Create Transport Zones

To create a new transport zone, log into the vSphere Web Client and navigate to Networking & Security > Installation > Logical Network Preparation and click on green + button.

Provide a name for the transport zone and select the appropriate replication mode (we will discuss this shortly).… Read More

Today while cleaning up my lab, I came across situation where I needed to delete one of the deployed controllers. Although this task is fairly simple from vCenter UI, but recently I came across a situation (in VMware HOL) where I was unable to delete a controller via UI.

As an alternative, I came across set of API calls which did the job for me. In this post I will demonstrate how to use API calls to delete stuck/bad NSX controllers.

Step 1: Fetch controller details

Example: curl -sik -u “vcadmin@corp.local” -H ‘Content-Type: application/xml’ -X GET https://nsxmgr-01a.corp.local/api/2.0/vdn/controller | tidy -xml -indent -quiet

Output