(c)iStock.com/loops7
Can VMware’s NSX finally fulfil the promise of SDN?
The first time I heard the acronym SDN was more than 10 years ago. At that time SDN was the cool way of saying “once the networking guys have racked, stacked and wired the switching and routing components we can install tools on a server and configure them through those tools from the comfort of the NOC”.
This was much more than just standard monitoring and management; we could setup whole networks and change them around, in software. But alas, this wasn’t really what we were hoping for and we would have to wait a number of years for the next advance.
The next evolutionary step was realized when VMware came out with the ability to create a virtual switch on top on their ESX hypervisor (Virtual Distributed Switching or VDS). Now we were talking slick. The ability to hang a switch without having to roll out physical hardware – amazing! Just provide some basic networking hardware at the perimeter, enough CPU to support your networking needs and start building networks. Great, but not quite good enough. Some of the questions left unanswered were:
- Modern networks consist of much more than basic switches and routers: what happened to the other components?
- How do I as a provider of cloud services keep the multiple tenant networks from affecting each other?
- How can I provide overlay networking capabilities to decouple the logical networking world from the physical?
In other words: “You promised me real virtual networking, so where is it?”
NSX-v
Enter VMware’s NSX for vSphere (NSX-v). Does it do everything? No, but it gets the cloud world a whole lot closer to the promise of SDN. The following picture provides an overview of the functions that VMware NSX-v provides:
The Virtual Distributed Switch (VDS) is the basic building block for the overall NSX-v architecture. VDS, as previously mentioned, is the original SDN function but in NSX-v the VDS has taken on a much more complete set of switching capabilities, including multi-layer switching.
Routing within NSX-v as described in VMware’s NSX Network Virtualization Design Guide: “The Logical Routing capability in the NSX platform provides customers the ability to interconnect endpoints (virtual and physical) deployed in different logical L2 networks. Once again, this is possible due to the decoupling between network infrastructure and logical networks provided by the deployment of network virtualization.” Bottom line, much of what you previously needed a physical router for, you can now do virtually.
The NSX Distributed Firewall (DFW) provides, as expected, full firewall capabilities in a virtual appliance. An even more interesting feature of DFW is micro-segmentation, or the ability to place a set of servers (1 or more VMs) in their own security zone and logically isolate them from other logical/virtual environments.
Again quoting the VMware NSX Design Guide: “In legacy environments, to provide security services to a server or set of servers, traffic from/to these servers must be redirected to a firewall using VLAN stitching method or L3 routing operations: traffic must go through this dedicated firewall in order to protect network traffic. With DFW, this is no longer needed as the firewall function is brought directly to the VM. Any traffic sent or received by this VM is systematically processed by the DFW.
“As a result, traffic protection between VMs (workload to workload) can be enforced if VMs are located on same Logical Switch (or VDS VLAN-backed port-group) or on different logical switches.”
NSX also provides a fairly impressive network load balancing service based on the NSX edge device. Some of the important supported features of NSX LB are special design for cloud applications, fully programmable via API, management through the same stack as all other NSX services, support for TCP and UDP applications, connection throttling, L7 manipulation and integration with third party LB solutions.
NSX L2 VPN service allows extending L2 connectivity across two separate data centre locations. Some of the use cases for NSX VPN Services, delivered through the NSX Edge device, include enterprise workload migration/DC consolidation, service provider tenant on-boarding, cloud bursting, and stretched application tiers.
Connectivity to the Physical Environment via NSX-v allows for the use of the physical network as a backbone, while allowing highly flexible, highly customised networking as an overlay. The use of the Virtual Extensible LAN protocol (VXLAN) enables the building of logical networks that provide L2 adjacency between workloads, without the issue and scalability concerns found with traditional layer 2 technologies.
NSX Spine and Leaf Use Case
The above diagram depicts a consolidated use case, which covers many different possibilities when using NSX-v. The architecture shown above is a modern spine and leaf construct of the type that I have recently been involved in utilising the following NSX-v features:
- Connectivity to the physical environment and the use of VXLAN
- NSX L2 VPN Services
- L2/L# Switching, Routing, Gateways
- NSX DFW and Micro-segmentation
- NSX Network Load Balancing
Conclusion
While VMware’s NSX-v represents a tremendous leap forward in software defined networking, there is still plenty to do. During a recent project, a few minor challenges arose, around how to integrate NSX into an existing physical infrastructure. The particulars involved my company’s security standards which required a physical firewall between the environment’s control plane and the user definable areas. VMware engineering was extremely helpful and the problem resolved.
As the product set matures and usage increases these issues will inevitably decrease. What we have gained is much more cloud centric and feature rich software creation, control and change capabilities. Sure, there is still work to do to reach true SDN, but now we are that much closer.