Blog

An Introduction to VMWare’s Software-Defined Networking Platform - Part 2

September 18, 2013 | Heroix Staff

In Part 1, we took a relatively non-technical look at the SDN model - so now we'll look at VMware’s NSX implementation of that model, followed by some caveats for implementing SDN.

VMware’s Allwyn Sequeira provided the following NSX implementation of the SDN model:

Management plane:

Administrators use a REST API to configure networking requirements

Control plane:

One master controller cluster delegates tasks to a control plane agent in each hypervisor.  NSX lists support for VMware 5.5, KVM, and Xen hypervisors.

Data plane:

The hypervisor Control plane agent activates the Data plane to fulfill the request from the Management plane.  The Control Data Plane interface in the ONF model correlates to “overlays” in the NSX model.

Additionally, NSX includes:

Bridging to physical networks:

This will allow you to connect to LAN devices not being administered by NSX.  Agents exist for Arista, Brocade, Cumulus, Dell, HP and Juniper network devices, and the outline states: We expect to continue to leverage partnerships with network vendors to create smart overlays that take advantage of additional capabilities in the network.

Logical Edge Services:

These services provides incoming and outgoing WAN/internet connections – e.g. load balancing, firewalls, VPNs, etc.

Given the above descriptions of SDN in general, and NSX in particular, there several considerations before jumping in to network virtualization:

1)    Do you need SDN?

A properly configured SDN application can streamline network traffic, and simplify management, but, marketing hype aside, if your network is already configured and you’re not seeing network bottlenecks, is it worth the additional cost?

2)    Does your network hardware support the necessary protocols?

Plan out the hardware needed in the infrastructure layer and edge devices and check to see if what you have meets vendor specified requirements. Keep in mind that devices used in the infrastructure layer and edge devices will have different requirements, and that NSX does not list agents for Cisco.

3)    The early adopter surcharge (or, why you should wait until at least SP1 before installing anything).

SDN was first outlined in 2005, so it is a fairly new technology.  NSX is based on Nicira, which was founded in 2007, but NSX itself is still being rolled out.  Even if all the technical bugs have been ironed out, you still need to find experienced support for implementing the specific version of SDN that you’ve selected.

4)    Pick your vendor.

If you’re a VMware shop, NSX may be the easiest solution to integrate into your existing infrastructure.  But, if you’re also a Cisco shop, maybe Cisco ONE is a better fit for your needs.  There are a lot of SDN vendors at the moment, and it’s hard to predict who will be the market leader in the next 5 or 10 years.  Selecting a vendor that uses the standardized OpenFlow protocol will make it easier to avoid vendor lock in if the vendor you choose now isn’t there in a few years.

5)    Underneath it all, it’s still a network.

As mentioned in a previous blog, switch failure was found to be the leading cause of outages in an analysis of network outages in Europe in 2012, and even a virtualized network can run into problems if the underlying hardware fails.  The SDN management interface abstracts the underlying devices, and a well designed network should be configured to failover when there is a problem – but you still need to be able to track down and replace failed hardware.  Implement a network monitoring application to keep an eye on the otherwise abstracted network layer.