Cisco Blogs


Cisco Blog > Data Center and Cloud

Some Afterthoughts on Open Network Environment, SDN and Overlay Networks

June 25, 2012
at 11:04 am PST

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.

Open Network EnvironmentIn 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.

Tags: , , , , , , , , , , , ,

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

4 Comments.


  1. When you are talking about that Cisco OnePK components are really only designed to Cisco platform, does it mean that we won’t provide OnePK components to 3rd party’s application ?

       0 likes

    • Gary Kinghorn

      No, we are making the onePK components available for third party application developers. That is the primary intent here with this announcement. What I was trying to convey is that onePK is a developer kit which includes software libraries that can be compiled into applications (among other things). Those libraries will work only on Cisco platforms, just like when you compile Windows libraries into your application, the application will not run on a Linux box, only Windows. These libraries access internals in the platform operating systems, et al., unique to Cisco, and will not work on non-Cisco routers and switches. Sorry for the confusion.

         0 likes

  2. So the killer app of SDN is “virtual network overlays”? Sorry Gary, but that doesn’t make a whole lot of sense. A Network Overlay in and of itself is just another form of networking. Sure, it can enable more flexibility, extend the diameter of VM mobility. But it’s not an application itself.

    Also, VNO and SDN don’t really have anything to do with one another. We have been doing network overlays (for instance, IPSec/GRE VPNs for VPLS tunnels) long before people started talking about SDN. You don’t need SDN to do Virt Network Overlays, and you certainly don’t need VNO to SDN-enable the network.

       0 likes

    • Gary Kinghorn

      You are right. Perhaps the point to clarify is that making virtual overlays PROGRAMMABLE is the killer app of SDN. Your GRE tunnels, etc. aren’t programmable. Having said that, you could also say that programmable overlays are not an app either. The app is what you program on top of the overlay. But if we said that programmable virtual overlays were really middleware for the network, even fewer people would get what we were talking about.

         0 likes