Cisco Application Virtual Switch (AVS), a virtual member of the Cisco’s Application Centric Infrastructure (ACI) family has seen increasing interest from customers who want to enforce application centric policies all the way to the virtual edge of the data center.
Cisco AVS is a derivative of the Nexus 1000V virtual switch, which is the market leading 3rd party virtual switch in the industry. Nexus 1000V has accumulated more than 10,000 customers and has been deployed in large-scale service providers to large enterprises. Recently Cisco announced Nexus 1000V support for vSphere 6.0 releases. VMware has also announced to continue supporting Cisco Nexus 1000V in vSphere 6.0 and later releases.
VMware has supported and re-sold Nexus 1000V since we jointly launched the product. Recently (Feb 2nd 2015) VMware has announced that they will stop re-selling product/post-sales support for Nexus 1000V. Cisco will continue to sell and support Nexus 1000V for all customers.
Cisco AVS uses exactly the same vSphere APIs that the Nexus 1000V uses. Cisco AVS has always been supported by Cisco since the launch of ACI and will continue to be supported by Cisco. Currently, ACI with Cisco AVS is supported in vSphere 5.1 and vSphere 5.5 releases. With the latest release 5.2(1)SV3(1.5), Cisco AVS supports the Data Center Micro Segmentation delivered by the ACI. We plan to release vSphere 6.0 support for ACI with Cisco AVS later in second half of CY 2015. Cisco is committed to deliver on the strong customer interest in Cisco AVS and have multiple successful production deployments of Cisco AVS with ACI across our customer install base.
Customers who use either Cisco Nexus 1000V or Cisco AVS are assured that Cisco will continue to innovate and support these products via Cisco Support channel.
To ease adoption, Cisco AVS product and support is included as part of the Cisco ACI product and support agreement. No additional services or products need to be purchased.
Tags: #CiscoACI, ACI, application vi, AVS, Nexus 1000v, VMware vSphere, vsphere 6
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
3-party or OpenSource vSwitch
•Distributed Virtual Switch
•Cisco Application Virtual Switch
•IBM DVS 5000V
•HP Virtual Switch 5900V
|Native Hyper-v Switching
|Linux Bridge(some distributions include OVS natively)
|OVS – open source project with multiple contributions from different vendors and individuals
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: application centric infrastructure, Application Virtual Switch, AVS, Canonical, KVM, Microsoft Hyper-V, Nexus1000V, open source, opendaylight, OpFlex, opflex protocol, OVS, RedHat, VMware vSphere, vmworld, vmworld 2014
There’s been a lot of news and momentum surrounding VXLAN technology in the last several months, and there is no doubt that VXLAN is becoming a more strategic and pervasive technology across cloud networks as a result. When we rolled out VXLAN about two years ago with the first commercial implementation as part of our Nexus 1000V virtual switch, VXLAN was solely a virtual networking construct and had real constraints in how it could be extended to physical networks and devices. It was also restricted to overlay networks using our Nexus 1000V switch (or other virtual switches supporting the VXLAN overlay protocol).
Now, however, VXLAN is being supported broadly across Cisco networking platforms and devices, across multiple Cisco fabric architectures, and we are even seeing broader support from other vendor ecosystems and non-Cisco switching platforms. Cisco is continuing to expand its support for VXLAN onto the new Nexus 5600 Series switches, as well as Nexus 7700 Series using the F3 line card.
For those of you not fully up to speed on VXLAN, VXLAN stands for Virtual eXtensible Local Area Network, and started out as vastly more scalable Layer 2 LAN and tenant isolation construct for data center and cloud networks. Where cloud networks were running out of only 4000+ VLAN IDs to segment application networks, VXLAN gave them over 16 Million logical network segments.
Read More »
Tags: ACI, application centric infrastructure, Application Virtual Switch, AVS, Nexus 1000v, Nexus 3000, Nexus 5600, Nexus 7700, Nexus 9000, virtual switch, VXLAN
Following our launch of the Cisco Application Centric Infrastructure (ACI), we continue with our series exploring in more detail key aspects of the ACI policy model and partner ecosystem. In Part 1 of my series on ACI, we looked at why application policies were an ideal model to build infrastructure automation around, and how application policies are better suited to mirror business objectives and requirements than traditional IT infrastructure policies. The key benefits for customers end up being vastly greater degrees of automation, process improvement and business agility.
In Part 2, we looked into one example of the difficulty in deploying and managing applications and the level of complexity that must be overcome to truly automate application-oriented tasks: application-specific network services and security policies (as well as a separate post on the partner ecosystem for application services and security solutions that support the ACI model).
In this Part 3, we’ll look at one of the components of the ACI fabric that we also announced, the Application Virtual Switch (AVS). We’ve received a number of follow-on questions in this area that can be addressed here. By way of introduction, I had the chance to sit down with AVS and Nexus 1000V Director of Product Management, Balaji Sivasubramanian to talk about the new AVS and how it relates to both ACI and the Nexus 1000V virtual switch (Balaji also had a related post on AVS):
But wait, there’s more… Read More »
Tags: ACI, APIC, application centric infrastructure, Application Policy Infrastructure Controller, Application Virtual Switch, AVS, Nexus 1000v, Nexus 9000
Cisco has been the leader in virtual networking since the introduction of Nexus 1000V virtual switch more than 5 years ago. Now it is time to make the virtual network more application aware. With the introduction of the Application Centric Infrastructure (ACI), we are pleased to introduce the Application Virtual Switch (AVS), the virtual network edge of the Cisco ACI -enabled network that includes the Nexus 9000 series of switches.
In the ACI architecture, applications drive networking behavior, not the other way around. Pre-defined application requirements and descriptions (“policy templates”) automate the provisioning of the network – virtual and physical, application services, security policies, tenant subnets and workload placement. Automating the provisioning of the complete application network reduces IT costs, reduces errors, accelerates deployment and makes the business more agile.
Application Virtual Switches are the purpose-built, hypervisor-resident virtual network edge switches designed for the ACI fabric. They provide consistent virtual networking across multiple hypervisors to simplify network operations and provide consistency with the physical infrastructure.
- AVS is robustly integrated into the ACI architecture and supports Application Network Profile (ANP) enforcement at the virtual host layer consistent with the Nexus 9000 series physical switches.
- AVS is managed centrally along with rest of the ACI fabric components through the Application Policy Infrastructure Controller (APIC) and provides advanced telemetry features to allow end-to-end visibility and troubleshooting capabilities across both virtual and physical devices, .
- AVS enables optimal traffic steering between virtual and physical layers of the fabric to maximize performance and resource utilization. For example, if the web and app tier are located on the same host, AVS can route traffic or apply security policies between these end point groups within the hypervisor itself. On the other hand, if the database is a bare metal workload that is attached to the physical Nexus 9000, the application policy is consistently applied at the physical Nexus 9000 top of rack switches instead.
Application Centric Infrastructure with Application Virtual Switch
ACI eliminates the operational complexity of differences in managing virtualized environments vs. bare metal or legacy environments. It provides a consistent operational model across both AVS and Nexus 9000 respectively. ACI also allows for flexibility of placement of application workloads based on application requirements. Watch this short video.
Read More »
Tags: application centric infrastructure, Application Policy Infrastructure Controller, Application Virtual Switch, AVS, Nexus 9000, Nexus1000V