Continuing on our theme of virtual network overlays and programmable networks, today we’ll look at how to increase workload mobility over more data center and cloud resources. If server virtualization increases resource utilization and reduces costs, and data center consolidation is a good thing, then it follows that the larger the resource pool that your virtual workloads can migrate over, the more cost effective your IT operation can be. And if your mobility diameter spans multiple sites, you can obviously improve your fault tolerance as well. We call this increasing your mobility diameter, and we’ll complement what we’ve already learned about VXLAN and virtual overlays with some new technologies to seamlessly scale your diameter up. (Sounds like some sort of bizarre reverse Weight Watchers program, doesn’t it?).
As we noted in our VXLAN overview, VXLANs enable private virtual overlays over layer 3 boundaries via their MAC in UDP encapsulation and the cool way they filter MAC address broadcasts to only the right subnets. However, when you are doing full on application migration over a layer 3 boundary, VXLAN alone isn’t going to do it alone. In order to extend virtual workload mobility beyond layer 2 boundaries, Cisco came up with Overlay Transport Virtualization (OTV) that can work in conjunction with VXLAN to extend application mobility to any point the VXLAN virtual overlay can reach. And not surprisingly, the media wizards over at TechWise TV have a great video that takes all the complexity of OTV and makes it cartoonishly simple.
What is vPath? Well, if VXLANs can set up secure tunnels over a shared, multi-tenant virtual network, vPath is a feature of the Nexus 1000V virtual switch that can redirect traffic to virtual application services before the switch sends the packets down into the virtual machine. Very important stuff, but how does it do that? I find that my blog posts are more popular the less I type, and the more I embed cool TechWiseTV videos that illustrate the concept, so I’m dusting off this classic from the TWTV team on just how vPath does that with our Virtual Security Gateway (VSG). Take it away Robb…
At Cisco live last month I spent several days talking to a lot of customers about all the new enhancements to our Nexus 1000V portfolio, especially the programmable virtual network overlays that are part of the Cisco ONE framework for SDN/network programmability. While the Nexus 1000V-based virtual networks are really gaining traction (6,000+ Nexus 1000V virtual switch customers to date), I still found a lot of folks weren’t all that familiar with the concept of VXLAN, and why they are so important to building scalable cloud networks and multi-tenant data centers.
Well, not to fear, VXLAN MAN is here! Well, not really, but we have just released a great new fundamentals video on VXLAN from the creative geniuses at Techwise TV (Thanks to @JimmyRay_Purser and @robbboyd!). We’ve gotten great reviews on this so far, and I know the guys really had a fun time in creating this one.
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. Read More »
There’s an incredible amount of hype and excitement these days around Software Defined Networking (SDN), which promises to herald in a new age of flexibility, business agility and automation to our existing data center and campus networks. Since there are very few, if any, SDN networks in production environments today, though, we know there are a lot of implementation details to work out before the industry achieves the lofty benefits of network programmability. Cisco opened its kimono this week on its strategy around programmable networks (an even broader concept than what we believe the traditional definition of SDN is), called Cisco Open Network Environment. (Get Omar’s take on Cisco ONE).
If you are like a lot of people, you might think that SDN is synonymous with OpenFlow, the leading standards-based approach for SDN today. However, we are already seeing folks across the industry extending the SDN vision beyond what OpenFlow is currently envisioned to do, so we think the definition of SDN will probably evolve over the next year or so to include additional programming models and protocols. Cisco ONE, for example, includes three approaches to network programmability: 1) our own onePK set of API’s to Cisco network operation systems and devices, 2) a portfolio of agents and controllers that will support OpenFlow, among other things, and 3) our Nexus 1000V-based portfolio for building virtual network overlays.