Nexus 1000v: QoS Overview and Traffic Classification Configuration

[Sandeep Singh]

Introduction

QoS on Nexus 1000v provides traffic classification, marking, and policing on packets flowing through the network. Furthermore, with the Cisco Nexus 1000v, QoS can be applied on a per virtual interface basis. Hence, it makes it possible to apply different QoS policies to VM, Service Console of VMotion traffic. On appropriately dimensioned uplinks, such as 10 Gigiabt Ethernet, this removes the requirement for dedicated physical NICs for Service Console or VMotion traffic. Identifying and categorizing network traffic into traffic classes (that is, classifying packets) enables you to handle different types of traffic by separating network traffic into different categories. Classifying network traffic allows you to see the kinds of traffic you have and treat some types of traffic differently than others. Identifying and organizing network traffic allows you to allocate network resources to deliver the best performance for each type of traffic.

Following can be achieved by implementing QoS on Nexus 1000v:

• Mark traffic leaving their servers

• Police traffic to/from VMs

 

Nexus 1000v Traffic Classification

In a VMware environment, traffic varies based on the types of applications being virtualized. However, some traffic types can be identified and general prioritization applied. The general classifications of traffic for a typical VMware deployment are as follows:

• Control traffic: Control traffic is generated by the Cisco Nexus 1000V Series and exchanged between the primary and secondary VSMs as well as the VSMs and VEMs. It requires very little bandwidth (less than 10 KBps) but demands absolute priority. This type of traffic generally falls under Network Control class of traffic.

• Management Traffic: This traffic type includes the communication for managing the compute and network resources. This includes ESX service-console access (VMKernel in case of ESXi), storage and network device management, and per-product traffic (application and VM administration). The traffic requirement of this type of traffic may not be high during steady state; however access to the critical infrastructure component is crucial during failure or congestions.

• Virtual machine data traffic: This traffic category can comprise of two major traffic groups. The first one consists of back-end traffic, which includes storage traffic and back-end VM-to-VM traffic for multi-tier applications. The second group consists of user access traffic (generically called front-end application traffic).

• VMware VMmotion traffic: VMware VMotion traffic does not occur on a constant basis, meaning that most of the time VMware VMotion does not use any bandwidth. When this type of traffic is faced with bandwidth that is lower than line rate, the duration of the virtual machine move event is extended based on the amount of bandwidth available. VMware VMotion traffic can usually be considered of medium priority relative to other traffic types.

• Packet traffic: Packet traffic is used to transport selected packets to the VSM for processing. The bandwidth required for packet interface is extremely low, and its use is very intermittent. If Cisco Discovery Protocol and IGMP features are turned off, there is no packet traffic at all. The importance of this interface is directly related to the use of IGMP. If IGMP is not deployed, then this interface is used only for Cisco Discovery Protocol, which is not considered a critical switch function.

 

Default QoS Behaviour and High Availability Requirements

QoS on Nexus 1000v has no default behavior. Policing and prioritization of traffic are only implemented when we apply a policy map to an interface. The only exception is that, by default, the CoS value for control and packet VLAN traffic is set to 6. This value can be overridden with an explicit QoS policy that is configured on the interface that carries the control and packet VLAN traffic.

QoS recovers its previous state after a software restart, and it is able to switch over from the active supervisor (VSM) to the standby supervisor (VSM) without a loss of state.

Classification, Marking and Policing on Nexus 1000v

Classificiation, Marking and Policing capabilties of Nexus 1000v are similar to Nexus 7000 as both platforms based on NX-OS.

 

Nexus 1000v QoS Configuration

Classification: class-map definition

The first step is to define a set of access-list that will allow identifying the class to which a packet belongs. The following access-list will need to be defined for classification purposes:

ip access-list Network-Control

ip access-list Expedited-Forwarding

ip access-list High-Priority

ip access-list Realtime

ip access-list Near-Realtime-1

ip access-list Assured-Transport-1

ip access-list Low-Priority

ip access-list Near-Realtime-3

ip access-list Assured-Transport-3

Each of the above access-list should be properly configured to permit relevant protocol or ip addresses for the class.

Note: There is no need to specify an access-list for best effort, indeed this will match everything not matched earlier and will use the class-default.

Once the access-lists are defined we need to define each class that will be used. We will use the following config to define the classes:

class-map type qos Network-Control

  match access-group name Network-Control

class-map type qos Expedited-Forwarding

  match access-group name Expedited-Forwarding

class-map type qos High-Priority

  match access-group name High-Priority

class-map type qos Realtime

  match access-group name Realtime

class-map type qos Near-Realtime-1

  match access-group name Near-Realtime-1

class-map type qos Assured-Transport-1

  match access-group name Assured-Transport-1

class-map type qos Low-Priority

  match access-group name Low-Priority

class-map type qos Near-Realtime-3

  match access-group name Near-Realtime-3

class-map type qos Assured-Transport-3

  match access-group name Assured-Transport-3

Marking and Policing: policy-map definition

A simple marking configuration that would mark each class according to the requirement can be achieved with the below policy-map:

policy-map type qos Marking

  class Network-Control

    set dscp cs6

class Expedited-Forwarding

   set dscp 46

class High-Priority

  set dscp cs5

class Realtime

  set dscp af41

class Near-Realtime-1

set dscp af31

class Assured-Transport-1

set dscp af21

class Low-Priority

  set dscp cs1

class Near-Realtime-3

set dscp af33

class Assured-Transport-3

  set dscp af23

class class-default

set dscp 0

The policer shown below polices to a CIR (committed information rate) of 50 Mbits/s, it mark the confirming traffic to EF and drop the traffic above the CIR.

police cir 50 mbps bc 8 mbytes conform set-dscp-transmit ef violate drop

The exact CIR configured can be decided based on your requirement.

It is part of usual best practices to use a burst (Bc) value relatively high. This is absolutely needed when the traffic policed is TCP based. For this reason it is shown here Be value more or less equal to the CIR.

The policy-map to apply to a port which needs policing of priority traffic in addition to marking will be similar to the following:

Policy-map type qos Marking-Police-XX-YY

  class Network-Control

    set dscp cs6

class Expedited-Forwarding

   police cir XX mbps bc XX/8 mbytes conform set-dscp-transmit ef violate drop

class High-Priority

  police cir YY mbps bc YY/8 mbytes conform set-dscp-transmit cs5 violate drop

class Realtime

  set dscp af41

class Near-Realtime-1

set dscp af31

class Assured-Transport-1

set dscp af21

class Low-Priority

  set dscp cs1

class Near-Realtime-3

set dscp af33

class Assured-Transport-3

set dscp af23

class class-default

set dscp 0

The Value XX and YY above refer the rate to which you will limit respectively class Expedite-Forwarding and High-Priority. That value can be adapted on port by port basis depending on the type of servers (VMs) connected.

Note: Once defined, a given policy-map can be used on as many ports with same profile as required; each port will be policed independently. Secondly, Each module polices independently, which might affect a policer that is applied to traffic distributed across more than one module.

CoS value for control and packet VLAN traffic is set to 6 on Nexus 1000v. However, we need to define a class to specifically mark Network-Control traffic on Nexus 1000v for the VMWare ESX management traffic. Remember that VMware vCenter Server requires access to the VMware ESX management interface to monitor and configure the VMware ESX host.

Marking and Policing: Interface configuration

After having defined class-map and policy-map, we now need to apply the policy-map to relevant interfaces.On Nexus 1000v, we can apply the policing instructions in a QoS policy map to ingress or egress packets by attaching that QoS policy map to an interface or port profile. To select ingress or egress, we can specify either the input or output keyword in the service-policy command.

It is recommended to apply service policy on a port-profile rather than the VM interfaces. The Cisco Nexus 1000v Series with the port profile feature eliminates the requirement for the administrator to create or maintain vSwitch and port group configurations on any of their VMware ESX hosts.

Network policies enforced by a port profile follow the virtual machine throughout its lifecycle, whether the virtual machine is being migrated from one server to another, suspended, hibernated, or restarted.

Port profiles are not static entities; they are dynamic policies that can change as network needs change. Changes to active port profiles are applied to each switch port that is using the profile.

The following configuration shows how to apply service policy on a port-profile,

N1K(config)# port-profile hi-pri-apps

N1K(config-port-prof)# service-policy output Marking-Police-XX-YY

 

Related Information

Configure and verify QOS Fair Queue on Nexus 1000v

Nexus 1000v Port Profile Changes in version 1.4