Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Inside VMware NSX: Page 2 of 2

Migration to an overlay is a challenge that few in the vendor, research or network community have been willing to go on record to articulate. The decoupled overlay needs to eventually integrate back into the physical network.

The NSX approach uses gateways that can either be delivered in software on x86 hardware or via physical switches from partners. The partner list includes Arista, Brocade, Cumulus, Dell, HP and Juniper Networks, with Arista demoing working code at VMworld.

The gateway (both hardware and software) registers with the NSX controller and appears as an element in the NSX infrastructure. Once the physical switch connects to the NSX controller, the controller instructs the switch to build tunnels into the tunnel fabric, thus establishing connectivity between the underlay and overlay networks.

NSX has a northbound API consisting of the NSX API and two open southbound protocols, OpenFlow and OVSDB. NSX uses the Open vSwitch database protocol (OVSDB) for data plane programming and management.

NSX also exchanges VTEP and associated VM MAC addresses on those tunnels using the JSON-based OVSDB protocol. The physical switches do not build OpenFlow control channels for forwarding to the controller like the hypervisors do on the soft edge.

Where Do We Go From Here?

The launch of NSX kicked off a lot of debate between overlays and underlays. What's clear is that physical and virtual networks are not mutually exclusive. Each one depends on the other. Creating overlay networks does not exclude the importance of a solid and scalable Ethernet fabric--the physical fabric is as important as ever.

That said, I think the overlay offers certain advantages.

• Time to market with new services and feature is measured in software development lifecycles rather then silicon foundry order and merchant silicon lifecycles.

• Capacity planning of network services begins to resemble the capex model found in storage and compute. Customers can buy the capacity they need and not the capacity they think they may need at some point in the hardware lifecycle.

• Packet processing and flow table constraints are significantly reduced on 32-core servers vs. current-generation ASICs.

Of course, there are also significant issues that need to be addressed in the overlay approach.

First, decoupling forwarding awareness of the overlay with a protocol (VXLAN) that sends frames unmodified into tunnels could introduce fragility if network state becomes inconsistent from the tunnel fabric.

Today, VXLAN overlays have no awareness of the plumbing underneath. An endpoint can either reach its target or it cannot. For example, if a physical circuit is discarding frames there is no mechanism today that instructs the overlay to avoid that problematic path. That said, dynamically self-healing networks don't exist today anyways. The question is whether the overlay should provision and extract attributes to the underlay, or vice versa.

Second, regardless of the abstraction method, many underlay networks are fragile. Routing scales and bridging does not. Overlays should be complimentary to stable and uncongested physical fabrics, not a fix for unstable, congested underlays.

There are undoubtedly still plenty of details and bugs to work out, but the overlay framework is here to stay. When it comes to actually implementing SDN in the data center, decoupling the logical from the physical constraints appears the path of least resistance, particularly if an organization needs to leverage existing hardware investments.

It's evident to me that it would take a software company to push networking out of its comfort zone. Now that that's happened, it raises other questions. I wonder who blinks first for API support between Cisco and VMware? If Cisco is willing to decouple any control (particularly OVSDB) to a VMware network controller, that will be an interesting indicator of its own SDN strategy.

I also wonder if Cisco will to dust off the Citrix acquisition playbook and shed EMC for good, or stick to the arms dealer strategy in server virtualization.

[SDN will have more than technology implications; it will also affect operations, which will affect the lives of network administrators. An Interop panel will address these concerns in the session "Will SDN Make Me Homeless?" Register today!]