By Guillaume Caballé - The Expert Virtual Infrastructure,
Network & Cloud Infrastructure Engineer at SQUAD
Introduction
In February 2017, VMware added the NSX-T product to its catalog: while the NSX-V Software-Defined Networking (SDN) solution was already on the market, what are the differences between these two products, and what are the advantages/applications of NSX-T? That's what we'll summarize in this article.
In the beginning, there was... NSX-V
The NSX-V solution (for "NSX for vSphere") meets the need for a virtualized network deployment platform (SDN) for VMware environments. According to them, it is the equivalent of a network hypervisor, capable of reproducing all network services from Layer 2 to Layer 7. It can only be linked to a single vSphere instance, thereby limiting its adoption in other ecosystems.
if "hypervisor" == "ESX" then NSX-V
NSX-V appears as a plugin for vSphere, where it is possible to provision a complete network infrastructure: Logical Switches, Distributed Logical Routers, Edge Firewall, Edge Services (DHCP, NAT, Load Balancing, VPN), etc.
One of the main benefits is the ability to perform vMotion (VM migration) from one ESXi server to another ESXi server without interrupting network service. This is made possible by the Distributed vSwitch component included in the NSX-V solution. It also integrates the VXLAN protocol for everything related to overlay networks.
Since version 6.1, it has improved management of multi-tenant environments, but it is still unable to ensure total network isolation between clients.
NSX-T, a competitor?
NSX-T, which stands for "NSX Transformers," stands out from its predecessor through its integration with multiple virtualization platforms: OpenStack (and KVM), as well as AWS and Azure (via the NSX Cloud offering). It also supports containerization technologies (Kubernetes, Pivotal, Openshift, Docker), providing comprehensive network architecture management for container flows.
T for "Third-Party"
Unlike NSX-V, NSX-T is a separate product, not a plugin, which seems obvious since a customer does not necessarily need to have a vSphere environment to use it. The appliance used, NSX Manager, is now a VM that can be deployed on vSphere or KVM. The NSX Edge component, previously deployed automatically on vSphere, can now be deployed on KVM or on a bare metal server.
T for "Tunneling"
In addition, it now incorporates the GENEVE protocol ( Generic Network Virtualization Encapsulation, co-written by
VMware, Microsoft, Red Hat, and Intel) instead of VXLAN, enabling more advanced metadata management and a slight improvement in performance when processing packets. There are several reasons for adopting this new protocol (still in draft form at the IETF today):
- The OpenStack Foundation relies on the OVN project and its OpenvSwitch for control plane management, and GENEVE has recently been adopted as the default tunneling protocol for OVN. OpenStack will therefore use GENEVE in its OVS implementation in the near future.
- The open-source OVN project was initially launched by the OpenvSwitch team at Nicira Networks, which was acquired by VMware in 2012: this facilitated/promoted the use of GENEVE in the NSX-T solution.
Although it is more recent, the product appears to be the predecessor of NSX-V, due to its ability to interface with third-party solutions. While it is true that it seemed less complete than NSX-V when it was released (particularly in terms of Identity Firewall and Service Insertion), with several features missing, it has since caught up with each new version, to the point where it is now just as complete.
The main changes that can be noted on NSX-T are:
- Compatibility with third-party hypervisors and public clouds
- Configuration and deployment via NSX API (Infrastructure as Code)
- the emergence of GENEVE encapsulation for transporting flows between machines
- container-to-container flow management
- multi-tenant management (multiple clients provisioned on the same SDDC)
Conclusion:
While NSX-V has a very strong affinity with vSphere, NSX-T will break free from this constraint to cater to multi-hypervisor environments.
By declining its product, VMware indicates that it is placing a strong emphasis on NSX in the future. The emergence of NSX-T demonstrates its desire to offer solutions to current SDDC issues, with the aim of attracting new customers. Furthermore, the advanced integration of new technologies (Docker, Kubernetes, Openstack, and Infrastructure as Code) demonstrates a desire for greater openness.
It will be interesting to follow the evolution of these ranges and see whether they remain separate or converge in the near future. We can already see the beginnings of an answer in version 2.4 of NSX-T, which unifies the interfaces of the two solutions so that they are similar.
