Some Afterthoughts on Open Network Environment, SDN and Overlay Networks
After our Open Network Environment (Cisco ONE) announcement at Cisco live!, where we unveiled our strategy for network programmability, Jim Duffy at NetworkWorld had a very interesting article that asks a key question, “What are the killer apps for software defined networks?” While SDN technology is very exciting and holds a great deal of promise, the answer to that question will ultimately determine how quickly it is adopted and by who. The consensus is that network virtualization or virtual network overlays are one of the early killer apps that software defined networks can certainly enable (when coupled with other technologies), which is exactly why Cisco made virtual overlays one of the three solution pillars of its ONE announcement. As I mentioned in my TechwiseTV video on virtual overlays, the primary use case for SDN/OpenFlow research in universities is also campus network slicing or creating virtual network partitions for test and production environments, e.g., to share a physical network. As noted in Duffy’s article, virtual overlays can be done with or without OpenFlow.
In the aftermath of a major launch, after reading the press and analyst coverage of the news, I always ask what we could have made clearer, what could have been highlighted better, or how could we have made the complexity of some of the details easier to understand. One such point that probably could have been clarified is just how “open” the Open Network Environment (what’s in a name anyway?). Specifically, regarding our Nexus 1000V virtual overlay framework, there were some comments and questions about how open and interoperable this overlay framework was, especially compared to other vendors touting programmable overlays. One financial analyst firm even stated that our overlay networks had some great advantages, but only worked with Cisco switches.
To correct that misperception, it’s important to note that virtual network overlays are designed to be independent of the underlying physical infrastructure, i.e. open and vendor agnostic. And the Nexus 1000V virtual infrastructure is no exception. The Nexus 1000V is a virtual switch that runs on any virtual server (with the right hypervisor), and runs transparent to the underlying physical network, whether there are any physical Cisco switches or not. Again, this is the same as other virtual infrastructure vendors with their own virtual switch, virtual service or virtual tunnel technology. Cisco’s virtual overlays based on the Nexus 1000V are completely agnostic to the physical infrastructure. For example, we co-developed and are actively promoting the multi-vendor VXLAN tunneling technology.
The other point that I think was frequently overlooked in all the hoopla was the importance of Layer 4-7 virtual services to the virtual overlay story, and specifically the role of vPath. vPath is a component of the Nexus 1000V virtual switch that enables the integration of virtual service nodes into virtual overlays. vPath is critical to inserting services such as security, WAN optimization or load balancing into the data paths of our virtual networks. These virtual services are again agnostic of the underlying physical infrastructure, so we don’t have to rely on partitioning firewall or application delivery controller contexts in physical appliances and stitching them into our networks with VLANs.
These virtual network services run as virtual machines on any virtual server, or the Cisco Nexus 1010 virtual services appliance, a dedicated platform that offloads application servers and gives the network team more control over network policies. VLAN stitching is no longer required to insert services into data center networks. And, in fact, vPath works seamlessly with new VXLAN tunnels to insert services into the newer, much more scalable L2/L3 overlay partitioning technology.
vPath was recently enhanced to support “service chaining”, i.e., to create custom paths through multiple services, like a firewall then an application controller, particular to the needs of each virtual application. vPath is so critical to the delivery of complete, open/interoperable virtual overlays with full L4-7 capability that one of the attendees at a panel I hosted at Cisco live asked if Cisco would eventually license its vPath technology outside the Nexus 1000V.
While on the subject of how “open” ONE is, in the interest of full disclosure, I will point out that the onePK component, consisting of API’s to Cisco network devices, really is designed only for Cisco platforms, in order to extract value from Cisco-specific capabilities. Meanwhile, ONE supports the OpenFlow standard, OpenStack API’s, and will track and include other important SDN multi-vendor technologies going forward. We understand the need of programmers to write applications that will run across many platforms without (much) modification.
In future posts, I hope to touch on other “killer app” use cases for network programmability and Cisco ONE besides virtual overlays in order to illustrate the power of this important new technology and why there’s so much enthusiasm about it so far. Drop a note in the comments section as to what you think the early SDN/network programmability killer apps are.