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.
The Enterprise Strategy Group (ESG) has released this week a whitepaper and companion video looking at virtual network overlays and their use in multi-tenant environments. This comes on the heels of the ESG research brief on Cisco’s recently announced Cisco ONE set of network programming interfaces which includes Nexus 1000V-based virtual overlays.
ESG points out that virtual network overlays are important to building out multi-tenant environments like private and hybrid clouds, as well as overcoming scalability issues in those environments that have traditionally been based on VLANs. As ESG notes, and as Cisco mentioned in it’s ONE announcement, programmability of the virtual networks is what really separates them from classic overlays based on MPLS or GRE tunnels. The Nexus 1000V will achieve this programmability capability by SDN API’s such as OpenStack on top of the Nexus 1000V virtual supervisor module.
We decided to take advantage of the fine collection of smart people running around at CiscoLive in San Diego, and tape another in our Virtual Symposia series. This one was a bit different than in that we started with a Cisco-specific seed topic and we did not take live Q&A due to the logistics of being live and onsite at CiscoLive.
I think the show turned out well--we have a wide ranging discussion on not just the Cisco ONE announcement but also SDN, network programmability and implications for networking folks.
This wide-ranging discussion touched on a number of topics:
Contrasting Cisco’s ONE strategy with SDN and OpenFlow in general
APIs, OpenFlow, and XML
What will people do with SDN in the future?
Distributed and autonomous versus centralized
Standards: IEEE vs. IETF, de facto and interoperability
As I noted last week, we will be hosting Virtual Symposia #3 (more on network programmability) and #4 (VM networking) later this month. I should have the registration links up tomorrow. We have a killer panel coming together and we will once again have most of the show dedicated to audience Q&A, so I hope you can join us for those.
So, if you are a networking geek of any sort, you should be listening to PacketPushers--for both the education and the sheer entertainment value. This year, we tried something a little different with the PacketPushers team and had them join us onsite at CiscoLive. Below are six of the podcasts they produced for us:
PQ Show 002 – Cisco Cloud Services Router With Prashant Shenoy
In the wake of our Open Network Environment (Cisco ONE) announcements, we are continuing our series on software defined networking (SDN) use cases, this time focusing on the primary use case for OpenFlow and universities, campus network slicing. If interested, a more detailed solution brief on this scenario and the Cisco SDN OpenFlow controller can be found here. And check out our demo video below.
University campus networks offer an increasingly wide array of networking services to one of the broadest user bases of any “enterprise.” Some universities have medical or high-security facilities and must maintain regulatory compliance accordingly. Student networking services vary depending on whether they are on or off campus, and in almost all cases students and faculty bring their own devices. Administration offices must also be able to manage the day-to-day activities of the university. Often event management must include the rapid provisioning of point-of-sale terminal support and back-end payment reconciliation. And faculty must have both data and video access within the university campus, across campuses, and further out to other universities.
As a result, the ability to partition networks (called “slicing”) based on SDN has risen in popularity. Although slicing is being performed today on isolated networks, the need to perform it on production networks is now becoming a priority. Cisco controllers and agents, as part of the Cisco Open Network Environment for network programmability, are aimed at addressing this need.
Much of the early research and collaboration between universities on OpenFlow and SDN has been driven by the adoption of National Science Foundation (NSF) projects such as GENI, an open, collaborative research environment to explore networking at scale.
One of the basic premises of SDN is that the abstraction of control plane management, out of each network device and into a centralized “controller,” can create high business agility through automation with relatively lower OpEx and low risk. SDN is a natural fit for the class of requests universities need to service.
One of the primary components to the emergence of SDN on campuses has been the ability to create logically isolated networks and allow them to be partitioned and programmed using slicing. In SDN, this is facilitated with an abstraction layer in the network device called a flowvisor. Today, many universities use flowvisors within their isolated networks in conjunction with SDN controllers to manage their slicing requirements. In many cases these slicing activities are still performed off the campus backbone, as the software used to implement both the operating systems and slicing functions does not provide the policy management consistency required for production network applications.
