When I first heard the NSX announcement, I am not sure why but I got the impression that they were releasing code for network equipment itself, something akin to what Cumulus networks (http://cumulusnetworks.com/) does. Obviously that isn’t the case but I still thought there had to be more to the story. This couldn’t just be a recycling Nicira NVP overlay network with some virtual services added, right?
Essentially VMware NSX is just a virtual switching/overlay network with VMs that act as gateways (for example VXLAN VTEPs) to the rest of the network. In short it appears that VMware is doing is recycling products that exist already and repackaging them in something new. The technologies that make NSX possible are a fusion of Nicira aquired tech (NVP), VMware and Cisco jointly developed overlay technology (VXLAN). Ok, ok, GRE tunnels appear to be an new option in NSX but Microsoft has been doing this with NVGRE. I honestly cannot find anything currently that is technically possible with NSX that is not possible with Cisco 1000v, vASA, CSR, VXLAN, vWAAS, vADC, & LISP. In fact, if you were to use all of these Cisco technologies I can think of a few problems you can solve with Cisco that you cannot do with NSX. LISP being the operative protocol here that can handle mobility in a greater fashion and do so for more than just virtualized applications. For example, see section 6 of Brad Hedlund’s (@bradhedlun) blog (link below). NOTE: The title of the blog is a little misleading in my opinion, Section 6 is really the only section that is specific to Cisco. The rest could be any network and/or compute vendor really. Cliff’s (Brandon’s) notes:
“The next problem area — optimized egress routing — is ideal for a tool like OTV on the Cisco Nexus 7000 series, where the virtual network’s NSX Edge is given a consistent egress gateway network at either data center, with localized egress forwarding.”
“…optimized ingress routing. This challenge is ideal for tools such as BGP routing, or LISP on the Cisco Nexus 7000 switches and LISP capable routers; delivering inbound client traffic immediately and directly to the data center hosting the application.”
However, there are a few significant developments to consider, namely the rich vendor ecosystem VMware is bringing to the table with NSX. This is where NSX gets exciting for me. I am a cryto g33k so I understand the need for security services (aka firewalls, IPS, proxy, WAF, etc) but I also understand the pain that steering traffic to services entails. The ability to dynamically herd packets to a multitude of services from potentially multiple vendors is the draw for me. Back to the comparison with the Cisco solution, it is close to a single vendor system or in the case of vADC a very close partner. It’s not the same as the potentially more open ecosystem that NSX should bring to the table.
Tom Hollingsworth (@networkingnerd) put together a great blog post about the “end-game” for NSX in which he further discusses these services integration components (link below). Cliff’s (Brandon’s) notes:
“VMware would be much happier having direct integration between the host and the service appliance. Rather than running an agent on the ToR switch for decapsulation, VMware would rather have the agent run directly on the firewall or load balancer. That way, a particular service policy in NSX could push traffic to the appropriate device and ensure delivery and compliance without disturbing the underlying network. The physical switching plant serves as a simple transmission network, not unlike the electrical power infrastructure.”
“Eventually, VMware would rather have the virtual appliance running as a service instance that can be called rather than a full-fledged network function virtualization (NFV) device. A service plugin for NSX is much easier to configure than traffic rules pointing packets to a physical or virtual host with a routing table.”
So it’s the perfect solution right?
Sorry but there are a few drawbacks to consider with VMware NSX. In my estimation there are two major areas of concern that need to be addressed before NSX is a realistic option for most.
First, massive reliance on overlay gateways (such as VXLAN VTEP) to do the translation between the underlay and overlay networks. This will not be too much of an issue if VMware can sell organizations, primarially security and network operations teams, on using NSX for all east-west traffic thus only needing to hit gateways for north-south flows. However, the likelihood that they will get the firewall, IPS, load balancer, WAN optimization, and so on vendors in any given organization integrated under one umbrella doesn’t seem to likely too me. There is also that pesky physical one-to-one infrastructure to consider which most organizations still have a decent percentage of. It seems to me that NSX becomes exponentially less viable the lower the percentage of your virtualized workload mix.
In theory, the overhead associated with gateway translation from underlay to overlay increases exponentially by the amount of east-west traffic that is not contained entirely in the NSX overlay. There are hardware based gateways which will aid in reducing the overhead but at the same time increases infrastructure requirements. An example of this is Arista’s VTEP support on their 7150 switch. Greg Ferraro (@etherealmind) points out this issue as well as a few others in a blog discussing NSX caution signs. Cliff’s (Brandon’s) notes:
“A network overlay such as NSX makes good sense for traffic that flows from VM to VM within a data center, but there are countless use cases where traffic has to touch a physical network device–be it a switch, load balancer, firewall or other machine.”
“there aren’t yet well-defined ways for underlay networks to share state information (such as the overall health of the physical network or trouble such as delay and jitter) with the overlay.”
The other issue that many network operators seem to be hung up on is visibility and troubleshooting. I’ve seen numerous sentiments that indicate the feeling is that an overlay network is going to be more complex to troubleshoot and given the history of virtual switching being an unknown black box to most network operations teams. I think this will be an issue that will be dispelled over time as tools are developed to enhance visibility and troubleshooting capabilities. The truth is that currently there is a significant lack of tools that can tie the overlay and underlay together to give you total visibility.
Brad Hedlund – Seven reasons VMware NSX, Cisco UCS and Nexus are orders of magnitude more awesome together: http://blogs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html
Tom Hollingsworth – VMware’s NSX End Game: http://www.networkcomputing.com/data-center/vmwares-nsx-end-game/240160947
Greg Ferraro – VMware NSX Caution Signs: http://www.networkcomputing.com/data-networking-management/vmware-nsx-caution-signs/240160803
Ivan Pepelnjak – What is VMware NSX?: http://blog.ipspace.net/2013/08/what-is-vmware-nsx.html