Cisco Blogs


Cisco Blog > Data Center and Cloud

Power of Open Choice in Hypervisor Virtual Switching

July 28, 2014 at 5:00 am PST

Customers gain great value from server virtualization in the form of virtual machines (VM) and more recently Linux Containers /Dockers in data centers, clouds and branches.  By some estimates, more than 60 % of the workloads are virtualized although less than 16% of the physical servers (IDC) are virtualized (running a hypervisor).  From a networking perspective, the hypervisor virtual switch on these virtualized servers plays a critical component in all current and future data center, cloud, and branch designs and solutions

As we count down to the annual VMworld conference and reflect on the introduction of the Cisco Nexus 1000V in vSphere 4.0 six years ago, we can feel proud of what we have achieved. We have to congratulate VMware for their partnership and success in opening vSphere networking to third party vendors. It was beneficial for our joint customers, and for both companies. VMware and Cisco could be considered visionaries in this sense. Recognizing this success, the industry has followed.

Similarly we praise Microsoft as well, for having also provided an open environment for third-party virtual switches within Hyper-V, which has continued gaining market share recently.  Cisco and Microsoft (along with other industry players) are leading the industry with the latest collaboration on submitting the OpFlex control protocol to the IETF. Microsoft’s intention to enable OpFlex support in their native Hyper-V virtual switch enables standards-based interaction with the virtual switches.  Another win for customers and the industry.

In KVM and Xen environments, many organizations have looked at Open vSwitch (OVS) as an open source alternative. There is an interest in having richer networking than the standard Linux Bridge provides, or using OVS as a component for implementing SDN-based solutions like network virtualization. We think that there is an appetite for OVS on other hypervisors as well.  Cisco is also committed to contributing and improving these open source efforts.  We are active contributors in the Open Virtual Switch project and diligently working to open source our OpFlex control protocol implementation for OVS in the OpenDaylight consortium.

To recap on the thoughts from above, Table 1 provides a quick glance at the options for virtual networking from multiple vendors as of today:

Table 1:  Hypervisors and Choices in Virtual Switches

Hypervisor

Native vSwitch

3-party or OpenSource  vSwitch

vSphere

•Standard vSwitch
•Distributed Virtual Switch
•Cisco Application Virtual Switch
•IBM DVS 5000V
•HP Virtual Switch 5900V

Hyper-V

Native Hyper-v Switching
•NEC
•Broadcom

KVM

Linux Bridge(some distributions include OVS natively)
•OVS

XEN

OVS -- open source project with multiple contributions from different vendors and individuals
•OVS

 

As an IT Professional, whether you are running workloads on Red Hat KVM, Microsoft Hyper-V or VMware vSphere, it is difficult to imagine not having a choice of virtual networking. For many customers, this choice still means using the hypervisor’s native vSwitch.  For others, it is about having an open source alternative, like OVS. And in many other cases, having the option of selecting an Enterprise-grade virtual switch has been key to increasing deployments of virtualization, since it enables consistent policies and network operations between virtual machines and bare metal workloads.

As can be seen in the table above, Cisco Nexus 1000V continues to be the industry’s only multi-hypervisor virtual switching solution that delivers enterprise class functionality and features across vSphere, Hyper-V and KVM. Currently, over 10,000 customers have selected this option with Cisco Nexus 1000V in either vSphere, Hyper-V, or KVM (or a combination of them).

Cisco is fully committed to the Nexus 1000V for vSphere, Hyper-V and KVM and also the Application Virtual Switch (AVS) for Application Centric Infrastructure (ACI), in addition to our open source contributions to OVS.  Cisco has a large R&D investment in virtual switching, with a lot of talented engineers dedicated to this area, inclusive of those working on open-source contributions.

Nexus 1000V 3.0 release for vSphere is slated for August 2014 (general availability). This release addresses scale requirements of our increasing customer base, as well as an easy installation tool in the form of Cisco Virtual Switch Update Manager.   The Cisco AVS for vSphere will bring the ACI policy framework to virtual servers.  With ACI, customers will for the first time benefit from a true end-to-end virtual + physical infrastructure being managed holistically to provide visibility and optimal performance for heterogeneous hypervisors and workloads (virtual or physical).  These innovations and choices are enabled by the availability of open choices in virtual switching within hypervisors.

As we look forward to VMworld next month, we are excited to continue the collaborative work with platform vendors VMware, Microsoft, Red Hat, Canonical, and the open source community to maintain and continue development of openness and choice for our customers.  We are fully committed to this vision at Cisco.

Acknowledgement:  Juan Lage (@juanlage) contributed to this blog.

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

Introducing OpFlex – A new standards-based protocol for Application Centric Infrastructure

Continuing on its tradition of contributing and committing to open source and open standards over the last 25 years, today Cisco announced “OpFlex” – a new open standards-based protocol for Application Centric Infrastructure that has been submitted into the IETF standardization process. We believe this will accelerate multi-vendor innovation in data center and cloud networks to drive operational simplicity, lower costs and increased agility.

Why is this required?

Traditional SDN models today function on the basis of an imperative control model with a centralized controller and distributed network entities that support the lowest common denominator feature set across vendors such as bridges, ports and tunnels. As the network scales, the controller becomes a bottleneck due to the need to maintain increased state, and starts to impact performance and resiliency. Likewise, because the applications, ops and infrastructure requirements need to be translated into network configuration, it impacts agility and introduces a manual learning process, requiring app developers to describe their requirements in low-level constructs.

OpFlex1

If we contrast that with the vision of the ACI model with the Application Policy Infrastructure Controller (APIC), ACI adopts a declarative management approach. This model abstracts applications, operations and infrastructure providing simplification and agility. By distributing complexity to the edges, it also increases better scalability, and allows for resiliency – i.e. the data forwarding can still continue to happen even if there is no controller. It further provides ease of use with self-documenting policies automatically deployed or cleaned up from devices as necessary. All of these help circumvent the issues seen in traditional SDN models.

For this declarative model to work across a multi-vendor environment, to translate and map policy definition into the infrastructure, there has hitherto been no standard protocol to do that across physical/virtual switches, routers and L4-L7 network services. This vacuum has led to the development of “OpFlex” – a new open standard recently submitted to the IETF.

Who is contributing to OpFlex?

Several industry leaders and practitioners are actively involved in the standardization process. These include Microsoft, IBM, Citrix and SunGard Availability Services, in addition to Cisco.

Read More »

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