NSX-T vs NSX-V Differences and Similarities

When it comes to network virtualization in the enterprise datacenter, there is no better solution on the market currently than VMware’s NSX network virtualization platform.

VMware NSX has certainly changed over the past few years. One of the changes that you may have noticed when looking at the NSX platform is there are now two different “versions” of NSX that you can deploy in your environment – NSX-T vs NSX-V.

If you are new to VMware’s network virtualization portfolio of products, you may wonder what the differences and similarities are between the two platforms. In this post, we we take a thorough examination of NSX-T vs NSX-V differences and similarities to see how these two solutions compare.

What is VMware NSX and How Can You Use It?

You may well wonder what exactly VMware NSX is to begin with and how you can use this product in your existing VMware vSphere environment. VMware NSX is VMware’s network virtualization platform for creating virtual networks.

You can think of network virtualization as a hypervisor for your network the same as ESXi is a hypervisor for your servers. Just as server virtualization allows you to abstract your servers/compute from the underlying hardware, network virtualization allows you to abstract the network from your physical network hardware.

Instead of using a physical switch, physical router, and physical cabling to create networks, you can instead with VMware NSX create the same constructs virtually using virtual switches, virtual routers, and network encapsulation which we will get into a bit more.

Networks created by network virtualization are often referred to as overlay networks since the networks created are “overlaid” on top of the physical network irregardless of the physical network topology.

What NSX is Used For

You might wonder, aside from the “coolness” factor of being able to virtually create networks, what can you actually use this for in the real world? A lot!

Virtual networking brings about a new age for networking with features and capabilities that are either not possible or not feasible with physical networks. However, some of the major use cases with software-defined virtual networking made possible by NSX includes the following:

• Micro-segmentation – Micro-segmentation is a buzz word that has been floating around for a few years now and refers to the concept of a “zero-trust” model of networking where even internal network resources are viewed as dangerous. Micro-segmentation means you only allow the needed hosts to communicate with each other that need to communicate. All other forms of communication between network nodes is not allowed. The software-defined constructs, firewalling, and routing provided by NSX easily allows micro-segmenting network resources. Firewall rules can also be based off non-standard network constructs like vSphere objects, vSwitches, VM names, and so on.
• Connecting IP address space regardless of physical location – Due to the network encapsulation that is provided by VMware NSX, have a single IP address space exist across many different physical locations is easily achievable due to the logical network features and functionality of NSX.
• Service-defined firewall – In conjunction with VMware AppDefense, NSX has deep visibility into application behavior and can automatically create firewall rules based on application behaviors
• More efficient and performant networks – Since much of the traffic with NSX can be handled inside the ESXi kernel itself, you don’t have the traffic hairpinning behavior and other inefficient network traffic patterns to deal with. This results in more efficient and better performing networks as a result of NSX
• Application white-listing – We have already touched on this with service-defined firewall, but with AppDefense, NSX is able to work in conjunction with these features and provide the security enforcement backbone for application whitelisting
• Programmability and automation – NSX allows vSphere administrators full access to automated provisioning, management, and configuration of networks. NSX provides a full API driven interface that allows easily interacting with the API to perform any action needed that can be performed in the GUI. Network automation by way of NSX provides a much more powerful way to perform networking than in traditional network environments.
• Application Continuity – Due to the features and functionality provided by NSX in extending networking, it can interact across vCenters to provide consistent networking and firewalling across vCenter environments.

All of these use cases and many others are found as part of the uses for VMware NSX in your environment.

NSX-T vs NSX-V Components and Architecture Overview

Up until this point, we have simply been referencing “NSX”, however, VMware now is maintaining two versions of NSX – NSX-T and NSX-V. What are the similarities and differences between the two NSX versions?

NSX-V

The first NSX product has been widely known as NSX-V. The “V” in NSX-V stands for NSX-“vSphere” or NSX for vSphere. This is the case since NSX-V is the VMware NSX product that is specifically designed for use with vSphere.

In fact, without a vSphere environment with a vCenter Server, you can’t have a functioning NSX-V installation. One of the first steps in configuring an NSX-V installation is to provide the address of your vCenter Server.

NSX-V is composed of the following components:

• NSX Manager – Provides the Management plane interface for the NSX-V solution. It also provides the API interface for the NSX-V solution
• NSX Controller – Provides the control plane for the NSX-V solution and makes all logical networking possible in the NSX-V environment. Provisioned in a controller “cluster” for high-availability
• ESXi firewall VIBs – The specialized VIBs that get installed on the ESXi hosts that allow the ESXi host to perform specialized firewalling functions for NSX-V
• Transport Zone – The transport zone defines which hosts are able to participate in and have VMs connected to logical networking such as a logical switch
• VXLAN – The specialized network technology that encapsulates the networks inside packets and allowing them to be decapsulated in an entirely different location. In this way, networks can be “stretched”, “extended”, and so forth
• VTEPs – Special endpoints between which the VXLAN tunnel is established between ESXi hosts and even VXLAN capable network equipment
• Segment IDs – Specialized identifiers similar to VLANs used by VXLAN. However, in the world of VXLAN these are a 24 bit identifier providing 16 million possible VXLAN identifiers

NSX-V Network Encapsulation Using VXLAN

NSX-V makes use of VXLAN as the network encapsulation technology used to create the “overlay” of the virtual network on top of the physical network. It encapsulates the original Ethernet frames with external VXLAN, UDP, IP and Ethernet headers to allow it to traverse across the network infrastructure interconnecting the VXLAN endpoints. Encapsulating the Ethernet frame into a UDP packet increases te size of the IP packet. This results in a requirement for the MTU size to be a minimum of 1600 bytes.

NSX-V Logical Switching

Logical switching in NSX-V allows creating logical Layer 2 networks with the same ease as spinning up a new virtual machine. With logical switching, endpoints can connect to these logical segments and have connectivity to the Layer 2 network regardless of their phsyical location across the datacenter network.

Logical switching enables both virtual-to-virtual and virtual-to-physical communication in each logical network segment. Virtual to physical connectivity is provided by VXLAN to VLAN bridging. Use cases for bridging includes migrating workloads and the inability of application dependencies to change their IP addresses.

Logical switching constructs are defined by a segment ID (VXLAN ID) and provides a unique value per NSX manager.

Traffic replication modes for multi-destination traffic include:

• Multicast
• Unicast
• Hybrid

NSX-V Logical Routing

Logical routing allows connecting both virtual and physical endpoints deployed in different logical layer 2 networks. The logical routing in NSX-V is used for two purposes: interconnecting endpoints belonging to separate logical Layer 2 domains or connecting endpoints belonging to logical Layer 2 domains with devices deployed in the external Layer 3 physical infrastructure. These are typically east-west communication and north-south communication respectively.

Two different functionalities are achieved with logical routing including centralized routing and distributed routing. Centralized routing allows communication between logical network space and the external Layer 3 physical infrastructure.

Distributed routing is provided by the Distributed Logical Router (DLR). The DLR has directly connected interfaces to all hosts where VM connectivity is required.

NSX-T

NSX-T is the newest version of VMware NSX and transcends beyond the capabilities and features of NSX-V. VMware has certainly made no secret about the fact that NSX-T is going to be the version of NSX moving forward.

NSX-T is designed for today’s infrastructure challenges and hybrid environments, including cloud-centric architectures. NSX-T removes the strictly vSphere network virtualization requirement and decouples NSX from vSphere altogether.

In fact, you do not have to have a vCenter Server with NSX-T and can simply use ESXi as a transport node. You can still make use of vCenter Server in NSX-T as a compute manager, but again, it is not a requirement.

Beside being very cloud-centric in design, NSX-T was also built with the application as the key construct. This allows NSX-T to consistently apply networking and security in a consistent manner, regardless of whether or not the application is a traditional monolithic application or a newer microservices architecture.

NSX-T is composed of the following components:

• NSX-T Combined Manager Appliance – New with NSX-T 2.4, VMware combined the NSX-T Manager appliance and the NSX-T controllers into a single combined appliance. This helped to simply the architecture and deployment of NSX-T. Like in NSX-V, the Manager appliance provides the management plane of the NSX-T solution as well as API access. Instead of creating a cluster of controllers, you cluster the NSX-T manager appliance for high-availability.
• Transport nodes are the hosts running the local control plane daemons and forwarding engines implementing the NSX-T data plane
• Edge nodes are service appliances dedicated to running centralized network services that cannot be distributed to the hypervisors
• NSX Virtual Distributed Switch, or N-VDS – This is the specialized NSX-T virtual switch

NSX-T Network Encapsulation

NSX-T uses Generic Network Virtualization Encapsulation (Geneve) for the overlay encapsulation technology. Geneve is an IETF Internet Draft that takes the features and functionality of VXLAN and extends them to provide enhanced flexibility in the area of data plane extensibility.

NSX-T relies on metadata inserted in the tunnel header to identify the source TEP of an Ethernet frame. The VXLAN tunnel is not capable of housing this metadata. Geneve however allows any vendor to add its own metadata in the tunnel header with a TLV model.

NSX-T Logical Switching

NSX-T creates logical Layer 2 networks called segments. The primary component that is used by the transport nodes for logical switching is the N-VDS. The N-VDS forwards traffic between transport nodes. The N-VDS is mandatory with NSX-T for overlay and VLAN backed networking.

The N-VDS is a specialized variant of the vSphere Disributed Switch (VDS). In NSX-T virtual Layer 2 domains are referred to as segments. There are two kinds of segments with NSX-T logical layer 2 domains – VLAN backed segments, and Overlay backed segments.

A few items to remember in regards to transport nodes and zones:

• A single N-VDS can connect to multiple VLAN transport zones as long as there are no conflicting VLAN IDs presented
• The N-VDS can only connect to a single overlay transport zone but multiple VLAN transport zones
• A transport host can have multiple N-VDS switches configured, each connecting to different transport zones
• You can have multipel N-VDS, VDS, or VSS switches coexist on the same transport node
• An Edge Node can only associate with a single transport overlay zone but multiple VLAN transport zones

Like NSX-V, NSX-T is able to create logical Layer 2 networks that are decoupled from the physical network constructs and allows the mobility and flexibility needed for today’s complex hybrid topologies.

Each transport node is configured with a Tunnel End Point (TEP) assigned an IP address. These TEPs are what create the tunnels that allow logical networks to be formed between the transport nodes.

This allows the overlay traffic to have direct connectivity between transport nodes regardless of the L2 or L3 connectivity between them. Segmentation can be implemented separate from the physical network segmentation in place and without creating segmentation at the physical network layer.

N-VDS Uplinks vs pNICs

There is a new concept to wrap your mind around in NSX-T compared to NSX-V as there is a difference between the uplink and the pNICs of a host. In the NSX-T world, uplinks are logical constructs that are mapped to a single or multiple pNICs.

The uplinks are defined in uplink profiles. What are uplink profiles? The uplink profile is a template of sorts that defines how an N-VDS connects to the physical network. This includes information such as the following:

• Uplink formats
• Teaming policy
• Transport VLAN for overlay traffic
• MTU size
• Network IO Control profile

NSX-T Logical Routing

NSX-T like NSX-V has the capability to connect both virtual and physical workloads deployed in different logical Layer 2 segments. Routing traffic between these layer 2 segments is accomplished with gateways or routers. These logical entities in NSX-T can be created programmatically and in an automated fashion.

NSX-T Single Tier Routing

With single tier routing NSX-T assumes the gateway is connected to segments southbound that provide E-W routing and is then connected to physical network infrastructure providing N-S connectivity. This is referred to as a Tier-0 Gateway.

The Tier-0 Gateway has two components – Distributed Routing (DR) and Service Routing (SR).

Two-Tier Routing

NSX-T supports multi-tiered routing that separates the provider and tenant functions of routing. This concept of multi-tenancy is built into the NSX-T solution. The top-tier gateway si the Tier-0 gateway and then bottom-tier gateway is the Tier-1 gateway.

This allows both the tenant administrators and providers to have control over their services and policies. Another interesting concept is that two-tier routing is not mandatory, but it is recommended.

NSX-T vs NSX-V Differences and Similarities

Let’s describe the differences and similarities between the two versions of VMware NSX. Which do you choose?

Let’s look first at the NSX-T vs NSX-V differences and see how they contrast with each other. NSX-T is the newer of the two NSX variants. It is decoupled from vSphere. While NSX-V requires a vCenter Server connection, NSX-T does not rely on vCenter Server at all. In fact, you don’t even have to have a vCenter Server if you want to implement NSX-T with vSphere. You can connect it directly to ESXi Servers to use them as transport nodes. NSX-T can also use other hypervisors like KVM.

With NSX-T you now have a combined Manager and Controller appliance, so you deploy the combined appliance in a cluster. With NSX-V, you still deploy the NSX-V Manager and then deploy a cluster of separate controllers.

NSX-T makes use of a different type of encapsulation than NSX-V for creating logical networks. While NSX-V uses VXLAN, NSX-T makes use of the Geneve encapsulation protocol. Geneve allows for metadata to be added as needed by NSX-T. With this being the case, NSX-T uses TEPs whereas NSX-V uses VTEPs for “VXLAN”TEP.

NSX-T uses a different model of routing than NSX-V. NSX-T implements a two-tier routing approach that makes it perfect for today’s multi-tenancy needs.

NSX-T is a true multi-cloud network virtualization platform that you would choose to talk to your multiple cloud environments and move forward with creating networks between cloud environments. Whereas, NSX-V is really an on-premises solution for on-premises vSphere environments. If you want to make use of a VMware on AWS environment, you will be using NSX-T.

What are the similarites? Both versions of NSX can create logical constructs, interact with vSphere, and perform distributed routing. At this point, NSX-T has relative feature parity with NSX-V.

They both use the same license key. If you own an NSX-V license already, you are technically licensed for NSX-T as well. It will be interesting to see whether VMware changes this in the future.

Which to Choose?

There is no question that for most, if you are installing a greenfield implementation of NSX, you will want to choose NSX-T. Is there any reason at this point to choose NSX-V? The only case that could be made for greenfield installations of NSX-V at this point is if there is a vendor integration you need that does not exist for NSX-T at this point.

Otherwise, NSX-T is the way to go. VMware also has an NSX-V migration tool built into NSX-T that is getting better and better. Now, customers have a path forward from V to T.