Objective 2.3 – Configure and Manage Routing in NSX

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

Configuring Layer 2 Bridging in NSX

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

Objective 2.1 – Create and Manage Logical Switches

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.
Read More

Objective 1.3 – Configure and Manage Transport Zones

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

Deleting NSX Controller Using API

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

Read More

vRealize Automation 7.3-Simple Installation: Part 2: NSX Deployment and Configuration

In last post of this series I discussed about my lab setup. In this post we will learn how to deploy and configure NSX.

Last year I did a complete lab on NSX and posted few blog articles on installation and configuration stuffs. So in this post I will not go into much details on NSX stuffs. If you are new to NSX then make sure you read VMware documentation on NSX deployment.

Also you can view below articles from my blogs on NSX.

1: Installing and Configuring NSX

2: Deploying NSX Controllers

3: Preparing Esxi Hosts and Cluster

4: Configure VXLAN on the ESXi Hosts

Lets first start with deploying NSX.

Nothing fancy here. NSX deployment involves same steps as deploying any other virtual appliance.  Here is a slideshow for deployment steps.

Once deployment completes and NSX manager boots up, login to the appliance by typing https://NSX-fqdn/. Credentials are admin/pwd set during deployment.Read More

vRealize Network Insight-Part-4: Monitoring Infrastructure

In last post of this series we had a look on how to add data sources and successfully added vCenter server and NSX manager so that vRNI can fetch and provide us necessary information. In this post we will see how we can monitor our infrastructure and how we can improve it based on recommendations generated by vRNI. Let’s get started.

If you have missed earlier posts of this series, you can read them from below links:

1: Introduction to vRealize Network Insight

2: Deploying vRNI Appliance

3: Configuring vRNI

We will start with checking Esxi host statistics. 

From the left pane select Path and Topology and select Host.

From the drop down menu select the host for which you want to retrieve the stats.

You will be presented with host stats for last 24 hours. This time range can be modified by clicking on down arrow button as shown in screenshot.Read More

vRealize Network Insight-Part-3: Configuring vRNI

In last post of this series we had a look on deployments steps of the Platform and Proxy VM. In this post we will configure the vRNI deployments and will see what kind of data the dashboard presents to user.

If you have missed earlier posts of this series, you can read them from below links:

1: Introduction to vRealize Network Insight

2: Deploying vRNI Appliance

Lets begin with configuring the appliance.

Login to vRNI appliance by typing https://<IP or FQDN of the platform appliance> in your browser.

First we have to add a data source. To do so click the settings button on the top right corner as shown below.

Click on Add new source button

From the drop down menu select vCenter server as source type.

Fill in the vCenter details and click on validate. 

As a best practice, I like to use service accounts for components communication. I have added an account and configured the role in vCenter.Read More

vRealize Network Insight-Part-2: Installation

In last post of this series we discussed briefly about what is vRNI and why you should have it your environment. In this post we will look into the deployments steps.

The current version of vRealize Network Insight is 3.4. I am going to deploy the same in my lab. 

The installation process for VMware vRNI is a two-step process that includes:

  • Deploying VMware vRNI platform appliance.
  • Deploying VMware vRNI proxy appliance.

Following are the resource requirements for deploying the Platform and Proxy OVA.

vRealize Network Insight Platform OVA

  • 8 cores – Reservation 4096 Mhz
  • 32 GB RAM – Reservation – 16GB
  • 750 GB – HDD, Thin provisioned

vRealize Network Insight Proxy OVA

  • 4 cores – Reservation 2048 Mhz
  • 10 GB RAM – Reservation – 5GB
  • 150 GB – HDD, Thick provisioned

Lets jump into lab and start the deployment process. To keep the length of the post to a reasonable length, I have omitted the deployment steps of the ova file except the final network information input screens where you have to define IP/Netmask/GW/DNS/NTP etc.Read More

vRealize Network Insight-Part-1: Introduction

Recently I was having a discussion with one of my friend on NSX related topic and then I came to know about a new must have tool for your NSX based lab. Title of this post itself explains which tool I am talking about here.

What is vRealize Network Insight (vRNI) and where it came from?

vRealize Network Insight is a product for delivering intelligent operations for your SDN environment (specially based on NSX). vRealize Network Insight, allows a single pane of glass view of the VMware NSX environment. vRNI integrates with NSX to deliver intelligent operations for software defined networking.

In June,2016 VMware acquired a company called Arkin Net and named the product vRealize Network Insight. I read few blog where people used to refer this tool by nickname “vernie” and it sounds just exactly right. Cool name isn’t it?

What advantage vRNI offers?

With the help of vRNI you can optimize network performance and availability with visibility and analytics across virtual and physical networks.Read More