At VMworld 2013 and on the Virtualization Security Podcast there were many conversations about VMware NSX. These conversations ranged from how will we implement this new technology to security, scale, and other technical questions. In addition, NSX and what was needed to make it a reality may be the answer to a nagging security question. Brad Hedlund, from the VMware NSX team, joined the Virtualization Security Podcast to share with us some of the details around VMware NSX prior to the podcast.The podcast conversation spanned form how NSX fits into your environment through the built in security features that augment any network. Three important features came out of the conversation:
- NSX is designed to be used within large scale deployments where there is also hardware that supports NSX in use
- NSX does not really change your physical network topography by much as the layer-2 network is used to transport packets. This also implies, that if you hairpin out and back into a virtual environment to implement some external security device you will still implement this hairpin using NSX.
- NSX has inherent security via its built-in access control list functionality, which implies if the external security device is a firewall, it may not be necessary to implement bandwidth wasting hairpins.
VMware NSX provides north-south and east-west networking capabilities within an application where an application is defined as a set of virtual machines. How we define that application is really outside the scope of NSX, but is another question that was under discussion at VMworld. NSX, however, does include a service composer.
The service composer provides a mechanism to not only provide port level firewall security rules around a network (or networks) but also allows you to include identity information within the service. Which partially answers yet another pressing security question about how you can setup security rules based on identity for pool based virtual desktop usage, service access, etc. However, service composer does not seem to include the ability to create rules based on location and device, but I expect those will be coming after the initial release of the product.
In addition, NSX based virtual switches seemed to have a massive performance improvement in bits per second. Perhaps this is related to the low-latency (real-time) extensions to VMware vSphere. These extensions have the potential to improve quite a few things within the the VMware virtual environment and this appears to be one manifestation of these improvements. Line speed virtual switches is a very good thing.
Judicious use of NSX-ready hardware, of which there was plenty shown at VMworld, with the notable exception of Cisco, and VMware NSX itself will allow a software defined network (SDN) to cross hypervisor and cloud management stack boundaries. Perhaps for the first time we have a hypervisor agnostic virtual networking layer. NSX provides this capability by using the openvswitch form factor which is how Nicira added its functionality into a virtual switch in the first place. There are two distinct versions of NSX. NSX for vSphere and the more generalized NSX.
NSX for vSphere adds NSX functionality into the existing vNetwork Distributed Switch (VDS), while NSX adds a new vSwitch into vSphere (and across the network) that is based on openvswitch. These two constructs however can share the same control plane that makes up NSX.
Can NSX scale down? That is the real question as this looks to be a product for the fortune 1000 and equivalent organizations. I can see many benefits to using SDN even within all enterprises. How would you like to use NSX today? What did you discuss about NSX at VMworld?