Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http:/​/​www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

QoS consists of the following key components:

• Classification— Classification is the process of distinguishing one type of traffic from another based upon ACLs, Differentiated Services Code Point (DSCP), Class of Service (CoS), and other factors.

• Marking and mutation— Marking is used on traffic to convey specific information to a downstream device in the network, or to carry information from one interface in a switch to another. When traffic is marked, QoS operations on that traffic can be applied. This can be accomplished directly using the set command or through a table map, which takes input values and translates them directly to values on output.

• Shaping and policing— Shaping is the process of imposing a maximum rate of traffic, while regulating the traffic rate in such a way that downstream devices are not subjected to congestion. Shaping in the most common form is used to limit the traffic sent from a physical or logical interface. Policing is used to impose a maximum rate on a traffic class. If the rate is exceeded, then a specific action is taken as soon as the event occurs.

• Queuing — Queueing is used to prevent traffic congestion. Traffic is sent to specific queues for servicing and scheduling based upon bandwidth allocation. Traffic is then scheduled or sent out through the port.

• Bandwidth—Bandwidth allocation determines the available capacity for traffic that is subject to QoS policies.

• Trust— Trust enables traffic to pass through the switch, and the DSCP, precedence, or CoS values coming in from the end points are retained in the absence of any explicit policy configuration.

The following terms are used interchangeably in this QoS configuration guide:

• Upstream (direction towards the switch) is the same as ingress.

• Downstream (direction from the switch) is the same as egress.

Note	Upstream is wireless to wired. Downstream is wired to wireless. Wireless to wireless has no specific term.

By configuring the quality of service (QoS), you can provide preferential treatment to specific types of traffic at the expense of other traffic types. Without QoS, the switch offers best-effort service to each packet, regardless of the packet contents or size. The switch sends the packets without any assurance of reliability, delay bounds, or throughput.

The following are specific features provided by QoS:

• Low latency

• Bandwidth guarantee

• Buffering capabilities and dropping disciplines

• Traffic policing

• Enables the changing of the attribute of the frame or packet header

• Relative services

Typically, networks operate on a best-effort delivery basis, which means that all traffic has equal priority and an equal chance of being delivered in a timely manner. When congestion occurs, all traffic has an equal chance of being dropped.

When you configure the QoS feature, you can select specific network traffic, prioritize it according to its relative importance, and use congestion-management and congestion-avoidance techniques to provide preferential treatment. Implementing QoS in your network makes network performance more predictable and bandwidth utilization more effective.

The QoS implementation is based on the Differentiated Services (Diff-Serv) architecture, a standard from the Internet Engineering Task Force (IETF). This architecture specifies that each packet is classified upon entry into the network.

The classification is carried in the IP packet header, using 6 bits from the deprecated IP type of service (ToS) field to carry the classification (class) information. Classification can also be carried in the Layer 2 frame.

Figure 3. QoS Classification Layers in Frames and Packets. The special bits in the Layer 2 frame or a Layer 3 packet are shown in the following figure:

To implement QoS, the switch must perform the following tasks:

• Traffic classification—Distinguishes packets or flows from one another.

• Traffic marking and policing—Assigns a label to indicate the given quality of service as the packets move through the switch, and then make the packets comply with the configured resource usage limits.

• Queuing and scheduling—Provides different treatment in all situations where resource contention exists.

• Shaping—Ensures that traffic sent from the switch meets a specific traffic profile.

Classification is the process of distinguishing one kind of traffic from another by examining the fields in the packet. Classification is enabled only if QoS is enabled on the switch. By default, QoS is enabled on the switch.

During classification, the switch performs a lookup and assigns a QoS label to the packet. The QoS label identifies all QoS actions to be performed on the packet and from which queue the packet is sent.

After a packet is classified and has a DSCP-based, CoS-based, or QoS-group label assigned to it, the policing and marking process can begin.

Policing involves creating a policer that specifies the bandwidth limits for the traffic. Packets that exceed the limits are out of profile or nonconforming. Each policer decides on a packet-by-packet basis whether the packet is in or out of profile and specifies the actions on the packet. These actions, carried out by the marker, include passing through the packet without modification, dropping the packet, or modifying (marking down) the assigned DSCP or CoS value of the packet and allowing the packet to pass through.

To avoid out-of-order packets, both conform and nonconforming traffic typically exit the same queue.

Note	All traffic, regardless of whether it is bridged or routed, is subjected to a policer, if one is configured. As a result, bridged packets might be dropped or might have their DSCP or CoS fields modified when they are policed and marked.

You can only configure policing on a physical port.

After you configure the policy map and policing actions, attach the policy to an ingress port or SVI by using the service-policy interface configuration command.

Marking is used to convey specific information to a downstream device in the network, or to carry information from one interface in a switch to another.

Marking can be used to set certain field/bits in the packet headers, or marking can also be used to set certain fields in the packet structure that is internal to the switch. Additionally, the marking feature can be used to define mapping between fields. The following marking methods are available for QoS:

• Packet header

• Device (switch) specific information

• Table maps

To support QoS in a network, traffic entering the service provider network needs to be policed on the network boundary routers to ensure that the traffic rate stays within the service limit. Even if a few routers at the network boundary start sending more traffic than what the network core is provisioned to handle, the increased traffic load leads to network congestion. The degraded performance in the network makes it difficult to deliver QoS for all the network traffic.

Traffic policing functions (using the police feature) and shaping functions (using the traffic shaping feature) manage the traffic rate, but differ in how they treat traffic when tokens are exhausted. The concept of tokens comes from the token bucket scheme, a traffic metering function.

Note	When running QoS tests on network traffic, you may see different results for the shaper and policing data. Network traffic data from shaping provides more accurate results.

The switch uses both queueing and scheduling to help prevent traffic congestion. The switch supports the following queueing and scheduling features:

• Bandwidth

• Weighted Tail Drop

• Priority queues

• Queue buffers

For wired or wireless ports that are connected to the switch (end points such as IP phones, laptops, cameras, telepresence units, or other devices), their DSCP, precedence, or CoS values coming in from these end points are trusted by the switch and therefore are retained in the absence of any explicit policy configuration.

This trust behavior is applicable to both upstream and downstream QoS.

The packets are enqueued to the appropriate queue per the default initial configuration. No priority queuing at the switch is done by default. This is true for unicast and multicast packets.

The Cisco IOS XE 3.2 Release supported different trust defaults for wired and wireless ports. The trust default for wired ports was the same as for this software release. For wireless ports, the default system behavior was non-trust, which meant that when the switch came up, all markings for the wireless ports were defaulted to zero and no traffic received priority treatment. For compatibility with an existing wired switch, all traffic went to the best-effort queue by default. The access point performed priority queuing by default. In the downstream direction, the access point maintained voice, video, best-effort, and background queues for queuing. The access selected the queuing strategy based on the 11e tag information. By default, the access point treated all wireless packets as best effort.

The default trust behavior in the case of wireless ports could be changed by using the qos wireless default untrust command.

Note

If you upgrade from Cisco IOS XE 3.2 SE Release to a later release, the default behavior of the wireless traffic is still untrusted. In this situation, you can use the no qos wireless-default untrust command to enable trust behavior for wireless traffic. However, if you install Cisco IOS XE 3.3 SE or a later release on the switch, the default QoS behavior for wireless traffic is trust. Starting with Cisco IOS XE 3.3 SE Release and later, the packet markings are preserved in both egress and ingress directions for new installations (not upgrades) for wireless traffic.

In a typical network, you connect a Cisco IP Phone to a switch port and cascade devices that generate data packets from the back of the telephone. The Cisco IP Phone guarantees the voice quality through a shared data link by marking the CoS level of the voice packets as high priority (CoS = 5) and by marking the data packets as low priority (CoS = 0). Traffic sent from the telephone to the switch is typically marked with a tag that uses the 802.1Q header. The header contains the VLAN information and the class of service (CoS) 3-bit field, which is the priority of the packet.

For most Cisco IP Phone configurations, the traffic sent from the telephone to the switch should be trusted to ensure that voice traffic is properly prioritized over other types of traffic in the network. By using the trust device interface configuration command, you configure the switch port to which the telephone is connected to trust the traffic received on that port.

Note

The trust device device_type command available in interface configuration mode is a stand-alone command on the switch. When using this command in an AutoQoS configuration, if the connected peer device is not a corresponding device (defined as a device matching your trust policy), both CoS and DSCP values are set to "0" and any input policy will not take effect. If the connected peer device is a corresponding device, input policy will take effect.

With the trusted setting, you also can use the trusted boundary feature to prevent misuse of a high-priority queue if a user bypasses the telephone and connects the PC directly to the switch. Without trusted boundary, the CoS labels generated by the PC are trusted by the switch (because of the trusted CoS setting). By contrast, trusted boundary uses CDP to detect the presence of a Cisco IP Phone (such as the Cisco IP Phone 7910, 7935, 7940, and 7960) on a switch port. If the telephone is not detected, the trusted boundary feature disables the trusted setting on the switch port and prevents misuse of a high-priority queue. Note that the trusted boundary feature is not effective if the PC and Cisco IP Phone are connected to a hub that is connected to the switch.

Wireless QoS is backward compatible with the precious metal policies offered by the unified wireless controller platforms. The precious metal policies are system-defined policies that are available on the controller.

The following policies are available:

These policies (also known as profiles) can be applied to a WLAN based on the traffic. We recommend the configuration using the Cisco IOS MQC configuration. The policies are available in the system based on the precious metal policy required.

Based on the policies applied, the 802.1p, 802.11e (WMM), and DSCP fields in the packets are affected. These values are preconfigured and installed when the switch is booted.

Note	Unlike the precious metal policies that were applicable in the Cisco Unified Wireless controllers, the attributes rt-average-rate, nrt-average-rate, and peak rates are not applicable for the precious metal policies configured on this switch platform.

There are two queues configured by default on each wired interface on the switch. All control traffic traverses and is processed through queue 0. All other traffic traverses and is processed through queue 1.

The ports on the switch do not distinguish between wired or wireless physical ports. Depending on the kind of device associated to the switch, the policies are applied. For example, when an access point is connected to a switch port, the switch detects it as a wireless device and applies the default hierarchical policy which is in the format of a parent-child policy. This policy is an hierarchical policy. The parent policy cannot be modified but the child policy (port-child policy) can be modified to suite the QoS configuration. The switch is preconfigured with a default class map and a policy map.

A target is an entity where a policy is applied. You can apply a policy to either a wired or wireless target. A wired target can be either a port or VLAN. A wireless target can be either a port, radio, SSID, or client. Only port, SSID, and client policies are user configurable. Radio polices are not user configurable. Wireless QoS policies for port, radio, SSID, and client are applied in the downstream direction, and for upstream only SSID and client targets are supported. Downstream indicates that traffic is flowing from the switch to the wireless client. Upstream indicates that traffic is flowing from wireless client to the switch.

The following are restrictions for applying QoS features on the switch for the wired target:

• A maximum of 8 queuing classes are supported on the switch port for the wired target.

• A maximum of 63 policers are supported per policy on the wired port for the wired target.

• No more than two levels are supported in a QoS hierarchy.

• In a hierarchical policy, overlapping actions between parent and child are not allowed, except when a policy has the port shaper in the parent and queueing features in the child policy.

• A QoS policy cannot be attached to any EtherChannel interface.

• Policing in both the parent and child is not supported in a QoS hierarchy.

• Marking in both the parent and child is not supported in a QoS hierarchy.

• A mixture of queue limit and queue buffer in the same policy is not supported.

  Note	The queue-limit percent is not supported on the switch because the queue-buffer command handles this functionality. Queue limit is only supported with the DSCP and CoS extensions.

• With shaping, there is an IPG overhead of 20Bytes for every packet that is accounted internally in the hardware. Shaping accuracy will be effected by this, specially for packets of small size.

• The classification sequence for all wired queuing-based policies should be the same across all wired upstream ports (10-Gigabit Ethernet), and the same for all downstream wired ports (1-Gigabit Ethernet).

• Empty classes are not supported.

• Class-maps with empty actions are not supported. If there are two policies with the same order of class-maps and if there are class-maps with no action in one of the policies, there may be traffic drops. As a workaround, allocate minimal bandwidth for all the classes in PRIORITY_QUEUE.

• A maximum of 256 classes are supported per policy on the wired port for the wired target.

• The actions under a policer within a policy map have the following restrictions:

  • The conform action must be transmit.

  • The exceed/violate action for markdown type can only be cos2cos, prec2prec, dscp2dscp.

  • The markdown types must be the same within a policy.

• A port-level input marking policy takes precedence over an SVI policy; however, if no port policy is configured, the SVI policy takes precedence. For a port policy to take precedence, define a port-level policy; so that the SVI policy is overwritten.

• Classification counters have the following specific restrictions:

  • Classification counters count packets instead of bytes.

  • Filter-based classification counters are not supported

  • Only QoS configurations with marking or policing trigger the classification counter.

  • The classification counter is not port based. This means that the classification counter aggregates all packets belonging to the same class of the same policy which attach to different interfaces.

  • As long as there is policing or marking action in the policy, the class-default will have classification counters.

  • When there are multiple match statements in a class, then the classification counter only shows the traffic counter for one of the match statements.

• Table maps have the following specific restrictions:

  • Only one table map for policing exceeding the markdown and one table map for policing violating the markdown per direction per target is supported.

  • Table maps must be configured under the class-default; table maps are unsupported for a user-defined class.

• Hierarchical policies are required for the following:

  • Port-shapers

  • Aggregate policers

  • PV policy

  • Parent shaping and child marking/policing

• For ports with wired targets, these are the only supported hierarchical policies:

  • Police chaining in the same policy is unsupported, except for wireless client.

  • Hierarchical queueing is unsupported in the same policy (port shaper is the exception).

  • In a parent class, all filters must have the same type. The child filter type must match the parent filter type with the following exceptions:

    • If the parent class is configured to match IP, then the child class can be configured to match the ACL.

    • If the parent class is configured to match CoS, then the child class can be configured to match the ACL.

• The trust device device_type command available in interface configuration mode is a stand-alone command on the switch. When using this command in an AutoQoS configuration, if the connected peer device is not a corresponding device (defined as a device matching your trust policy), both CoS and DSCP values are set to "0" and any input policy will not take effect. If the connected peer device is a corresponding device, input policy will take effect.

The following are restrictions for applying QoS features on the VLAN to the wired target:

• For a flat or nonhierarchical policy, only marking or a table map is supported.

The following are restrictions and considerations for applying QoS features on EtherChannel and channel member interfaces:

• QoS is not supported on an EtherChannel interface.

• QoS is supported on EtherChannel member interfaces in both ingress and egression directions. All EtherChannel members must have the same QoS policy applied. If the QoS policy is not the same, each individual policy on the different link acts independently.

• On attaching a service policy to channel members, the following warning message appears to remind the user to make sure the same policy is attached to all ports in the EtherChannel: ' Warning: add service policy will cause inconsistency with port xxx in ether channel xxx. '.

• Auto QoS is not supported on EtherChannel members.

Note

On attaching a service policy to an EtherChannel, the following message appears on the console: ' Warning: add service policy will cause inconsistency with port xxx in ether channel xxx. '. This warning message should be expected. This warning message is a reminder to attach the same policy to other ports in the same EtherChannel. The same message will be seen during boot up. This message does not mean there is a discrepancy between the EtherChannel member ports.

1.    configure terminal


2.    class-map {class-map name | match-any}


3.    match access-group {index number | name}


4.    match class-map class-map name


5.    match cos cos value


6.    match dscp dscp value


7.    match ip {dscp dscp value | precedence precedence value }


8.    match non-client-nrt


9.    match qos-group qos group value


10.    match vlan vlan value


11.    match wlan user-priority wlan value


12.    end

Switch# configure terminal

Switch(config)# class-map test_1000
Switch(config-cmap)#

Switch(config-cmap)# match access-group 100
Switch(config-cmap)#

Switch(config-cmap)# match class-map test_2000
Switch(config-cmap)#

Switch(config-cmap)# match cos 2 3 4 5
Switch(config-cmap)#

Switch(config-cmap)# match dscp af11 af12
Switch(config-cmap)#

Switch(config-cmap)# match ip dscp af11 af12
Switch(config-cmap)#

Switch(config-cmap)# match non-client-nrt
Switch(config-cmap)#

Switch(config-cmap)# match qos-group 10
Switch(config-cmap)#

Switch(config-cmap)# match vlan 210
Switch(config-cmap)#

Switch(config-cmap)# match wlan user priority 7
Switch(config-cmap)#

Switch(config-cmap)# end

Configure the policy map.

1.    configure terminal


2.    policy-map policy-map name


3.    class {class-name | class-default}


4.    admit


5.    bandwidth {kb/s kb/s value | percent percentage | remaining {percent | ratio}}


6.    exit


7.    no


8.    police {target_bit_rate | cir | rate}


9.    priority {kb/s | level level value | percent percentage value}


10.    queue-buffers ratio ratio limit


11.    queue-limit {packets | cos | dscp | percent}


12.    service-policy policy-map name


13.    set {cos | dscp | ip | precedence | qos-group | wlan}


14.    shape average {target _bit_rate | percent}


15.    end

Switch# configure terminal

Switch(config)# policy-map test_2000
Switch(config-pmap)#

Switch(config-pmap)# class test_1000
Switch(config-pmap-c)#

Switch(config-pmap-c)# admit cac wmm-tspec
Switch(config-pmap-c)#

Switch(config-pmap-c)# bandwidth 50
Switch(config-pmap-c)#

Switch(config-pmap-c)# exit
Switch(config-pmap-c)#

Switch(config-pmap-c)# no
Switch(config-pmap-c)#

Switch(config-pmap-c)# police 100000
Switch(config-pmap-c)#

Switch(config-pmap-c)# priority percent 50 
Switch(config-pmap-c)#

Switch(config-pmap-c)# queue-buffers ratio 10
Switch(config-pmap-c)#

Switch(config-pmap-c)# queue-limit cos 7 percent 50
Switch(config-pmap-c)#

Switch(config-pmap-c)# service-policy test_2000
Switch(config-pmap-c)#

Switch(config-pmap-c)# set cos 7
Switch(config-pmap-c)#

Switch(config-pmap-c) #shape average percent 50
Switch(config-pmap-c) #

Switch(config-pmap-c) #end
Switch(config-pmap-c) #

Configure the interface.

1.    configure terminal


2.    policy-map policy name


3.    class class name


4.    set cos {cos value | cos table table-map name | dscp table table-map name | precedence table table-map name | qos-group table table-map name | wlan user-priority table table-map name}


5.    set dscp {dscp value | default | dscp table table-map name | ef | precedence table table-map name | qos-group table table-map name | wlan user-priority table table-map name}


6.    set ip {dscp | precedence}


7.    set precedence {precedence value | cos table table-map name | dscp table table-map name | precedence table table-map name | qos-group table table-map name}


8.    set qos-group {qos-group value | dscp table table-map name | precedence table table-map name}


9.    set wlan user-priority {wlan user-priority value | cos table table-map name | dscp table table-map name | qos-group table table-map name | wlan table table-map name}


10.    end


11.    show policy-map

Switch# configure terminal

Switch(config)# policy-map policy1
Switch(config-pmap)#

Switch(config-pmap)# class class1
Switch(config-pmap-c)#

Switch(config-pmap)# set cos 5
Switch(config-pmap)# 

Switch(config-pmap)# set dscp af11
Switch(config-pmap)# 

Switch(config-pmap)# set ip dscp c3
Switch(config-pmap)#

Switch(config-pmap)# set precedence 5
Switch(config-pmap)#

Switch(config-pmap)# set qos-group 10
Switch(config-pmap)#

Switch(config-pmap)# set wlan user-priority 1
Switch(config-pmap)#

Switch(config-pmap)# end
Switch#

Switch# show policy-map

Attach the traffic policy to an interface using the service-policy command.

1.    configure terminal


2.    class-map class-map-name


3.    match dscp dscp-value-for-voice


4.    end


5.    configure terminal


6.    class-map class-map-name


7.    match dscp dscp-value-for-video


8.    end

Switch# configure terminal

Switch(config)# class-map voice

Switch(config-cmap)# match dscp 46

Switch(config)# end

Switch# configure terminal

Switch(config)# class-map video

Switch(config-cmap)# match dscp 34

Switch(config)# end

1.    configure terminal


2.    interface type


3.    service-policy {input policy-map | output policy-map }


4.    end


5.    show policy map

Switch# configure terminal

Switch(config)# interface GigabitEthernet1/0/1
Switch(config-if)#

Switch(config-if)# service-policy output policy_map_01
Switch(config-if)#

Switch(config-if)# end
Switch#

Switch# show policy map

Proceed to attach any other traffic policy to an interface, and to specify the direction in which the policy should be applied.

1.    configure terminal


2.    wlan profile-name


3.    service-policy [ input | output ] policy-name


4.    service-policy client [ input | output ] policy-name


5.    end

Switch# configure terminal

Switch# wlan test4

Switch(config-wlan)# service-policy input policy-map-ssid

Switch(config-wlan)# service-policy client input policy-map-client

Switch(config)# end

1.    configure terminal


2.    class-map {class-map name | match-any }


3.    match access-group { access list index | access list name }


4.    policy-map policy-map-name


5.    class {class-map-name | class-default}


6.    set {cos | dscp | ip | precedence | qos-group | wlan user-priority}


7.    police {target_bit_rate | cir | rate }


8.    exit


9.    exit


10.    interface interface-id


11.    service-policy input policy-map-name


12.    end


13.    show policy-map [policy-map-name [class class-map-name]]


14.    copy running-config startup-config

Switch# configure terminal

Switch(config)# class-map ipclass1
Switch(config-cmap)# exit
Switch(config)#

Switch(config-cmap)# match access-group 1000
Switch(config-cmap)# exit
Switch(config)#

Switch(config)# policy-map flowit
Switch(config-pmap)#

Switch(config-pmap)# class ipclass1
Switch(config-pmap-c)# 

Switch(config-pmap-c)# set dscp 45
Switch(config-pmap-c)#

Switch(config-pmap-c)# police 100000 conform-action transmit exceed-action
drop
Switch(config-pmap-c)#