- Bronze, 100 points or more
Events Top Contributors,
Editor’s Note: TS Newsletter readers get a 35% discount on Akhil Behl's book CCIE Collaboration Quick Reference. See discount code at the end of this article.
Cisco Collaboration (aka Cisco Unified Communications) solutions have come a long way since the conception of IP Telephony. With advancements in technology and the need to reduce economic and environmental impact, virtualization is well on way to become the core of all major technologies including Unified Communications. Cisco Collaboration solutions are now fully supported on Cisco UCS, with backend Nexus, storage, and Fibre Channel over Ethernet (FCoE) based systems complementing the next gen solutions.
However, with inclusion and dependency on virtualized environments the issue of Quality of Service (QoS) remains to be understood as it is no longer physical switches, NICs, or application instances that are deployed; it is virtual switches (for example Nexus 1000V), virtual NICs, and virtual machines that are deployed as Cisco Collaboration solutions are increasingly virtualized.
QoS with UC on UCS
In today’s converged environments, every application and/or device may be marking the traffic originating from it. From UC applications to virtual switches to Cisco Unified Computing Server (UCS) to Fabric Interconnects (61XX, 62XX) every application/device is capable of marking traffic, however, it makes more sense to mark it closest to the source of the traffic and then carry those trust markings as such in the network. In general, the rule of thumb applied to bare metal servers and physical infrastructure still applies in case of virtualized environments:
- Voice marking for QoS is classified as CoS 5 or DSCP 46 (EF).
- Videoconferencing marking for QoS is classified as CoS 4 or DSCP 34 (AF41, CS4).
- Call signaling for voice and videoconferencing is classified as CoS 3 or DSCP 24 (CS3).
At a high level, table 1-1 defines the traffic classification that can be defined for a virtualized Cisco Collaboration setup.
Table 1-1: Traffic Classification for Virtualized Cisco Collaboration Network
A virtual machine running as a base for a UC application can connect to following virtual switches:
- Cisco Nexus 1000V Switch: Requires the Enterprise Plus Edition of VMware ESXi and is a distributed virtual switch. Nexus 1000V offers policy-based virtual machine connectivity and enhanced QoS.
- Local VMware vSwitch: This vSwitch is available with all editions of VMware ESXi hypervisor and is limited to the local physical blade server on which the virtual machine is running.
- Distributed VMware vSwitch: This vSwitch is available only with the Enterprise Plus Edition of VMware ESXi hypervisor and can span multiple physical blade servers.
In this article, we will cover Nexus 1000V as this is the most commonly used and viable solution in a multiple server/application Cisco Collaboration network where juggling CoS to DSCP and vice-versa is required. Moreover, we will emphasize Cisco UCS’s capabilities to support QoS.
Nexus 1000V – Where and Why Do I Need It?
The Nexus 1000V is the edge switch on the virtual access layer and therefore provides a full quality of service (QoS) solution that includes:
- Traffic classification and marking
- Traffic policing (rate-limiting)
- Class-Based Weighted Fair Queuing for congestion management.
UCS Fabric Interconnects (FIs) create fibre-channel priority QoS class for traffic destined for the SAN Switch, which is set to FC QoS class that has no drop and marks traffic as CoS 3. With UC applications marking traffic (media and signaling) as L3 DSCP values only, it becomes challenging to prioritize or de-prioritize the traffic when UCS FIs as well as VMware (local or distributed) vSwitches are not designed to map L3 DSCP values to L2 CoS values. This issue is resolved with the help of the Nexus 1000V software switch which has the ability to map L2 CoS values to L3 DSCP values and vice versa.
Example 1-1 illustrates the configuration of Nexus 1000V to map DSCP to CoS (L3 to L2) markings.
Example 1-1: Nexus 1000V MQC to Prioritize L3 Traffic Transiting to FI and SAN
class-map type qos match-all media-audio
match dscp EF
class-map type qos match-any media-video
match dscp CS4
match dscp AF41
class-map type qos match-all signaling
match dscp CS3
policy-map type qos voice-qos
set cos 5
set cos 4
set cos 3
port-profile type vethernet VM_INTERFACES
service-policy type qos input voice-qos
Figure 1-1 depicts the association of Nexus 1000V with vEthernet interface for a VM on VCenter.
So, as you can see, Nexus 1000V makes it very convenient to mark multiple traffic types and, at the same time, preserve the classification while the traffic transits form applications to FI/SAN or vice-versa. However, in case Nexus 1000V is not part of a solution in a UC network, you could create multiple virtual switches and assign a different CoS value for the uplink ports of each of those switches. In other words, each virtual switch would have uplink ports configured with a different CoS value (for example, vSwitch 1 with a CoS value of 5, vSwitch 2 with a CoS value of 4, and so on). In such case, each VM would be assigned to a virtual switch, however, that will limit the traffic to a certain class. This is not a workable solution for Cisco UC on UCS as applications mark different traffic in different classes. Hence, a leading practice recommendation is to leverage Nexus 1000V for end-to-end QoS in a Cisco Collaboration solution.
QoS on Cisco UCS – How Can I Go About It?
Cisco UCS also offers the ability to mark traffic in various CoS values. Traffic classification in UCS is done on per vNIC basis. If you want a certain type of traffic to be treated a certain way, it needs its own vNIC(s).With the vNIC or vNIC template, you can configure the QoS policy you wish to put into effect on it. As discussed earlier, Nexus 1000V offers mapping CoS to DSCP and DSCP to CoS when the traffic is ingress and egress respectively to/from UC applications.
QOS for the entire UCS Fabric is configured from the UCS Manager. By default 50 percent of the bandwidth is allocated for COS3 traffic. This includes the FCOE traffic (which is marked as COS3) and any other traffic that is marked COS3 value. This queue has a no-drop policy. The remaining 50 percent is best effort for all other traffic. Table 1-2 gives an overview of the different configurable classes in UCS.
Table 1-2: UCS Fabric QoS Classes
Figure 1-2 shows the UCS based QoS classes that can be configured to keep CoS consistent across the virtual network.
Figure 1-2: Cisco UCS-based QoS Classes
Because leading practice recommends avoiding overlap with voice/video signaling traffic marked as CoS 3, FCoE traffic should be marked at a different CoS value. QoS policies can be created and properties for each policy can be set such that when a policy is applied to a vNIC the traffic is treated per the policy. Figure 1-3 shows the definition of Platinum policy.
Figure 1-3: Cisco UCS-based QoS Policy
The challenge with marking traffic in UCS is that multiple traffic classes cannot be linked to VM’s unless each VM is tagged to a specific vNIC. Moreover, the traffic markings are L2 CoS markings only, which still need Nexus 1000V to resolve the markings to L3 DSCP markings and vice-versa.
While virtualization of Cisco Collaboration solutions bring a rich feature set, and data center optimization (power, rack space, management), it also introduces certain key challenges that must be addressed, QoS is one of the major roadblocks if not properly planned and managed. QoS has its own twist and flavor with virtualized UC networks and requires diligent planning and deployment to ensure that the end-users do not feel anything out of place when it comes to voice media and signaling QoS requirements. This article focused on deployment of QoS in virtualized Cisco Collaboration solution; explicitly on Cisco Nexus 1000V and Cisco UCS. Nexus 1000V is an important component of any virtualized UC solution and must be strongly considered for inclusion in design and deployment. Cisco UCS offers QoS however, it is limited in QoS capabilities without support of Nexus 1000V, that enables L2 CoS to L3 DSCP conversion which the FI is unable to perform. Nexus 1000V and UCS together build a strong foundation for enabling QoS in virtualized Cisco Collaboration environments.
Akhil Behl is a Solutions Architect with Cisco Services, focusing on Cisco Collaboration and Security Architectures. He leads collaboration and security projects and service delivery worldwide for Cisco Services and the Collaborative Professional Services (CPS) portfolio. He's played major role in service conception and creation for various services within Cisco Advanced Services. He has Pre-Sales to Sales to Professional Services to Delivery to Post Sales experience with expertise in Consulting, Advisory, and Guidance services. He has extensive experience in Borderless, Collaboration and Data Center portfolio. Prior to his current role, he spent ten years working in various roles at Linksys as a Technical Support Lead, as an Escalation Engineer at Cisco Technical Assistance Center (TAC), and as a Network Consulting Engineer in Cisco Advanced Services.
Akhil has a bachelor of technology degree in electronics and telecommunications from IP University and a master’s degree in business administration from Symbiosis Institute. He is dual Cisco Certified Internetwork Expert CCIE # 19564 in Voice and Security. He also holds many other industry certifications, such as PMP, ITIL, VCP, CCNA, CCSP, CCVP, ISO/IEC 27002, TOGAF and CEH.
Over the course of his career, he has presented and contributed at various industry forums such as Interop, Enterprise Connect, Cloud Connect, Cloud Summit, Cisco Networkers, and Cisco SecCon. He also has several research papers published in various national and international journals including IEEE.
By Akhil Behl
Series: Quick Reference
Published: May 20, 2014
ISBN-10: 0-13-384596-6ISBN-13: 978-0-13-384596-9
Published by Cisco Press.
DISCOUNT: 35% off ciscopress.com for Cisco Technical Newsletter customers; use code CISCOTECH at checkout.