VMware NSX-V vs NSX-T Comparison

Table of Contents

1. Overview of VMware NSX Technology
2. Micro-Segmentation
3. Multi-Cloud Networking
4. Network Automation
5. Cloud-Native Apps
6. NSX Management Control and Data Planes
7. NSX Components
8. VMware NSX-V vs NSX-T Differences
9. Deployment
10. Comparing NSX-V vs NSX-T Licensing
11. VXLAN vs GENEVE
12. NSX-T N-VDS Switch – New Switch with NSX-T
13. Layer 2 Logical Switching and Bridging – NSX-V vs NSX-T
14. NSX-T Logical Switch and L2 Bridge
15. Routing Comparison – NSX-V vs NSX-T
16. NSX-V vs NSX-T Security
17. Wrapping Up

One of the most exciting technology spaces in the virtualization world today is software-defined network (SDN). Software-defined networking or SDN is literally transitioning the landscape of networking as we know it and producing a world where the physical network is simply an underlay environment on top of which the virtual network packets are being switched and routed.

VMware’s NSX is a software-defined networking solution that delivers virtualized networking and security entirely in software.

It’s the premier enterprise datacenter SDN solution on the market today that allows businesses to modernize their enterprise data center by allowing agile controls and technical solutions for today’s fast paced networking needs. Today with VMware NSX there are two variants of the product to note. These are NSX-V and NSX-T.

In this post, we will take a look at the following:

• What are the differences between VMware NSX-V & NSX-T?
• What different goals do they achieve?
• How are they implemented?
• Why would you choose one over the other solution?

Overview of VMware NSX Technology

VMware’s NSX is a powerful software-defined networking solution that allows businesses today to solve the very complex problems surrounding security, automation, and agility in today’s hybrid cloud data centers.

There are four main benefits to VMware NSX in the data center for modernizing networking.

• Micro-segmentation
• Multi-Cloud Networking
• Network Automation
• Cloud-Native Apps

Since VMware NSX is a software based solution, it touts all the benefits and agility of deploying changes, configuration, new designs and architecture in code as these are defined in software constructs and not hardware. The traditional days of making network changes that involved physical hardware involve processes that are tedious, cumbersome, time consuming, and often involve network teams and other change control requirements that present tremendous complexity to even simple changes to the network infrastructure being made.

With software-defined solutions such as NSX, these traditional hurdles are no longer a challenge since the changes can be implemented or made in the software constructs. NSX represents a revolutionary shift in the way businesses are able to control network traffic in their software-defined data center infrastructure.

With network virtualization using VMware NSX, you have the functional equivalent of a network hypervisor that allows virtually provisioning a complete set of Layer 2 through Layer 7 networking services. This includes switching, routing, access control, firewalling, QoS and doing all of this in software.

Micro-Segmentation

Micro-segmentation helps organizations to implement what is often referred to as the “zero-trust” model of security where all network endpoints are viewed as dangerous. In traditional network security, you have an edge firewall that separates what was traditionally thought of as “untrusted” zones such as the Internet and then “trusted” zones such as your LAN.

However, what if an attacker successfully infiltrates inside the LAN?
With the traditional network security mindset, they would have free reign over all “trusted” network endpoints that exist in the LAN.

With micro-segmentation, the network endpoint is not trusted and is only allowed to communicate with the specific network endpoints that you define. Whether your goal is to lock down critical applications or created a logical DMZ, you can do that with NSX. Additionally, you can reduce the attack surface of today’s modern infrastructure such as virtual desktop environments.

Micro-segmentation with VMware NSX allows using constructs to build network security policy that are simply not possible with traditional network security. These constructs include building network security policy using things such as Active Directory object names, virtual machine names, user accounts stored in Active Directory, operating system types, and so on.

Multi-Cloud Networking

Businesses are now utilizing hybrid infrastructure that spans from on-premises to the public cloud and even to multiple public clouds.

How do they scale and extend network traffic effectively into the cloud without relinquishing their security controls and other network policies?

This is where NSX really shines.

It helps to bring consistency across different data center sites and allows extending network access across data centers and to the public cloud where businesses can deploy their applications and move them seamlessly using virtualized infrastructure independently of geographic boundaries.

Network Automation

Keeping up with the demands of today’s enterprise data centers requires that you make use of automation. Automation allows streamlining IT operations which includes provisioning, configuration, and monitoring. VMware NSX is a fully software-defined solution which means that it is fully accessible, configurable, and manageable from programmatic API interfaces.

All of the virtualized networking and security functions contained in NSX can be automated which also helps to reduce manual, error-prone tasks. Lifecycle automation helps you to ensure that policy is enforced and aligned with business requirements and helps to eliminate the bottlenecks of manually configuring and operationalizing your network infrastructure.

This provides consistency and security across your landscape wherever workloads exist, either on-premises or in the public cloud or private cloud. Overall, this helps to make business processes more agile and helps development move at faster speeds.

By using PowerCLI and other scripting and configuration management tools such as vRealize Automation, NSX can be automated and provisioned in a fluid, software-defined way.

Cloud-Native Apps

Today businesses are building cloud-native apps inside of modern infrastructure technologies such as containers. NSX allows businesses to apply consistent network policies and rules no matter where the workload exists or what platform it is running on. Cloud-native apps, enabled by NSX can benefit from the same networking benefits such as micro-segmentation.

NSX Management Control and Data Planes

In the architecture of NSX, there are three different planes of operation: management, control, and data.

There are various software components, agents, processes, and modules that reside on three types of nodes – including the NSX Manager and transport nodes, that each fall into one of the above-integrated planes which we will define below.

• Every node hosts a management plane agent
• NSX Manager nodes host the API services and the cluster daemons found in the management plane
• NSX Controller nodes host the central control plane cluster daemons
• Transport nodes host the local control plane daemons and forwarding engines

NSX Components

There are various components that make up the NSX infrastructure. These are:

• NSX Manager – The NSX Manager provides access to the management plane of the NSX solution and also provides access to the APIs that can be interacted with from a programmatic standpoint. The NSX Manager is deployed as a virtual appliance in both the NSX-V and NSX-T platforms
  • NSX-T 2.4 introduced the combined appliance that contains both the NSX Manager and NSX Controller
• NSX Controller – The NSX Controller is NSX infrastructure component that creates the overlay networks using the network encapsulation protocol to carry virtual network traffic across the various segments of the physical network
  • With NSX-T 2.4 the controller is combined with the NSX Manager
• NSX Edge – The NSX Edge provides the routing and gateway services for the NSX infrastructure as well as DHCP, NAT, HA, and load balancers

VMware NSX-V vs NSX-T Differences

If you have been keeping up with VMware NSX over the past few years, you realize the original VMware NSX solution was called NSX-V.

NSX-V is the original software-defined networking solution based on the acquisition of Nicira by VMware back in 2012.

NSX-V is built around the VMware vSphere ecosystem and includes the requirements that you would expect in VMware vSphere such as having a vCenter Server and ESXi hosts. The VMware NSX-V solution is now branded NSX-V Data Center and is the older of the two technologies as it spawned from the vSphere product line.

NSX-T is the next-generation software-defined networking solution that provides the next evolution of software-defined networking from VMware. The “T” in NSX-T is for “Transformers”. If you are currently looking at a new NSX deployment for a greenfield installation, it makes total sense to be looking at NSX-T, since as we will describe later, the writing is on the wall that NSX-V will simply be folded into the functionality that NSX-T provides.

NSX-T is now branded NSX-T Data Center. The major difference with NSX-T and NSX-V is that NSX-T is “unlocked” from VMware vSphere. In other words, you don’t have to have a vCenter Server in order to deploy NSX-T. This allows VMware to move into new territory in the cloud and more hybrid infrastructure. Currently, NSX-T contains support for different hypervisors and environments.

NSX-T focuses on supporting cloud-native applications, bare metal workloads, multi-hypervisor environments, public clouds and multi-cloud environments. In fact, NSX-T is supported on ESXi, KVM, bare-metal servers, Kubernetes, OpenShift, AWS and Azure.

Recently, Amazon announced the Amazon Outposts product which will soon be available for provisioning in the data center. A little known fact with Amazon Outposts is that even the Amazon “only” solution that doesn’t offer an on-premises version of VMware Cloud on AWS, has networking that is powered by VMware NSX-T.

The NSX-T 2.4 release was a milestone release of NSX-T. Until the release of 2.4, NSX-V has always had more features than NSX-T which was always a point of disparity between the two and left most looking at NSX-V. However, everything changed with NSX-T Data Center 2.4. It signified the major release of NSX-T that everyone was waiting on. The release that achieved relative feature parity with NSX-V was finally here.

Now that NSX-T 2.4 has been released, the way forward is NSX-T Data Center. As mentioned above, you should be looking at NSX-T for greenfield deployments. NSX-T represents the SDN technology of tomorrow in that it is cloud focused and not tied to a specific hypervisor or platform.

NSX-V is a powerful SDN solution from VMware but it represents the technology of today and yesterday and not that of tomorrow. Tomorrow’s workloads are going to be cloud focused and hypervisor agnostic. VMware realizes this and is strategically engineering NSX-T to be the answer to the software-defined networking challenges of the on-premises, hybrid, and multi-cloud environments.

Deployment

As a high-level comparison with deploying either NSX-V or NSX-T in a vSphere environment, the process looks very similar. With each NSX solution, the deployment begins with deploying the NSX Manager, however, the similarities start to end there.

• NSX-V requires that you register the NSX Manager with VMware vCenter
• NSX-T allows you to point the NSX-T solution to VMware vCenter to register your Transport Nodes or ESXi hosts
• NSX-V Manager is a standalone solution which requires additional NSX Controllers to be deployed
• NSX-T Manager with NSX-T 2.4 is a combined appliance that includes both the NSX Manager and Controller functionality all in the same virtual appliance
• NSX-T has additional configuration of the N-VDS that must be completed, including uplink profiles, etc

Comparing NSX-V vs NSX-T Licensing

Interestingly, the licensing for NSX-V and NSX-T are the exact same license. So, if you have the license key for NSX-V, you can plug this license key into NSX-T and it will work. At least at this point, VMware has not differentiated the solutions from a licensing perspective. This also includes the licensed editions of each product.

VXLAN vs GENEVE

When looking at NSX-V vs NSX-T under the hood with the encapsulation that is performed, NSX-V uses the more traditional VXLAN encapsulation while NSX-T has adopted a newer encapsulation protocol known as GENEVE.

VXLAN or Virtual Extensible LAN is a virtual network encapsulation protocol that helps to solve many of the limitations and challenges associated with traditional Virtual LANs or VLANs. VXLANs use an encapsulation that allows encapsulating Layer 2 frames inside UDP datagrams that allow logically forming networks across physical network boundaries or segments.

The virtual network that is created with VXLAN is known as a VXLAN tunnel and are terminated either in software or by actual physical switch ports that understand and can communicate with VXLAN enabled networks. These termination points are defined as VXLAN tunnel endpoints or VTEPs.

Traditional VLANs have the limitation of some 4000 network segments that can be created to segment traffic. In today’s cloud centric networking environments, you may well run into limitations with this number. However, with VXLAN, the header includes a 24-bit field that is reserved for the VXLAN network identifier (VNI) that uniquely identifies the VXLAN. This allows some 16 million or so unique segments to be created. This is well beyond traditional VLANs.

Using the VNI constructs that are terminated with the VXLAN VTEP, you can create “logical” networks that span across the physical infrastructure and that behave in much the same way as a traditional layer 2 VLAN. This overlay network flows over the top of the physical underlay.

VXLAN requires an MTU value of 1600 or higher to accommodate the extra room for the encapsulation header

What is GENEVE?

GENEVE is a virtual network encapsulation protocol with the expressed goal to define an encapsulation data format only. It does not include any information or specification for the control plane. The data format of the GENEVE encapsulation allows it to be as flexible and extensible as possible. GENEVE has been engineered to potentially carry more than just the virtual network identifier information.

There is no doubt that new requirements and needs will be tossed upon the encapsulation protocol to carry. Having the flexibility to be extensible and insert metadata as TLV (Type, Length, Value) fields allows GENEVE to be engineered to evolve over time depending on the needs from a network standpoint.

GENEVE can be encapsulated and transmitted via standard networking equipment. It can make use of either unicast or multicast addressing.

The GENEVE encapsulation protocol has been shown to perform better than VXLAN, having better throughput and less CPU utilization, even compared to VXLAN offload capable hardware. VMware recommends an MTU of 1600 to account for the encapsulation header.

NSX-T N-VDS Switch – New Switch with NSX-T

The new VMware NSX-T Virtual Distributed Switch is the newest type of switch in the line of VMware virtual switches. It is an NSX-T technology. Compared to NSX-V that makes use of the vSphere Distributed Switch, the N-VDS is decoupled from VMware vCenter and is a host switch created on the transport nodes such as ESXi.

It does tout the following characteristics:

• Decoupled from vCenter Server
• Cross-platform support
• Different Uplink Profiles
• VLAN and Overlay Logical Switches

NSX-T for Data Center offers a tremendous advantage over NSX-V for Data Center for multi-cloud environments in that it is decoupled from vCenter Server. This means the N-VDS virtual switch is also not reliant on vCenter Server for configuration.

This decoupling from VMware vCenter Server allows for cross-platform support with the N-VDS virtual switch. This means the N-VDS switch can be used outside of VMware vSphere environments.

Characteristics of N-VDS virtual switches

A few notables about N-VDS virtual switches include:

• pnics are physical ports on the host
• pnics can be bundled to form a link aggregation (LAG)
• uplinks are logical interfaces of an N-VDS
• uplinks are assigned pnics or LAGs
• Any combination is possible on ESXi (KVM hosts can only define one LAG)

The N-VDS Teaming Policy:

• The teaming policy defines uplink redundancy and failover model
• Two remaining policies in NSX-T – Failover Order and Source Port (only in ESXi)
• Load based teaming and IP hash teaming are not available with N-VDS virtual switches
• The teaming policy defines uplink redundancy and failover model
• Two remaining policies in NSX-T – Failover Order and Source Port (only in ESXi)
• Load based teaming and IP hash teaming are not available with N-VDS virtual switches

The N-VDS Uplink Profile is applied to a Transport Node when it joins a Transport Zone. The Uplink Profile defines the transport Zone attachment and specifies:

• The teaming policy
• The uplinks definition (LAGs/pnics)
• MTU
• Overlay transport VLAN ID
• Transport Zones supports multiple uplink profiles

A new type of virtual switch mode has been introduced with N-VDS. Enhanced Data Path N-VDS – Data Plane Development Kit (DPDK)-based N-VDS

Two N-VDS modes available: Standard or Enhanced Datapath. N-VDS Enhanced Data Path is optimized for networking centric workloads. The Enhanced Data Path N-VDS makes sense when the VM requires:

• High packet rate
• Low latency, low jitter

A use case for the Enhanced Data Path N-VDS would be for Network Functions Virtualization. The Enhanced Data Path N-VDS includes the following:

• Adds flow-cache to N-VDS
• Polling-based, dedicated CPU cores
• Large pre-allocated buffers

Layer 2 Logical Switching and Bridging – NSX-V vs NSX-T

The heart of the NSX solution when it comes to software-defined networking is to have the ability to have logical constructs that are similar to the physical networks that have traditionally moved packets for production workloads.

As discussed, the overlay network that is created by the encapsulation mechanisms used by both NSX-V and NSX-T allow creating logical segments that mirror traditional VLANs and allow other flexibility in handling your traffic in the overlay network.

NSX-V Logical Switch and L2 Bridging

With NSX-V, the logical switch is distributed and can span across compute clusters. This allows functionality such as vMotioning virtual machines across the boundaries of physical VLANs. The MAC/FIB tables are contained in the Logical software table.

The logical switch is mapped to a specific VXLAN which encapsulates VM traffic and sends it over the underlying physical network. With NSX-V, the NSX controller is the central control point for the logical switch and keeps the information for all objects utilizing the logical switch.

The logical switch in NSX-V allows creating the Layer 2 Bridge between a logical switch and a physical VLAN. This can provide many interesting use cases including physical to virtual or V2V migration, connecting appliances that cannot be virtualized to the NSX infrastructure as well as physical routers, firewalls, etc.

L2 Bridges can make use of Layer 3 gateways that even exist in the physical network using the L2 bridge. A Layer 2 bridge maps to a single physical VLAN. You can run multiple L2 bridges inside of NSX-V. You have the requirement with NSX-V to have the VLAN port group and VXLAN logical switch on the same vSphere Distributed Switch (VDS).

NSX-T Logical Switch and L2 Bridge

The NSX-T Logical Switch is formed using GENEVE encapsulation instead of VXLAN and creates the similar overlay functionality of the Logical Switch used in NSX-V created with VXLAN. The logical switch is found under the Advanced Networking & Security functionality of NSX-T and provides a logical switch that allows for common switch traffic functionality such as BUM traffic.

The NSX-T Layer 2 bridge solution involves ESXi bridge clusters, bridge endpoints, and bridge nodes. An ESXi bridge cluster provides high-availability of bridge nodes. The bridge node such as ESXi in this case, is what actually does the bridging. The NSX-T logical switch used for bridging between a virtual and physical network has a VLAN ID. The bridge endpoint identifies the attributes of the bridge such as a bridge cluster ID and VLAN ID.

Routing Comparison – NSX-V vs NSX-T

Both NSX-V and NSX-T provide dynamic routing that allows forwarding information between Layer 2 segments. NSX allows providing a much more distributed and efficient routing mechanism than traditional routers when it comes to virtual environments in such a way that virtual machines are able to communicate with less routing cost or unnecessary hops. This includes both east/west and north/south traffic.

NSX-V Routing

With NSX-V, the NSX Edge provides network edge security and gateway services that are able to isolate virtualized networks. The Edge can be installed as either a logical (distributed) router or as an edge services gateway.

• The NSX-V Distributed Logical router provides the east/west distributed routing with tenant IP address space and isolation services. If VMs that are on different subnets reside on the same host need to communicate, the traffic does not have to traverse out of the host to a traditional routed interface and then back to the VM that is within the same host. Instead, with the DLR, the VMs are able to communicate without these unneeded hops
• NSX-V Edge Services Gateway connects isolated networks to shared uplinks by providing the gateway services needed to make this communication happen such as DHCP, VPN, NAT, dynamic routing, and load balancing

NSX-T Routing

Routing in NSX-T has been engineered from the ground up for today’s cloud and multi-cloud with multi-tenancy use cases which require supporting multi-tiered routing. The multi-tiered routing model provides the separation needed between provider router functions and tenant router functions. This multi-tenancy usability is built right into the NSX-T platform.

• Tier 0 Logical Router – performs the functions of a tier-0 logical router. It processes traffic between the logical and physical networks
• Tier 1 Logical Router – performs the functions of a tier-1 logical router. Its downlink connections connect to Logical switches and the uplink connections connect to tier-0 logical routers

It is interesting to note with NSX-T that it is not mandatory to run multi-tiered routing. A single Tier-0 Logical Router can be connected to the physical infrastructure for northbound traffic and then connect directly to logical switches southbound. This allows distributed east/west routing in the kernel and centralized north/south routing as well.

Using the multi-tiered routing approach benefits you in the following scenarios:

• You have multiple tenants that need isolation
• Delegated administration between the provider admin and tenant admin – Provider admins control Tier-0 logical routers and tenant admins control Tier-1 logical routers
• You are leveraging Openstack, Kubernetes, Pivotal Cloud Foundry

When a user creates a Tier-0 or Tier-1 logical router, the distributed logical router instance is created on all transport nodes. When centralized services such as NAT is configured an SR is created on the Edge Node.

NSX-V vs NSX-T Layer 2 and Routing comparison of equivalent technologies:

NSX-V vs NSX-T Security

One of the primary values to your business provided by the NSX software-defined networking solution is security.

Prior to NSX-T 2.4, a milestone release in NSX-T, there was a disparity between the security features found in NSX-T when compared to NSX-V, with the advantage going to NSX-V. NSX-V had many more security features and functionality than NSX-T.

With NSX-T 2.4, it now supports features that up until this release, were only included with NSX-V:

• Layer 7 application awareness
• Identity-based firewalling
• Agentless endpoint protection via third-party integrations
• Service insertion to build a security posture built around application context

With the security features parity with NSX-V, this helps NSX-T be a viable platform for NSX-V customers to look to for their next phase of software-defined networking and security.

With the security feature parity and a new level of analytics and visualization with the new NSX-T management dashboard and user interface and support for Splunk and VMware vRealize Log Insight, customers can now have better security with NSX-T than hardware-based firewalls.

In the NSX-V vs. NSX-T fight, security features are no longer an advantage of NSX-V and is a new win on the side of NSX-T in favor of VMware’s new premier software-defined networking and security platform. If you weigh into the mix the cloud integration that NSX-T has when compared to NSX-V which lacks the tight multi-cloud features of NSX-T, the new NSX-T version 2.4 and beyond is the new standard.

Wrapping Up

Software-defined networking and security provided by VMware’s NSX solution via NSX-V and NSX-T provides a powerful network virtualization platform.

VMware NSX is basically a network “hypervisor” for your virtual networks that allows extending and architecting your virtual network infrastructure in line with business needs. It allows having the tools needed to solve the challenges faced in terms of security and compliance, such as micro-segmentation.

NSX-V and NSX-T are both great solutions for software-defined networking needs. However, while solving many of the same challenges, NSX-V and NSX-T share some important differences. While NSX-V is the premier software-defined solution that has brought vSphere customers to where they are today with their SDN solution, NSX-T is the way forward. Starting with NSX-T 2.4, VMware has made a definite statement in bringing NSX-T up to feature parity with NSX-V in the main areas of functionality such as security.

By utilizing NSX solutions from VMware, customers have the tools needed to move their data regardless of the underlying physical network. They can do this in a way that enforces proper security policies and compliance regulations. Even with SDN solutions, customers must protect their business-critical data residing in their virtual infrastructure.

Vembu BDR Suite is a premier VMware backup and replication solution that allows integrating your VMware backup and replication solution with the capabilities offered by VMware NSX so that your data not only flows across the network as you want, but is also securely protected.

Download the Vembu BDR Suite fully-featured trial version to see how Vembu BDR Suite can protect your environment.

Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.