In last post of this series we created logical switches and established communication between the App and Web VM which were on same subnet and connected to same logical switch. In this post we will learn about logical routing.

If you are not following along this series, then I recommend reading earlier posts of this series from below links:

1: Introduction to NSX-T

2: NSX-T Architecture

3: NSX Manager Deployment

4: NSX Controllers Automated Deployment

5: NSX Controllers Manual Deployment

6: Prepare Esxi host to form NSX-T Fabric

7: Configuring Uplink Profile

8: Configuring Transport Zone and Transport Nodes

9: Creating Logical Switches and Testing Connectivity

Optimal routing is one of the biggest challenges in any datacenter and NSX revolutionized the way how networking was used in infrastructure. 

NSX-v offered distributed routing to SDDC and because of this routing between different subnets on a Esxi hypervisor can be done in kernel and traffic never has to leave the hypervisor and thus eliminating the traffic hairpinning problems.… Read More

In last post of this series we configured transport zones and transport nodes. We discussed about the modes of transport zone and also touch based on N-VDS. In this post we will learn how to create logical switches in NSX-T and we will test connectivity between vm’s attached to same logical switch.

If you are not following along this series, then I recommend reading earlier posts of this series from below links:

1: Introduction to NSX-T

2: NSX-T Architecture

3: NSX Manager Deployment

4: NSX Controllers Automated Deployment

5: NSX Controllers Manual Deployment

6: Prepare Esxi host to form NSX-T Fabric

7: Configuring Uplink Profile

8: Configuring Transport Zone and Transport Nodes

Logical switch provides layer 2 connectivity for the virtual machines that are attached to the it. In last post we discussed that transport zones are of two types (Overlay and VLAN) and the type of logical switch is based on to which type of transport zone it connects to. … Read More

In last post of this series we discussed about Uplink profiles. In this post we will learning about transport zones and its types.

If you are not following along this series, then I recommend reading earlier posts of this series from below links:

1: Introduction to NSX-T

2: NSX-T Architecture

3: NSX Manager Deployment

4: NSX Controllers Automated Deployment

5: NSX Controllers Manual Deployment

6: Prepare Esxi host to form NSX-T Fabric

7: Configuring Uplink Profile

What is transport zone in NSX-T?

As per vmware documentation

A transport zone is a container that defines the potential reach of transport nodes. Transport nodes are hypervisor hosts and NSX Edges that will participate in an NSX-T overlay.

What is meant by above is that if two or more Esxi hosts that are configured as transport nodes participate in the same transport zone, then VMs on these different hosts using the overlay network can communicate with each other.… Read More

In last post of this series we prepared the Esxi host for NSX-T and we ensured that host connection to NSX manager was up and all necessary vib’s have been pushed on hosts. In this post we will learn about uplink profile.

If you are not following along this series, then I recommend reading earlier posts of this series from below links:

1: Introduction to NSX-T

2: NSX-T Architecture

3: NSX Manager Deployment

4: NSX Controllers Automated Deployment

5: NSX Controllers Manual Deployment

6: Prepare Esxi host to form NSX-T Fabric

What is Uplink profile in NSX-T?

From VMware documentation:

An uplink profile defines policies for the links from hypervisor hosts to NSX-T logical switches or from NSX Edge nodes to top-of-rack switches.

Confused? All right lets simplify it a bit.

Uplink profile is pretty much similar to specifying the teaming policy when you enable VXLAN on Esxi host in NSX-v.… Read More

In last 2 post of this series, we discussed the automated and manual deployment of NSX controllers and how to form controller cluster. In this post we will learn how to do host preparation for NSX-T.

If you are not following along this series, then I recommend reading earlier posts of this series from below links:

1: Introduction to NSX-T

2: NSX-T Architecture

3: NSX Manager Deployment

4: NSX Controllers Automated Deployment

5: NSX Controllers Manual Deployment

When we do host preparation, NSX-T pushes few vibs on the Esxi host (just like NSX-v) and once the hosts are prepared they are known as fabric nodes. All Esxi host that are fabric nodes have NSX-T modules installed and are registered with the NSX-T management plane.

Before jumping into host preparation task, ensure that  install-upgrade service status on NSX-T manager is reporting as running. If this service is down, NSX manager won’t be able to push the vibs onto the ESXi hosts when we add them in the fabric.… Read More

In last post of this series, we learnt how to deploy NSX-T controllers automatically via NSX manager and we saw its pretty much same as deploying controllers in a NSX-V environment. 

In this post we will learn how to deploy the NSX controllers manually. 

If you are not following along this series, then I recommend reading earlier posts of this series from below links:

1: Introduction to NSX-T

2: NSX-T Architecture

3: NSX Manager Deployment

4: NSX Controllers Automated Deployment

Manual steps are a bit lengthy and complex so we have to be careful with the sequence of commands which we will be running to form controllers cluster. Before deploying the controller nodes, make sure following prerequisites are met:

• vCenter Server and ESXi hosts are deployed.
• Esxi hosts have been added to vCenter and networking and storage configuration on hosts are in place. 
• NSX Manager is deployed.
• ESXi host must have enough CPU, memory, and hard disk resources to support controller deployment.

In last post of this series we deployed the NSX manager appliance. In this post we will learn how to deploy the NSX-T controller nodes.

If you are not following along this series, then I recommend reading earlier posts of this series from below links:

1: Introduction to NSX-T

2: NSX-T Architecture

3: NSX Manager Deployment

There are 2 methods of deploying NSX controllers for vSphere integration with NSX-T:

• Automated Installation of Controller from NSX Manager
• Manual Installation of NSX Controller on ESXi via GUI or OVF tool

In this post we will not talk about controller deployment for non-vSphere infrastructure.

Also in this post we will be discussing only about Automated method for controllers. Manual installation will be covered in Next post of this series.

In order to deploy NSX controllers to consume NSX-T for your vSphere infrastructure, make sure following prerequisites are met:

• vCenter Server and ESXi hosts are deployed.

In last post of this series we discussed about NSX-T architecture. In this post we will be deploying the NSX-T components in lab. 

Lets start with deploying NSX manager first to form the management plane. NSX manager is deployed via ova file which can be downloaded from VMware website.

The current version of NSX-T is 2.2.0 and it can be downloaded from here

Please refer NSX-T 2.2 Installation Guide before going ahead with deployment.

NSX-T 2.2.0 supports following hypervisor versions:

• vSphere 6.5/6.5 U1/6.5 U2
• RHEL KVM 7.3
• Ubuntu KVM 16.04 

NSX manager deployment is pretty straight forward like any standard virtual appliance deployment. Steps are shown in screenshot below. 

For more information on NSX Manager installation, please see this article

Once the NSX Manager boots up, verify that the IP address set during deployment was applied as expected.

Also you can try to ping NSX-T from vCenter server and Esxi host to verify its connectivity. … Read More

As we discussed in first post of this series that NSX-T was born to meet the demands of the containerized workload, multi-hypervisor and multi-cloud.

The best use case that you can think of NSX-T is that it provides seamless connectivity and security services for all types of endpoints including virtual machines, containers and bare metal. It doesn’t really matter where these endpoints are. It could be in your on-prem datacenter, a remote office or in the cloud.

In this post we will look how NSX-T architecture looks like. 

Like NSX-V, NSX-T too contains a management plane, data plane and a control plane. Lets discuss about each plane individually here.

Data Plane

• NSX-T uses in-kernel modules for ESXi and KVM hypervisors for constructing data plane. 
• Since NSX-T is decoupled from vSphere, it don’t rely on vSphere vSwitch for network connectivity. NSX-T data plane introduces a host switch called N-VDS (NSX Managed Virtual Distributed Switch).

VMware NSX is one of the most sensational products that VMware produced 5 years ago, after the Niciria acquisition, and over the years, this product has just gotten better and better. NSX revolutionized the SDDC by adding SDN capabilities and changing the way SDN was used before NSX. 

One of the major limitations of NSX-V was that it could be used only with vSphere and not with other platforms, and customers were continuously demanding a version of NSX that could be integrated with non-vSphere platforms.

To overcome this challenge, VMware came up with NSX-T, which is a version of NSX that supports both vSphere and non-vSphere-based infrastructure. This version of NSX can be integrated with other hypervisors, such as KVM, and application frameworks, such as Redhat Openshift, Docker/Containers, and Pivotal.

As we know, in NSX-V, vCenter was a centralized management plane, but NSX-T has its own management interface. As of now, NSX-T doesn’t offer the same full feature set as NSX-V, but VMware is continuously making enhancements to this product to make it more robust.… Read More