This article is number one of a series about the upcoming network virtualization spree, specifically the one coming from VMware.

I spent 14 to 17 October at VMworld 2013 in Barcelona, basically getting my mind blown by the futuristic possibilities of network flexibility. Things are changing for the network, flattening the entire stack, distributing network services throughout the virtual network (instead of the monolithic central hardware), lowering network costs and making it more flexible and simple to manage.

In this post, I will go over the basics of the components that are used to form the VMware NSX virtual network.

  • NSX Manager (management-plane)
  • NSX Controller (control-plane)
  • NSX Hypervisor Switches (data-plane)
  • NSX Gateways
  • Distributed Network Services

Introducing VMware NSX

 
NSX Manager

Configuring the NSX virtual network mostly goes through APIs. The idea is that cloud automation platforms (i.e. vCenter Automation Center) or self-developed platforms will leverage NSX to automate deployment of virtual networks.

The NSX Manager produces a web-based GUI for user-friendly management of the NSX virtual network. This GUI can be used next to your cloud automation platform for manual configuration and troubleshooting. You can view the status of the entire virtual network, take snapshots of the virtual network for backup, restores and archival.

Everything the NSX Manager does to manage the virtual network, goes through API calls towards the NSX Controllers.

 
NSX Controller

The NSX Controller is a very scalable control layer that takes on the functionality of the network control-plane. It is responsible for programming the Hypervisor vSwitches and Gateways with the configurations and real-time forwarding state. Whenever there’s a change in the virtual network (a VM boots, change of portgroup), the controller programs the virtual network to understand these changes.

The NSX Controller cluster typically consists of three NSX Controllers, but when those three are not enough (and can’t keep up with the workloads), up scaling is as easy as deploying a new NSX Controller virtual appliance and adding it to the NSX Cluster.

The Hypervisor vSwitches are divided between the NSX Controllers. The responsibility for a vSwitch is done through an election process, where 1 NSX Controller wins the master role and another NSX Controller wins the slave role. The other NSX Controllers within the cluster can be called upon the master for assistance in the workloads. The slave monitors the master and takes over if the master fails.

 
Hypervisor vSwitches

Virtualization today already has had vSwitches from the beginning. How else would virtual machines connect (in a scalable fashion) to the network to provide services?

Each hypervisor has a built-in, high performance and programmable virtual switch inside. In the NSX virtual network, the NSX Controllers programs these vSwitches with the current state of the network (configuration and forwarding state). If a NSX network is distributed (VMs in the same network spanned over different hosts), the controllers program the vSwitches to set up IP encapsulation tunnels (STT or VXLAN) between these hosts to extend the virtual network.

 
NSX Gateways / Edge devices

An NSX Gateway is basically the border or edge of the virtual network. It is where the virtual network communicates with the physical network that we see today. A NSX Gateway can be a virtual appliance linking traffic to VLANs, but it can also be a physical device by some vendors.

Here’s a small list of the top vendors:

  • Arista (7150S)
  • Brocade (VCS Fabric: VDX 6740 and 6740T)
  • Juniper (EX9200 & MX-series, (1))
  • Dell (S6000-series)
  • HP (announced something, no details)

To my (and many others with me) disappointment, Cisco is absent from this list. They have a “different view” and going for their own thing (Cisco ONE), which is discussed here: http://blogs.cisco.com/datacenter/limitations-of-a-software-only-approach-to-data-center-networking/ – I hope they come to their senses and allow certain types of network switches to be part of a NSX network. (Perhaps the Nexus 5ks!?)

 
Distributed Network Services

The best part about the distributed network services functionality is the services registry. This service registry makes plugins possible. So far, I’ve heard great stories from Palo Alto and TrendMicro. Those of you not familiar with any of these products (be it that Palo Alto mostly does insanely great physical firewalls), should gather some info. More on distributed network services at a later date!

 
Introductory video

Check out this awesome introductory video on NSX! (via @elsinga)

 

Other NSX Stuff:
– VMware NSX – Distributed Services

 

(1) “Juniper plans to offer VXLAN routing on the EX9200 and MX series platforms by mid-2014”  Juniper Whitepaper – Solutions for VMware NSX.



Share the wealth!