Finding Feature
Information

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.

Prerequisites for QoS

Before configuring standard QoS, you must have a thorough understanding of these items:

Standard QoS concepts.

Wireless concepts and network topologies.

Classic Cisco IOS QoS.

Modular QoS CLI (MQC).

Understanding of QoS implementation.

The types of applications used and the traffic patterns on your network.

Traffic characteristics and needs of your network. For example, is the traffic on your network bursty? Do you need to reserve bandwidth for voice and video streams?

QoS
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
controller 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
controller, and the DSCP, precedence, or CoS values coming
in from the end points are retained in the absence of any explicit policy
configuration.

QoS Terminology

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

Upstream (direction towards the controller) is the same as ingress.

Downstream (direction from the controller) is the same as egress.

Note

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

Information About QoS

QoS Overview

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 controller offers best-effort service to each packet, regardless of the packet contents or size. The controller sends the packets without any assurance of reliability, delay bounds, or throughput.

Modular QoS Command-Line Interface

With the controller, QoS features are enabled through the Modular QoS command-line interface (MQC). The MQC is a command-line interface (CLI) structure that allows you to create traffic policies and attach these policies to interfaces. A traffic policy contains a traffic class and one or more QoS features. A traffic class is used to classify traffic, while the QoS features in the traffic policy determine how to treat the classified traffic. One of the main goals of MQC is to provide a platform-independent interface for configuring QoS across Cisco platforms.

Wireless QoS Overview

Wireless QoS can be configured on the following wireless targets:

Radio

SSID (applicable on a per-radio, per-AP, and per-SSID)

Client

The following table displays how policies are supported for the wireless targets.

Table 1 Wireless Targets Policies Support

Wireless Target

Policies on Wireless Targets Supported

Policies Supported Downstream Direction

Policies Supported Upstream Direction

Radio

Yes

Yes - but not configurable by user

No

SSID

Yes

Yes - user configurable

Yes - user configurable

Client

Yes

Yes - user configurable

Yes - user configurable

Note

Additional polices that are user configured include multi-destination policers and VLANs.

Port Policy
Format

The
Cisco 5700 Series Wireless Controller does not contain a default port
policy. Physical port policies must be configured for voice and video to
function. Because a
Cisco 5700 Series Wireless Controller contains six 10-gigabit ports, the
policy map must be configured on all ports.

Note

The policy must
be configured on all of the six physical ports on the controller even if LAG
(Link Aggregation/Etherchannel) is configured.

The following basic
port policy must be configured on the physical ports. You can add further
classification if required:

Radio Policies

The radio policies are system defined and are not
user configurable. Radio wireless targets are only applicable in the downstream
direction.

Radio policies are applicable on a per-radio, per-access point basis. The rate limit on the radios is the practical limit of the AP radio rate. This value is equivalent to the sum of the radios supported by the access point.

SSID Policies

You can create QoS policies on SSID BSSID (Basic Service Set Identification) in both the upstream and downstream directions. By default, there is no SSID policy.
You can configure an SSID policy based on the SSID name. The policy is applicable on a per BSSID.

The types of policies you can create on SSID include marking by using table maps (table-maps), shape rate, and RT1 (Real Time 1) and RT2 (Real Time 2) policiers. If traffic is upstream, you usually configure a marking policy on the SSID. If traffic is downstream, you can configure marking and queuing.

There should be a one-to-one mapping between the policies configured on a port and an SSID. For example, if you configure class voice and class video on the port, you can have a similar policy on the SSID.

The policy on the port is mandatory if you want to preserve the voice
and video behavior priority at the port level. Queuing policy is applicable in a downstream direction. When
packets arrive from the AP, you can only configure policing and rate limiting.

SSID priorities can be specified by configuring bandwidth remaining ratio. Queuing SSID policies
are applied in the downstream direction.

Client Policies

Client policies are applicable in the upstream and downstream direction. The wireless control module of the controller applies the default client policies when admission control is enabled for WMM clients. When admission control is disabled, there is no default client policy. You can configure policing and marking policies on clients.

Note

A client policy can have both IPv4 and IPv6 filters.

You can configure client policies in the following ways:

Using AAA—You can use a combination of AAA and TCLAS, and AAA and SIP snooping when configuring with AAA.

Using the Cisco IOS MQC CLI—You can use a combination of CLI and TCLAS and CLI and SIP snooping.

Using the default configuration

Note

When applying client policies on a WLAN, you must disable the WLAN before modifying the client policy. SSID policies can be modified even if the WLAN is enabled.

Note

If you configured AAA by configuring the unified wireless controller procedure, and using the MQC QoS commands, the policy configuration performed through the MQC QoS commands takes precedence.

Hierarchical Wireless QoS

The controller supports hierarchical QoS for wireless targets. Hierarchical QoS policies are applicable on port, radio, SSID, and client. QoS policies configured on the device (including marking, shaping, policing) can be applied across the targets. If the network contains non-realtime traffic, the non-realtime traffic is subject to approximate fair drop. Hierarchy refers to the process of application of the various QoS policies on the packets arriving to the device.

Figure 1. Hierarchical QoS. This figure shows the various targets available on a wireless network, as well as a hierarchal wireless configuration. Wireless QoS is applied per-radio constraint, per-WLAN, and per-client constraint.

Wireless Packet Format

Figure 2. Wireless Packet Path in the Egress Direction during First Pass.

This figure displays the wireless packet flow and encapsulation used in hierarchical wireless QoS. The incoming packet enters the controller. The controller encapsulates this incoming packet and adds the 802.11e and CAPWAP headers.

Hierarchical AFD

Approximate Fair Dropping (AFD) is a feature provided by the QoS infrastructure in Cisco IOS. For wireless targets, AFD can be configured on SSID (via shaping) and clients (via policing). AFD shaping rate is only applicable for downstream direction. Unicast real-time traffic is not subjected to AFD drops.

QoS Implementation

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:

Layer 2 Frame Prioritization Bits

Layer 2 Inter-Switch Link (ISL) frame headers have a 1-byte User field that carries an IEEE 802.1p class of service (CoS) value in the three least-significant bits. On ports configured as Layer 2 ISL trunks, all traffic is in ISL frames.

Layer 2 802.1Q frame headers have a 2-byte Tag Control Information field that carries the CoS value in the three most-significant bits, which are called the User Priority bits. On ports configured as Layer 2 802.1Q trunks, all traffic is in 802.1Q frames except for traffic in the native VLAN.

Other frame types cannot carry Layer 2 CoS values.

Layer 2 CoS values range from 0 for low priority to 7 for high priority.

Layer 3 Packet Prioritization Bits

Layer 3 IP packets can carry either an IP precedence value or a Differentiated Services Code Point (DSCP) value. QoS supports the use of either value because DSCP values are backward-compatible with IP precedence values.

End-to-End QoS Solution Using Classification

All switches and routers that access the Internet rely on the class information to provide the same forwarding treatment to packets with the same class information and different treatment to packets with different class information. The class information in the packet can be assigned by end hosts or by switches or routers along the way, based on a configured policy, detailed examination of the packet, or both. Detailed examination of the packet is expected to occur closer to the edge of the network, so that the core switches and routers are not overloaded with this task.

Switches and routers along the path can use the class information to limit the amount of resources allocated per traffic class. The behavior of an individual device when handling traffic in the Diff-Serv architecture is called per-hop behavior. If all devices along a path provide a consistent per-hop behavior, you can construct an end-to-end QoS solution.

Implementing QoS in your network can be a simple task or complex task and depends on the QoS features offered by your internetworking devices, the traffic types and patterns in your network, and the granularity of control that you need over incoming and outgoing traffic.

Packet Classification

Packet classification is the process of identifying a packet as belonging to one of several classes in a defined policy, based on certain criteria. The Modular QoS CLI (MQC) is a policy-class based language. The policy class language is used to define the following:

Class-map template with one or several match criteria

Policy-map template with one or several classes associated to the policy map

The policy map template is then associated to one or several interfaces on the controller.

Packet classification is the process of identifying a packet as belonging to one of the classes defined in the policy map. The process of classification will exit when the packet being processed matches a specific filter in a class. This is referred to as first-match exit. If a packet matches multiple classes in a policy, irrespective of the order of classes in the policy map, it would still exit the classification process after matching the first class.

If a packet does not match any of the classes in the policy, it would be classified into the default class in the policy. Every policy map has a default class, which is a system-defined class to match packets that do not match any of the user-defined classes.

Packet classification can be categorized into the following types:

Classification based on information that is propagated with the packet

Classification Based on Layer 3 or Layer 4 Header

This is the most common deployment scenario. Numerous fields in the Layer 3 and Layer 4 headers can be used for packet classification.

At the most granular level, this classification methodology can be used to match an entire flow. For this deployment type, an access control list (ACLs) can be used. ACLs can also be used to match based on various subsets of the flow (for example, source IP address only, or destination IP address only, or a combination of both).

Classification can also be done based on the precedence or DSCP values in the IP header. The IP precedence field is used to indicate the relative priority with which a particular packet needs to be handled. It is made up of three bits in the IP header's type of service (ToS) byte.

The following table shows the different IP precedence bit values and their names.

Note

IP precedence is not supported for wireless QoS.

Table 4 IP Precedence Values and Names

IP Precedence Value

IP Precedence Bits

IP Precedence Names

0

000

Routine

1

001

Priority

2

010

Immediate

3

011

Flash

4

100

Flash Override

5

101

Critical

6

110

Internetwork control

7

111

Network control

Note

All routing control traffic in the network uses IP precedence value 6 by default. IP precedence value 7 also is reserved for network control traffic. Therefore, the use of IP precedence values 6 and 7 is not recommended for user traffic.

The DSCP field is made up of 6 bits in the IP header and is being standardized by the Internet Engineering Task Force (IETF) Differentiated Services Working Group. The original ToS byte contained the DSCP bits has been renamed the DSCP byte. The DSCP field is part of the IP header, similar to IP precedence. The DSCP field is a super set of the IP precedence field. Therefore, the DSCP field is used and is set in ways similar to what was described with respect to IP precedence.

Note

The DSCP field definition is backward-compatible with the IP precedence values.

Classification Based on Layer 2 Header

A variety of methods can be used to perform classification based on the Layer 2 header information. The most common methods include the following:

MAC address-based classification (only for access groups)—Classification is based upon the source MAC address (for policies in the input direction) and destination MAC address (for policies in the output direction).

Class-of-Service—Classification is based on the 3 bits in the Layer 2 header based on the IEEE 802.1p standard. This usually maps to the ToS byte in the IP header.

VLAN ID—Classification is based on the VLAN ID of the packet.

Note

Some of these fields in the Layer 2 header can also be set using a policy.

Classification Based on Information that is Device Specific (QoS Groups)

The controller also provides classification mechanisms that are available where classification is not based on information in the packet header or payload.

At times you might be required to aggregate traffic coming from multiple input interfaces into a specific class in the output interface. For example, multiple customer edge routers might be going into the same access controller on different interfaces. The service provider might want to police all the aggregate voice traffic going into the core to a specific rate. However, the voice traffic coming in from the different customers could have a different ToS settings. QoS group-based classification is a feature that is useful in these scenarios.

Policies configured on the input interfaces set the QoS group to a specific value, which can then be used to classify packets in the policy enabled on output interface.

The QoS group is a field in the packet data structure internal to the controller. It is important to note that a QoS group is an internal label to the controller and is not part of the packet header.

Hierarchical Classification

The controller permits you to perform a classification based on other classes. Typically, this action may be required when there is a need to combine the classification mechanisms (that is, filters) from two or more classes into a single class map.

QoS Wired Model

To implement QoS, the controller 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 controller, 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 controller meets a specific traffic profile.

Ingress Port Activity

The following activities occur at the ingress port of the controller:

Classification—Classifying a distinct path for a packet by associating it with a QoS label. For example, the controller maps the CoS or DSCP in the packet to a QoS label to distinguish one type of traffic from another. The QoS label that is generated identifies all future QoS actions to be performed on this packet.

Policing—Policing determines whether a packet is in or out of profile by comparing the rate of the incoming traffic to the configured policer. The policer limits the bandwidth consumed by a flow of traffic. The result is passed to the marker.

Marking—Marking evaluates the policer and configuration information for the action to be taken when a packet is out of profile and determines what to do with the packet (pass through a packet without modification, mark down the QoS label in the packet, or drop the packet).

Note

Applying polices on the wireless ingress port is not supported on the controller.

Egress Port Activity

The following activities occur at the egress port of the controller:

Policing—Policing determines whether a packet is in or out of profile by comparing the rate of the incoming traffic to the configured policer. The policer limits the bandwidth consumed by a flow of traffic. The result is passed to the marker.

Marking—Marking evaluates the policer and configuration information for the action to be taken when a packet is out of profile and determines what to do with the packet (pass through a packet without modification, mark down the QoS label in the packet, or drop the packet).

Queueing—Queueing evaluates the QoS packet label and the corresponding DSCP or CoS value before selecting which of the egress queues to use. Because congestion can occur when multiple ingress ports simultaneously send data to an egress port, Weighted Tail Drop (WTD) differentiates traffic classes and subjects the packets to different thresholds based on the QoS label. If the threshold is exceeded, the packet is dropped.

Classification

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 controller. By default, QoS is enabled on the controller.

During classification, the controller 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.

Access Control Lists

You can use IP standard, IP extended, or Layer 2 MAC ACLs to define a group of packets with the same characteristics (class). You can also classify IP traffic based on IPv6 ACLs.

In the QoS context, the permit and deny actions in the access control entries (ACEs) have different meanings from security ACLs:

If a match with a permit action is encountered (first-match principle), the specified QoS-related action is taken.

If a match with a deny action is encountered, the ACL being processed is skipped, and the next ACL is processed.

If no match with a permit action is encountered and all the ACEs have been examined, no QoS processing occurs on the packet, and the controller offers best-effort service to the packet.

If multiple ACLs are configured on a port, the lookup stops after the packet matches the first ACL with a permit action, and QoS processing begins.

Note

When creating an access list, note that by default the end of the access list contains an implicit deny statement for everything if it did not find a match before reaching the end.

After a traffic class has been defined with the ACL, you can attach a policy to it. A policy might contain multiple classes with actions specified for each one of them. A policy might include commands to classify the class as a particular aggregate (for example, assign a DSCP) or rate-limit the class. This policy is then attached to a particular port on which it becomes effective.

Class Maps

A class map is a mechanism that you use to name a specific traffic flow (or class) and isolate it from all other traffic. The class map defines the criteria used to match against a specific traffic flow to further classify it. The criteria can include matching the access group defined by the ACL or matching a specific list of DSCP or IP precedence values. If you have more than one type of traffic that you want to classify, you can create another class map and use a different name. After a packet is matched against the class-map criteria, you further classify it through the use of a policy map.

You create a class map by using the class-map global configuration command or the class policy-map configuration command. You should use the class-map command when the map is shared among many ports. When you enter the class-map command, the controller enters the class-map configuration mode. In this mode, you define the match criterion for the traffic by using the match class-map configuration command.

You can create a default class by using the classclass-default policy-map configuration command. The default class is system-defined and cannot be configured. Unclassified traffic (traffic that does not meet the match criteria specified in the traffic classes) is treated as default traffic.

Policy Maps

A policy map specifies which traffic class to act on. Actions can include the following:

Setting a specific DSCP or IP precedence value in the traffic class

Setting a CoS value in the traffic class

Setting a QoS group

Setting a wireless LAN (WLAN) value in the traffic class

Specifying the traffic bandwidth limitations and the action to take when the traffic is out of profile

Before a policy map can be effective, you must attach it to a port.

You create and name a policy map using the policy-map global configuration command. When you enter this command, the controller enters the policy-map configuration mode. In this mode, you specify the actions to take on a specific traffic class by using the class or set policy-map configuration and policy-map class configuration commands.

The policy map can also be configured using the police and bandwidth policy-map class configuration commands, which define the policer, the bandwidth limitations of the traffic, and the action to take if the limits are exceeded. In addition, the policy-map can further be configured using the priority policy-map class configuration command, to schedule priority for the class or the queueing policy-map class configuration commands, queue-buffers and queue-limit.

To enable the policy map, you attach it to a port by using the service-policy interface configuration command.

Policy Map on Physical Port

You can configure a nonhierarchical policy map on a physical port that specifies which traffic class to act on. Actions can include setting a specific DSCP or IP precedence value in the traffic class, specifying the traffic bandwidth limitations for each matched traffic class (policer), and taking action when the traffic is out of profile (marking).

A policy map also has these characteristics:

A policy map can contain multiple class statements, each with different match criteria and policers.

A policy map can contain a predefined default traffic class explicitly placed at the end of the map.
When you configure a default traffic class by using the classclass-default policy-map configuration command, unclassified traffic (traffic that does not meet the match criteria specified in the traffic classes) is treated as the default traffic class (class-default).

A separate policy-map class can exist for each type of traffic received through a port.

Policy Map on VLANs

The controller supports a VLAN QoS feature that allows the user to perform QoS treatment at the VLAN level (classification and QoS actions) using the incoming frame’s VLAN information. In VLAN-based QoS, a service policy is applied to an SVI interface. All physical interfaces belonging to a VLAN policy map then need to be programmed to refer to the VLAN-based policy maps instead of the port-based policy map.

Although the policy map is applied to the VLAN SVI, any policing (rate-limiting) action can only be performed on a per-port basis. You cannot configure the policer to take account of the sum of traffic from a number of physical ports. Each port needs to have a separate policer governing the traffic coming into that port.

Wireless QoS Rate
Limiting

QoS per Client
Rate Limit—Wireless

QoS policies can be configured to rate-limit client
traffic using policiers. Ths includes both real-time and non real time traffic.
The non real-time traffic is policed using AFD policiers. These policiers can
only be one rate two color.

Note

For client
policy, the voice and video rate limits are applied at the same time.

QoS Upstream and
Downstream SSID Rate Limit—Wireless

Upstream and
downstream rate limiting is done using policing at the SSID level. AFD cannot
drop real-time traffic, it can only be policed in the traffic queues. Real-time
policing and AFD shaping is performed at the SSID level.
The policiers can only be one rate two color.

The radio has a
default shaping policy. This shaping limit is the physical limit of the radio
itself. You can check the policy maps on the radio by using the
show
policy-map interface wireless radio command.

Note

The controller
does not support the port-shaping rate.

Wireless QoS Multicast

There are two modes of a multicast configuration in the Cisco 5700 Series Wireless Controller:

multicast-unicast mode—Multicast traffic is copied as unicast traffic to the APs. QoS on multicast traffic when multicast-unicast mode is not supported on the Cisco 5700 Series Wireless Controller.

multicast-multicast mode—The controller sends the traffic to the multicast group. The APs in the
multicast group then receive the multicast traffic.

Marking

Marking is used to convey specific information to a downstream device in the network, or to carry information from one interface in a controller 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 controller. Additionally, the marking feature can be used to define mapping between fields. The following marking methods are available for QoS:

Packet Header Marking

Marking on fields in the packet header can be classified into two general categories:

IPv4/v6 header bit marking

Layer 2 header bit marking

The marking feature at the IP level is used to set the precedence or the DSCP in the IP header to a specific value to get a specific per-hop behavior at the downstream device (switch or router), or it can also be used to aggregate traffic from different input interfaces into a single class in the output interface. The functionality is currently supported on both the IPv4 and IPv6 headers.

Marking in the Layer 2 headers is typically used to influence dropping behavior in the downstream devices (switch or router). It works in tandem with the match on the Layer 2 headers. The bits in the Layer 2 header that can be set using a policy map are class of service.

Switch Specific Information Marking

This form of marking includes marking of fields in the packet data structure that are not part of the packets header, so that the marking can be used later in the data path. This is not propagated between the switches. Marking of QoS-group falls into this category. This form of marking is only supported in policies that are enabled on the input interfaces. The corresponding matching mechanism can be enabled on the output interfaces on the same switch and an appropriate QoS action can be applied.

Table Map Marking

Table map marking enables the mapping and conversion from one field to another using a conversion table. This conversion table is called a table map.

Depending upon the table map attached to an interface, CoS, DSCP, and UP values (UP specific to wireless packets) of the packet are rewritten. The controller allows configuring both ingress table map policies and egress table map policies.

As an example, a table map can be used to map the Layer 2 CoS setting to a precedence value in Layer 3. This feature enables combining multiple set commands into a single table, which indicates the method to perform the mapping. This table can be referenced in multiple policies, or multiple times in the same policy.

The following table shows the currently supported forms of mapping:

Table 5 Packet-Marking Types Used for Establishing a To-From Relationship

The To Packet-Marking Type

The From Packet-Marking Type

Precedence

CoS

Precedence

QoS Group

DSCP

CoS

DSCP

QoS Group

CoS

Precedence

CoS

DSCP

QoS Group

Precedence

QoS Group

DSCP

A table map-based policy supports the following capabilities:

Mutation—You can have a table map that maps from one DSCP value set to another DSCP value set, and this can be attached to an egress port.

Rewrite—Packets coming in are rewritten depending upon the configured table map.

Mapping—Table map based policies can be used instead of set policies.

The following steps are required for table map marking:

Define the table map—Use the table-map global configuration command to map the values. The table does not know of the policies or classes within which it will be used. The default command in the table map is used to indicate the value to be copied into the to field when there is no matching from field.

Define the policy map—You must define the policy map where the table map will be used.

Associate the policy to an interface.

Note

A table map policy on an input port changes the trust setting of that port to the from type of qos-marking.

Traffic Conditioning

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.

This table compares the policing and shaping functions.

Table 6 Comparison Between Policing and Shaping Functions

Policing Function

Shaping Function

Sends conforming traffic up to the line rate and allows bursts.

Smooths traffic and sends it out at a constant rate.

When tokens are exhausted, action is taken immediately.

When tokens are exhausted, it buffers packets and sends them out later, when tokens are available. A class with shaping has a queue associated with it which will be used to buffer the packets.

Policing has multiple units of configuration – in bits per second, packets per second and cells per second.

Shaping has only one unit of configuration - in bits per second.

Policing has multiple possible actions associated with an event, marking and dropping being example of such actions.

Shaping does not have the provision to mark packets that do not meet the profile.

Works for both input and output traffic.

Implemented for output traffic only.

Transmission Control Protocol (TCP) detects the line at line speed but adapts to the configured rate when a packet drop occurs by lowering its window size.

TCP can detect that it has a lower speed line and adapt its retransmission timer accordingly. This results in less scope of retransmissions and is TCP-friendly.

Policing

The QoS policing feature is used to impose a maximum rate on a traffic class. The QoS policing feature can also be used with the priority feature to restrict priority traffic. If the rate is exceeded, then a specific action is taken as soon as the event occurs. The rate (committed information rate [CIR] and peak information rate [PIR] ) and the burst parameters (conformed burst size [ Bc ] and extended burst size [Be] ) are all configured in bytes per second.

Single-Rate Two-Color Policing

Single-rate two-color policer is the mode in which you configure only a CIR and a Bc.

The Bc is an optional parameter, and if it is not specified it is computed by default. In this mode, when an incoming packet has enough tokens available, the packet is considered to be conforming. If at the time of packet arrival, enough tokens are not available within the bounds of Bc, the packet is considered to have exceeded the configured rate.

Dual-Rate Three-Color Policing

With the dual rate policer, the controller supports only color-blind mode. In this mode, you configure a committed information rate (CIR) and a peak information rate (PIR). As the name suggests, there are two token buckets in this case, one for the peak rate, and one for the conformed rate.

In the color-blind mode, the incoming packet is first checked against the peak rate bucket. If there are not enough tokens available, the packet is said to violate the rate. If there are enough tokens available, then the tokens in the conformed rate buckets are checked to determine if there are enough tokens available. The tokens in the peak rate bucket are decremented by the size of the packet. If it does not have enough tokens available, the packet is said to have exceeded the configured rate. If there are enough tokens available, then the packet is said to conform, and the tokens in both the buckets are decremented by the size of the packet.

The rate at which tokens are replenished depends on the packet arrival. Assume that a packet comes in at time T1 and the next one comes in at time T2. The time interval between T1 and T2 determines the number of tokens that need to be added to the token bucket. This is calculated as:

Shaping

Shaping is the process of imposing a maximum rate of traffic, while regulating the traffic rate in such a way that the downstream switches and routers are not subjected to congestion. Shaping in the most common form is used to limit the traffic sent from a physical or logical interface.

Shaping has a buffer associated with it that ensures that packets which do not have enough tokens are buffered as opposed to being immediately dropped. The number of buffers available to the subset of traffic being shaped is limited and is computed based on a variety of factors. The number of buffers available can also be tuned using specific QoS commands. Packets are buffered as buffers are available, beyond which they are dropped.

Class-Based Traffic Shaping

The controller uses class-based traffic shaping. This shaping feature is enabled on a class in a policy that is associated to an interface. A class that has shaping configured is allocated a number of buffers to hold the packets that do not have tokens. The buffered packets are sent out from the class using FIFO. In the most common form of usage, class-based shaping is used to impose a maximum rate for an physical interface or logical interface as a whole. The following shaping forms are supported in a class:

Average rate shaping

Hierarchical shaping

Shaping is implemented using a token bucket. The values of CIR, Bc and Be determine the rate at which the packets are sent out and the rate at which the tokens are replenished.

Average Rate Shaping

You use the shape average policy-map class command to configure average rate shaping.

This command configures a
maximum bandwidth for a particular class. The queue bandwidth is restricted to this value even though the port has more bandwidth
available. The controller supports
configuring shape average by either a percentage or by a target bit rate value.

Hierarchical Shaping

Shaping can also be configured at multiple levels in a hierarchy. This is accomplished by creating a parent policy with shaping configured, and then attaching child policies with additional shaping configurations to the parent policy.

There are two supported types of hierarchical shaping:

Port shaper

User-configured shaping

The port shaper uses the class default and the only action permitted in the parent is shaping. The queueing action is in the child with the port shaper. With the user configured shaping, you cannot have queueing action in the child.

Bandwidth

Bandwidth Percent

You can use the bandwidth percent policy-map class command to allocate a minimum bandwidth to a particular class.
The total sum cannot exceed 100 percent and
in case the total sum is less than 100 percent, then the rest of the bandwidth is divided equally
among all bandwidth queues.

Note

A queue can oversubscribe bandwidth in case the
other queues do not utilize the entire port bandwidth.

You cannot mix bandwidth types on a policy map. For example, you cannot configure bandwidth in a single policy map using both a bandwidth percent and in kilobits per second.

Bandwidth Remaining Ratio

You use the bandwidth remaining ratio
policy-map class command to create a ratio for sharing unused bandwidth in specified queues. Any unused bandwidth will be used by these specific queues in the ratio that is specified by the configuration. Use this command when
the priority command is also used for certain queues in the
policy.

When you assign ratios, the queues will be assigned certain weights which are
inline with these ratios.

You can specify ratios using a range from 0 to 100.
For example, you can configure a bandwidth remaining ration of 2 on one class, and another queue with a bandwidth remaining ratio of 4 on another class. The bandwidth remaining ratio of 4 will be scheduled twice as often as the bandwidth remaining ratio of 2.

The total bandwidth ratio allocation for the policy can
exceed 100. For example, you can configure a queue with a bandwidth remaining ratio of 50, and another queue with a bandwidth remaining ratio of 100.

Weighted Tail Drop

The controller egress queues use an enhanced version of the tail-drop congestion-avoidance mechanism called weighted tail drop (WTD). WTD is implemented on queues to manage the queue lengths and to provide drop precedences for different traffic classifications.

As a frame is enqueued to a particular queue, WTD uses the frame’s assigned QoS label to subject it to different thresholds. If the threshold is exceeded for that QoS label (the space available in the destination queue is less than the size of the frame), the controller drops the frame.

Each queue has three configurable threshold values. The QoS label determines which of the three threshold values is subjected to the frame.

Figure 4. WTD and Queue Operation. The following figure shows an example of WTD operating on a queue whose size is 1000 frames. Three drop percentages are configured: 40 percent (400 frames), 60 percent (600 frames), and 100 percent (1000 frames). These percentages indicate that up to 400 frames can be queued at the 40-percent threshold, up to 600 frames at the 60-percent threshold, and up to 1000 frames at the 100-percent threshold.

In the example, CoS value 6 has a greater importance than the other CoS values, and is assigned to the 100-percent drop threshold (queue-full state). CoS values 4 is assigned to the 60-percent threshold, and CoS values 3 is assigned to the 40-percent threshold. All of these threshold values are assigned using the queue-limit cos command.

Assuming the queue is already filled with 600 frames, and a new frame arrives. It contains CoS value 4 and is subjected to the 60-percent threshold. If this frame is added to the queue, the threshold will be exceeded, so the controller drops it.

Weighted Tail Drop Default Values

The following are the Weighted Tail Drop (WTD) default values and the rules for configuring WTD threshold values.

If you configure less than three queue-limit percentages for WTD, then WTD default values are assigned to these thresholds.

The following are the WTD threshold default values:

Table 7 WTD Threshold Default Values

Threshold

Default Value Percentage

0

80

1

90

2

400

If 3 different WTD thresholds are configured, then the queues are programmed as configured.

If 2 WTD thresholds are configured, then the maximum value percentage will be 400.

If a WTD single threshold is configured as x, then the maximum value percentage will be 400.

If the value of x is less than 90, then threshold1=90 and threshold 0= x.

If the value of x equals 90, then threshold1=90, threshold 0=80.

If the value x is greater than 90, then threshold1=x, threshold 0=80.

Priority Queues

Each port supports eight egress queues, of which two can be given a priority.

You use the priority level policy class-map command to configure the priority for two classes. One of the classes has to be configured with a priority queue level 1, and the other class has to be configured with a priority queue level 2. Packets on these two queues are subjected to less latency with respect to
other queues.

Queue Buffer

Each 1-gigabit port on the controller is allocated 168 buffers for a wireless port and 300 buffers for a wired port. Each 10-gigabit port is allocated 1800 buffers. At boot time, when there is no policy map enabled on the wired port, there are two queues created by default. Wired ports can have a maximum of 8 queues configured using MQC-based policies. The following table shows which packets go into which one of the queues:

Table 8 DSCP, Precedence, and CoS - Queue Threshold Mapping Table

DSCP, Precedence or CoS

Queue

Threshold

Control Packets

0

2

Rest of Packets

1

2

Note

You can guarantee the availability of buffers, set drop thresholds, and configure the maximum memory allocation for a queue. You use the queue-buffers policy-map class command to configure the queue buffers. You use the queue-limit policy-map class command to configure the maximum thresholds.

There are two types of buffer allocations: hard buffers, which are explicitly reserved for the queue, and soft buffers, which are available for other ports when unused by a given port.

For the wireless port default, Queue 0 will be given 40 percent of the buffers that are available for the interface as hard buffers, that is 67 buffers are allocated for Queue 0 in the context of 1-gigabit ports. The soft maximum for this queue is set to 268 (calculated as 67 * 400/100) for 1-gigabit ports, where 400 is the default maximum threshold that is configured for any queue.

For the wired port default, Queue 0 will be given 40 percent of the buffers that are available for the interface as hard buffers, that is 120 buffers are allocated for Queue 0 in the context of 1-gigabit ports, and 720 buffers in the context of 10-gigabit ports. The soft maximum for this queue is set to 480 (calculated as 120 * 400/100) for 1-gigabit ports and 2880 for 10-gigabit ports, where 400 is the default maximum threshold that is configured for any queue.

Queue 1 does not have any hard buffers allocated. The default soft buffer limit is set to 400 (which is the maximum threshold). The threshold would determine the maximum number of soft buffers that can be borrowed from the common pool.

Dynamic Threshold and Scaling

Traditionally, reserved buffers are statically allocated for each queue. No matter whether the queue is active or not, its buffers are held up by the queue. In addition, as the number of queues increases, the portion of the reserved buffers allocated for each queue can become smaller and smaller. Eventually, a situation may occur where there are not enough reserved buffers to support a jumbo frame for all queues.

The controller supports Dynamic Thresholding and Scaling (DTS), which is a feature that provides a fair and efficient allocation of buffer resources. When congestion occurs, this DTS mechanism provides an elastic buffer allocation for the incoming data based on the occupancy of the global/port resources. Conceptually, DTS scales down the queue buffer allocation gradually as the resources are used up to leave room for other queues, and vice versa. This flexible method allows the buffers to be more efficiently and fairly utilized.

As mentioned in the previous sections, there are two limits configured on a queue—a hard limit and a soft limit.

Hard limits are not part of DTS. These buffers are available only for that queue. The sum of the hard limits should be less than the globally set up hard maximum limit. The global hard limit configured for egress queuing is currently set to 5705. In the default scenario when there are no MQC policies configured, the 24 1-gigabit ports would take up 24 * 67 = 1608, and the 4 10-gigabit ports would take up 4 * 720 = 2880, for a total of 4488 buffers, allowing room for more hard buffers to be allocated based upon the configuration.

Soft limit buffers participate in the DTS process. Additionally, some of the soft buffer allocations can exceed the global soft limit allocation. The global soft limit allocation for egress queuing is currently set to 7607. The sum of the hard and soft limits add up to 13312, which in turn translates to 3.4 MB. Because the sum of the soft buffer allocations can exceed the global limit, it allows a specific queue to use a large number of buffers when the system is lightly loaded. The DTS process dynamically adjusts the per-queue allocation as the system becomes more heavily loaded.

Queuing in Wireless

Queuing in the wireless component is performed based on the port policy and is applicable only in the downstream direction. The wireless module supports the following four queues:

Voice—This is a strict priority queue. Represented by Q0, this queue processes control traffic and multicast or unicast voice traffic. All control traffic (such as CAPWAP packets) is processed through the voice queue. The QoS module uses a different threshold within the voice queue to process control and voice packets to ensure that control packets get higher priority over other non-control packets.

Multicast NRT—Represented by Q3, this queue processes Multicast NRT traffic. Any traffic that does not match the traffic in Q0, Q1, or Q2 is processed through Q3.

Note

By default, the queues Q0 and Q1 are not enabled.

Note

A weighted round-robin policy is applied for traffic in the queues Q2 and Q3.

For upstream direction only one queue is available. Port and radio policies are applicable only in the downstream direction.

Trust Behavior

Trust Behavior for
Wired and Wireless Ports

For wired or wireless ports that are connected to the
controller (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
controller 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
controller is done by default. This is true for
unicast and multicast packets.

In scenarios where
the incoming packet type differs from the outgoing packet type, the trust
behavior and the queuing behavior are explained in the following table. Note
that the default trust mode for a port is DSCP based. The trust mode ‘falls
back’ to CoS if the incoming packet is a pure Layer 2 packet. You can also
change the trust setting from DSCP to CoS. This setting change is accomplished
by using an MQC policy that has a class default with a 'set cos cos table
default default-cos' action, where default-cos is the name of the table map
created (which only performs a default copy).

Table 9 Trust and Queueing
Behavior

Incoming
Packet

Outgoing
Packet

Trust Behavior

Queuing
Behavior

Layer 3

Layer 3

Preserve
DSCP/Precedence

Based on DSCP

Layer 2

Layer 2

Not applicable

Based on CoS

Tagged

Tagged

Preserve DSCP
and CoS

Based on DSCP
(trust DSCP takes precedence)

Layer 3

Tagged

Preserve DSCP,
CoS is set to 0

Based on DSCP

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
controller came up, all markings for the wireless
ports were defaulted to zero and no traffic received priority treatment. For
compatibility with an existing wired
controller, 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
qoswirelessdefaultuntrust 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
noqos
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
controller, 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.

Port Security on a
Trusted Boundary for Cisco IP Phones

In
a typical network, you connect a Cisco IP Phone to a
controller 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
controller 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
controller 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
controller port to which the telephone is connected to
trust the traffic received on that port.

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
controller. Without trusted boundary, the CoS labels
generated by the PC are trusted by the
controller (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
controller port. If the telephone is not detected, the
trusted boundary feature disables the trusted setting on the
controller 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
controller.

Wireless QoS Mobility

Wireless QoS mobility enables you to configure QoS policies so that the network provides the same service anywhere in the network. A wireless client can roam from one location to another and as a result the client can get associated to different access points associated with a different controller. Wireless client roaming can be classified into two types:

Intra-controller roaming

Inter-controller roaming

Note

The client policies must be available on all of the controllers in the mobility group. The same SSID and port policy must be applied to all controllers in the mobility group so that the clients get consistent treatment.

Inter-Controller Roaming

When a client roams from one location to another, the client can get associated to access points either associated to the same controller (anchor controller) or a different controller (foreign controller). Inter-controller roaming refers to the scenario where the client gets associated to an access point that is not associated to the same device before the client roamed. The host device is now foreign to the device to which the client was initially anchored.

In the case of inter-controller roaming, the client QoS policy is always executed on the foreign controller. When a client roams from anchor controller to foreign controller, the QoS policy is uninstalled on the anchor controller and installed on the foreign controller. In the mobility handoff message, the anchor device passes the name of the policy to the foreign controller. The foreign controller should have a policy with the same name configured for the QoS policy to be applied correctly.

In the case of inter-controller roaming, all of the QoS policies are moved from the anchor device to the foreign device. While the QoS policies are in transition from the anchor device to the foreign device, the traffic on the foreign device is provided the default treatment. This is comparable to a new policy installation on the client target.

Note

If the foreign device is not configured with the user-defined physical port policy, the default port policy is applicable to all traffic is routed through the NRT queue, except the control traffic which goes through RT1 queue. The network administrator must configure the same physical port policy on both the anchor and foreign devices symmetrically.

Intra-Controller Roaming

With intra-controller roaming, the client gets associated to an access point that is associated to the same controller before the client roamed, but this association to the device occurs through a different access point.

Note

QoS policies remain intact in the case of intra-controller roaming.

Precious Metal Policies for Wireless QoS

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:

Platinum—Used for VoIP clients.

Gold—Used for video clients.

Silver— Used for traffic that can be considered best-effort.

Bronze—Used for NRT traffic.

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 controller 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 controller platform.

Note

The 802.1p protocol priority is applicable on the Cisco 5700 Series Wireless Controller.

Default Wired QoS Configuration

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

DSCP Maps

Default CoS-to-DSCP Map

You use the CoS-to-DSCP map to map CoS values in incoming packets to a DSCP value that QoS uses internally to represent the priority of the traffic. The following table shows the default CoS-to-DSCP map. If these values are not appropriate for your network, you need to modify them.

Table 10 Default CoS-to-DSCP Map

CoS Value

DSCP Value

0

0

1

8

2

16

3

24

4

32

5

40

6

48

7

56

Default IP-Precedence-to-DSCP Map

You use the IP-precedence-to-DSCP map to map IP precedence values in incoming packets to a DSCP value that QoS uses internally to represent the priority of the traffic. The following table shows the default IP-precedence-to-DSCP map. If these values are not appropriate for your network, you need to modify them.

Table 11 Default IP-Precedence-to-DSCP Map

IP Precedence Value

DSCP Value

0

0

1

8

2

16

3

24

4

32

5

40

6

48

7

56

Default DSCP-to-CoS Map

You use the DSCP-to-CoS map to generate a CoS value, which is used to select one of the four egress queues. The following table shows the default DSCP-to-CoS map. If these values are not appropriate for your network, you need to modify them.

Table 12 Default DSCP-to-CoS Map

DSCP Value

CoS Value

0–7

0

8–15

1

16–23

2

24–31

3

32–39

4

40–47

5

48–55

6

56–63

7

Restrictions for QoS
on Wired Targets

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
controller to the wireless client. Upstream
indicates that traffic is flowing from wireless client to the
controller.

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

A maximum of 8
queuing classes are supported on the
controller 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
controller because the
queue-buffer
command handles this functionality. Queue limit is only supported with the DSCP
and CoS extensions.

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.

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.

Classification counters have the following specific
restrictions:

Classification counters count packets instead of bytes.

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
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. '.

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.

Restrictions for QoS
on Wireless Targets

General
Restrictions

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
controller to the wireless client. Upstream
indicates that traffic is flowing from wireless client to the
controller.

Only port, SSID,
and client (using AAA and Cisco IOS command-line interface) policies are
user-configurable. Radio policies are set by the wireless control module and
are not user-configurable.

Port and radio
policies are applicable only in the downstream direction.

SSID and client
support non-queuing policies in the upstream direction.
SSID and
client targets can be configured with marking and policing policies.

One policy per
target per direction is supported.

Policer based markdown
actions are only supported using table maps. Only one markdown table map is
allowed for each marking field in the controller.

For the egress class-default SSID policy, you must
configure the queue buffer ratio as 0 after you configure the average shape
rate.

Wireless QoS
Restrictions on SSID

The following are
restrictions for applying QoS features on SSID:

One table map
is supported at the ingress policy.

Table maps are
supported for the parent class-default only. Up to two table maps are supported
in the egress direction and three table-maps can be configured when a QoS group
is involved.

Note

Table-maps are
not supported at the client targets.

Policing
without priority is not supported in the egress direction.

Priority
configuration at the SSID level is used only to configure the RT1 and RT2
policers (AFD for policer). Priority configuration does not include the shape
rate. Therefore, priority is restricted for SSID policies without police.

The mapping in
the DSCP2DSCP and COS2COS table should be based on the classification function
for the voice and video classes in the port level policy.

No
action is allowed under the class-default of a child policy.

Wireless QoS
Restrictions on Clients

The
following are restrictions for applying QoS policies on client targets:

The default client policy is enabled only on WMM clients that are
ACM-enabled.

Queuing is not
supported.

Attaching,
removing, or modifying client policies on a WLAN in the enabled state is not
supported. You must shut down the WLAN to apply, remove, or modify a policy.

Table-map
configuration is not supported for client targets.

Policing and set configured together in
class-default is blocked in both the upstream and downstream direction:

policy-map foo
class class-default
police X
set dscp Y

Child policy
is not supported under class-default if the parent policy contains other
user-defined class maps in it.

For flat
egress client policy, policing in class-default and marking action in other
classes are not supported.

Restrictions for ACLs

All the filters in classes in a policy map for client policy must
have the same attributes. Filters matching on protocol-specific attributes such
as IPv4 or IPv6 addresses are considered as different attribute sets.

If an ingress SSID policy is configured along with
an ingress client policy matching ACLs with port ranges, the SSID policy takes
precedence over the client policy. As a result, the client policy will not take
effect.

For filters matching on ACLs, all ACEs (Access Control Entry) in
the access list should have the same type and number of attributes. For
example, the following is an invalid access list as they match on different
attributes:

For filters matching on marking attributes, all filters in the
policy-map must match on the same marking attribute. For example, If filter
matches on DSCP, then all filters in the policy must match on DSCP.

Restrictions for AVC QoS Policies

AVC is supported only on
the following access points:

Cisco Aironet 1600 Series
Access Points

Cisco Aironet 2600 Series
Wireless Access Points

Cisco Aironet 3600 Series
Access Points

When there is
a mix of AVC-enabled APs such as 3600 and non-AVC-enabled APs such as 1140, and
the chosen policy for the client is AVC-enabled, the policy will not be sent to
the APs that are not capable of supporting AVC.

Creating a Traffic
Policy
(CLI)

To create a traffic
policy, use the
policy-map
global configuration command to specify the traffic policy name.

The traffic class
is associated with the traffic policy when the
class command
is used. The
class command
must be entered after you enter the policy map configuration mode. After
entering the
class
command, the
controller is automatically in policy map class
configuration mode, which is where the QoS policies for the traffic policy are
defined.

This procedure
describes the available configurations using
set command
options. The other command options (admit,
bandwidth,
etc.) are described in other sections of this guide. Although this task lists
all of the possible
set commands,
only one
set command is
supported per class.

(Optional)
Sets the WLAN user priority value. You can set the following values using this
command:

wlan
user-priority value—A value between 0 to 7.

cos
table—Sets the WLAN user priority value from CoS based on a table map.

dscp
table—Sets the WLAN user priority value from DSCP based on a table map.

qos-group
table—Sets the WLAN user priority value from QoS group based on a table
map.

wlan
table—Sets the WLAN user priority value from the WLAN user priority based
on a table map.

Step 10

end

Example:

Controller(config-pmap)# endController#

Saves
configuration changes.

Step 11

show policy-map

Example:

Controller# show policy-map

(Optional)
Displays policy configuration information for all classes configured for all
service policies.

What to Do Next

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

Configuring Class
Maps for Voice and Video
(CLI)

To configure class
maps for voice and video traffic, follow these steps:

SUMMARY STEPS

1.configureterminal

2.class-mapclass-map-name

3.matchdscpdscp-value-for-voice

4.end

5.configureterminal

6.class-mapclass-map-name

7.matchdscpdscp-value-for-video

8.end

DETAILED STEPS

Command or Action

Purpose

Step 1

configureterminal

Example:

Controller# configure terminal

Enters global configuration mode.

Step 2

class-mapclass-map-name

Example:

Controller(config)# class-map voice

Creates a class
map.

Step 3

matchdscpdscp-value-for-voice

Example:

Controller(config-cmap)# match dscp 46

Matches the DSCP
value in the IPv4 and IPv6 packets. Set this value to 46.

Step 4

end

Example:

Controller(config)# end

Returns to privileged EXEC mode. Alternatively, you can also press Ctrl-Z to exit global configuration mode.

Step 5

configureterminal

Example:

Controller# configure terminal

Enters global configuration mode.

Step 6

class-mapclass-map-name

Example:

Controller(config)# class-map video

Configures a
class map.

Step 7

matchdscpdscp-value-for-video

Example:

Controller(config-cmap)# match dscp 34

Matches the DSCP
value in the IPv4 and IPv6 packets. Set this value to 34.

Step 8

end

Example:

Controller(config)# end

Returns to privileged EXEC mode. Alternatively, you can also press Ctrl-Z to exit global configuration mode.

Attaching a Traffic
Policy to an Interface
(CLI)

After the traffic
class and traffic policy are created, you must use the
service-policy
interface configuration command to attach a traffic policy to an interface, and
to specify the direction in which the policy should be applied (either on
packets coming into the interface or packets leaving the interface).

Before You Begin

A
traffic class and traffic policy must be created before attaching a traffic
policy to an interface.

If a traffic
class has already been defined by using the
class-map
global configuration command, specify its name for
class-map-name in this command.

A
class-default traffic class is predefined and can
be added to any policy. It is always placed at the end of a policy map. With an
implied
match any included in the
class-default class, all packets that have not
already matched the other traffic classes will match
class-default.

If a traffic
class has already been defined by using the
class-map
global configuration command, specify its name for
class-map-name in this command.

A
class-default traffic class is predefined and can
be added to any policy. It is always placed at the end of a policy map. With an
implied
match any included in the
class-default class, all packets that have not
already matched the other traffic classes will match
class-default.

Configuring Table
Maps
(CLI)

Table
maps are a form of marking, and also enable the mapping and conversion of one
field to another using a table. For example, a table map can be used to map and
convert a Layer 2 CoS setting to a precedence value in Layer 3.

Note

A table map can be
referenced in multiple policies or multiple times in the same policy.

Creates a table
map and enters the table map configuration mode. In table map configuration
mode, you can perform the following tasks:

default—Configures the
table map default value, or sets the default behavior for a value not found in
the table map to copy or ignore.

exit—Exits from the
table map configuration mode.

map—Maps a
from
to a
to
value in the table map.

no—Negates or sets the
default values of the command.

Step 3

mapfromvaluetovalue

Example:

Controller(config-tablemap)# map from 0 to 2Controller(config-tablemap)# map from 1 to 4Controller(config-tablemap)# map from 24 to 3Controller(config-tablemap)# map from 40 to 6Controller(config-tablemap)# default 0Controller(config-tablemap)#

In this step,
packets with DSCP values 0 are marked to the CoS value 2, DSCP value 1 to the
CoS value 4, DSCP value 24 to the CoS value 3, DSCP value 40 to the CoS value 6
and all others to the CoS value 0.

Note

The mapping
from CoS values to DSCP values in this example is configured by using the
set policy
map class configuration command as described in a later step in this procedure.

Step 4

exit

Example:

Controller(config-tablemap)# exitController(config)#

Returns to
global configuration mode.

Step 5

exit

Example:

Controller(config) exitController#

Returns to
privileged EXEC mode.

Step 6

show table-map

Example:

Controller# show table-map
Table Map table01
from 0 to 2
from 1 to 4
from 24 to 3
from 40 to 6
default 0

Configuring Trust
Behavior for Wireless Traffic
(CLI)

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
controller came up, all markings for the wireless
ports were defaulted to zero and no traffic received priority treatment. For
compatibility with an existing wired
controller, 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.

SUMMARY STEPS

1.configureterminal

2.qoswireless-default-untrust

3.end

DETAILED STEPS

Command or Action

Purpose

Step 1

configureterminal

Example:

Controller# configure terminal

Enters global configuration mode.

Step 2

qoswireless-default-untrust

Example:

Controller (config)# qos wireless-default-untrust

Configures the
behavior of the
controller to untrust wireless traffic. To
configure the
controller to trust wireless traffic by default,
use the
no form of the
command.

Step 3

end

Example:

Controller(config)# end

Returns to privileged EXEC mode. Alternatively, you can also press Ctrl-Z to exit global configuration mode.

The
priority
command assigns a strict scheduling priority for the class.

Note

Priority
level 1 is more important than priority level 2. Priority level 1 reserves
bandwidth that is processed first for QoS, so its latency is very low. Both
priority level 1 and 2 reserve bandwidth.

Step 17

police [target_bit_rate|
cir| rate]

Example:

Controller(config-pmap-c)# police cir 10m

(Optional)
Configures the policer:

target_bit_rate—Specifies the bit rate per second. Enter a
value between 8000 and 10000000000.

The
priority
command assigns a strict scheduling priority for the class.

Note

Priority
level 1 is more important than priority level 2. Priority level 1 reserves
bandwidth that is processed first for QoS, so its latency is very low. Both
priority level 1 and 2 reserve bandwidth.

Step 25

police [target_bit_rate|
cir| rate]

Example:

Controller(config-pmap-c)# police cir 20m

(Optional)
Configures the policer:

target_bit_rate—Specifies the bit rate per second. Enter a
value between 8000 and 10000000000.

Kb/s—Configures a
specific value in kilobits per second (from 20000 to 10000000).

percent-—Allocates
minimum bandwidth to a particular class based on a percentage. The queue can
oversubscribe bandwidth in case other queues do not utilize the entire port
bandwidth. The total sum cannot exceed 100 percent, and in case it is less than
100 percent, the rest of the bandwidth is equally divided along all bandwidth
queues.

remaining— Allocates
minimum bandwidth to a particular class. The queue can oversubscribe bandwidth
in case other queues do not utilize entire port bandwidth. The total sum cannot
exceed 100 percent. It is preferred to use this command when the
priority
command is used for certain queues in the policy. You can also assign ratios
rather than percentages to each queue; the queues will be assigned certain
weights which are inline with these ratios. Ratios can range from 0 to 100.
Total bandwidth ratio allocation for the policy in this case can exceed 100.

Note

You
cannot mix bandwidth types on a policy map. For example, you cannot configure
bandwidth in a single policy map using both a bandwidth percent and in kilobits
per second.

Step 5

end

Example:

Controller(config-pmap-c)# endController#

Saves
configuration changes.

Step 6

show policy-map

Example:

Controller# show policy-map

(Optional)
Displays policy configuration information for all classes configured for all
service policies.

What to Do Next

Configure any
additional policy maps for QoS for your network. After creating the policy
maps, attach the traffic policy or polices to an interface using the
service-policy command.

The
priority
command assigns a strict scheduling priority for the class.

The command
options include:

Kb/s—Specifies the
kilobits per second (from 1 to 2000000).

burst_in_bytes—Specifies the burst in bytes (from 32 to
2000000).

levellevel_value—Specifies the multilevel (1-2) priority queue.

Kb/s—Specifies the
kilobits per second (from 1 to 2000000).

burst_in_bytes—Specifies the burst in bytes (from 32 to
2000000).

percent—Percentage of
the total bandwidth.

burst_in_bytes—Specifies the burst in bytes (from 32 to
2000000).

percent—Percentage of
the total bandwidth.

burst_in_bytes—Specifies the burst in bytes (32 to 2000000).

Note

Priority
level 1 is more important than priority level 2. Priority level 1 reserves
bandwidth that is processed first for QoS, so its latency is very low. Both
priority level 1 and 2 reserve bandwidth.

Step 5

end

Example:

Controller(config-pmap-c)# endController#

Saves
configuration changes.

Step 6

show policy-map

Example:

Controller# show policy-map

(Optional)
Displays policy configuration information for all classes configured for all
service policies.

What to Do Next

Configure any
additional policy maps for QoS for your network. After creating your policy
maps, attach the traffic policy or polices to an interface using the
service-policy command.

Configuring Egress Queue Characteristics

Depending on the complexity of your network and your QoS solution, you may need to perform all of the procedures in this section. You need to make decisions about these characteristics:

Which packets are mapped by DSCP, CoS, or QoS group value to each queue and threshold ID?

What drop percentage thresholds apply to the queues, and how much reserved and maximum memory is needed for the traffic type?

How much of the fixed buffer space is allocated to the queues?

Does the bandwidth of the port need to be rate limited?

How often should the egress queues be serviced and which technique (shaped, shared, or both) should be used?

Note

You can only configure the egress queues on the controller.

Configuring Queue
Buffers
(CLI)

The
controller allows you to allocate buffers to queues.
If there is no allocation made to buffers, then they are divided equally for
all queues. You can use the queue-buffer ratio to divide it in a particular
ratio. Since by default DTS (Dynamic Threshold and Scaling) is active on all
queues, these are soft buffers.

Note

The queue-buffer
ratio is supported on both wired and wireless ports, but the queue-buffer ratio
cannot be configured with a queue-limit.

Before You Begin

The following are
prerequisites for this procedure:

You should have
created a class map for the queue buffer before beginning this procedure.

You must have
configured either bandwidth, shape, or priority on the policy map prior to
configuring the queue buffers.

Configures
the bandwidth for the policy map. The command parameters include:

Kb/s—Use this command
to configure a specific value. The range is 20000 to 10000000.

percent—Allocates a
minimum bandwidth to a particular class using a percentage. The queue can
oversubscribe bandwidth in case other queues do not utilize the entire port
bandwidth. The total sum cannot exceed 100 percent, and in case it is less than
100 percent, the rest of the bandwidth is equally divided along all bandwidth
queues.

remaining—Allocates a
minimum bandwidth to a particular class. The queue can oversubscribe bandwidth
in case other queues do not utilize entire port bandwidth. The total sum cannot
exceed 100 percent. It is preferred to use this command when the
priority
command is used for certain queues in the policy. You can also assign ratios
rather than a percentage to each queue; the queues will be assigned certain
weights that are inline with these ratios. Ratios can range from 0 to 100.
Total bandwidth ratio allocation for the policy in this case can exceed 100.

Configuring Queue
Limits
(CLI)

You use queue
limits to configure Weighted Tail Drop (WTD). WTD ensures the configuration of
more than one threshold per queue. Each class of service is dropped at a
different threshold value to provide for QoS differentiation. With the
controller, each queue has 3 explicit programmable
threshold classes—0, 1, 2. Therefore, the enqueue/drop decision of each packet
per queue is determined by the packet’s threshold class assignment, which is
determined by the DSCP, CoS, or QoS group field of the frame header.

WTD also uses a soft
limit, and therefore you are allowed to configure the queue limit to up to 400
percent (maximum four times the reserved buffer from common pool). This soft
limit prevents overrunning the common pool without impacting other features.

Note

You
can only configure queue limits on the
controller egress queues on wired ports.

Before You Begin

The following are
prerequisites for this procedure:

You should have
created a class map for the queue limits before beginning this procedure.

You must have
configured either bandwidth, shape, or priority on the policy map prior to
configuring the queue limits.

Kb/s—Use this command
to configure a specific value. The range is 20000 to 10000000.

percent—Allocates a minimum bandwidth to a particular class.
The queue can oversubscribe bandwidth in case other queues do not utilize the
entire port bandwidth. The total sum cannot exceed 100 percent, and in case it
is less than 100 percent, the rest of the bandwidth is equally divided along
all bandwidth queues.

remaining—Allocates a
minimum bandwidth to a particular class. The queue can oversubscribe bandwidth
in case other queues do not utilize entire port bandwidth. The total sum cannot
exceed 100 percent. It is preferred to use this command when the
priority
command is used for certain queues in the policy. You can also assign ratios
rather than a percentage to each queue; the queues will be assigned certain
weights that are inline with these ratios. Ratios can range from 0 to 100.
Total bandwidth ratio allocation for the policy in this case can exceed 100.

With every
queue, there are three thresholds (0,1,2), and there are default values for
each of these thresholds. Use this command to change the default or any other
queue limit threshold setting. For example, if DSCP 3, 4, and 5 packets are
being sent into a specific queue in a configuration, then you can use this
command to set the threshold percentages for these three DSCP values. For
additional information about queue limit threshold values, see
Weighted Tail Drop.

Note

The
controller does not support absolute queue-limit
percentages. The
controller only supports DSCP or CoS queue-limit
percentages.

Step 6

end

Example:

Controller(config-pmap-c)# endController#

Saves
configuration changes.

Step 7

show policy-map

Example:

Controller# show policy-map

(Optional)
Displays policy configuration information for all classes configured for all
service policies.

What to Do Next

Proceed to
configure any additional policy maps for QoS for your network. After creating
your policy maps, proceed to attach the traffic policy or polices to an
interface using the
service-policy command.

Configuring Shaping
(CLI)

You
use the
shape command
to configure shaping (maximum bandwidth) for a particular class. The queue's
bandwidth is restricted to this value even though the port has additional
bandwidth left. You can configure shaping as an average percent, as well as a
shape average value in bits per second.

Before You Begin

You should have
created a class map for shaping before beginning this procedure.

Configuring Precious
Metal Policies
(CLI)

You can configure precious
metal QoS policies on a per-WLAN basis.
SUMMARY STEPS

1.configureterminal

2.wlanwlan-name

3.service-policyoutputpolicy-name

4.end

5.showwlan{wlan-id|wlan-name}

DETAILED STEPS

Command or Action

Purpose

Step 1

configureterminal

Example:

Controller# configure terminal

Enters global command mode.

Step 2

wlanwlan-name

Example:

Controllerwlan test4

Enters the WLAN configuration submode.

Step 3

service-policyoutputpolicy-name

Example:

Controller(config-wlan)# service-policy output platinum

Example:

Controller(config-wlan)# service-policy input platinum-up

Configures the
WLAN with the QoS policy. To configure the WLAN with precious metal policies,
you must enter one of the following keywords:
platinum,
gold,
silver, or
bronze.
The upstream policy is specified with the keyword platinum-up as shown in the example.

Note

Upstream policies
differ from downstream policies. The upstream policies have a suffix of -up.

Step 4

end

Example:

Controller(config)# end

Returns to privileged EXEC mode. Alternatively, you can also press Ctrl-Z to exit the global configuration mode.

After creating a class map by using a DSCP or precedence values, you then create a policy map for the class, and apply the policy map to an interface for QoS.

Examples: Hierarchical Classification

The following is an example of a hierarchical classification, where a class named parent is created, which matches another class named child. The class named child matches based on the IP precedence being set to 2.

Examples: Classification for Voice and Video

This example describes how to classify packet streams for voice and video using controller specific information.

In this example, voice and video are coming in from end-point A into GigabitEthernet1/0/1 on the controller and have precedence values of 5 and 6, respectively. Additionally, voice and video are also coming from end-point B into GigabitEthernet1/0/2 on the controller with DSCP values of EF and AF11, respectively.

Assume that all the packets from the both the interfaces are sent on the uplink interface, and there is a requirement to police voice to 100 Mbps and video to 150 Mbps.

To classify per the above requirements, a class to match voice packets coming in on GigabitEthernet1/0/1 is created, named voice-interface-1, which matches precedence 5. Similarly another class for voice is created, named voice-interface-2, which will match voice packets in GigabitEthernet1/0/2. These classes are associated to two separate policies named input-interface-1, which is attached to GigabitEthernet1/0/1, and input-interface-2, which is attached to GigabitEthernet1/0/2. The action for this class is to mark the qos-group to 10. To match packets with QoS-group 10 on the output interface, a class named voice is created which matches on QoS-group 10. This is then associated to another policy named output-interface, which is associated to the uplink interface. Video is handled in the same way, but matches on QoS-group 20.

The following example shows how classify using the above controller specific information:

Multicast Policer in the example above is not a keyword. It refers to the policing policy configured.

Two class maps with name voice and video are configured with DSCP assignments of 46 and 34. The voice traffic is assigned the priority of 1 and the video traffic is assigned the priority level 2 and is processed using Q0 and Q1. If your network receives multicast voice and video traffic, you can configure multicast policers. The non-client NRT data and NRT data are processed using the Q2 and Q3 queues.

Examples: Policing Action Configuration

The following example displays the various policing actions that can be associated to the policer. These actions are accomplished using the conforming, exceeding, or violating packet configurations. You have the flexibility to drop, mark and transmit, or transmit packets that have exceeded or violated a traffic profile.

For example, a common deployment scenario is one where the enterprise customer polices traffic exiting the network towards the service provider and marks the conforming, exceeding and violating packets with different DSCP values. The service provider could then choose to drop the packets marked with the exceeded and violated DSCP values under cases of congestion, but may choose to transmit them when bandwidth is available.

Note

The Layer 2 fields can be marked to include the CoS fields, and the Layer 3 fields can be marked to include the precedence and the DSCP fields.

One useful feature is the ability to associate multiple actions with an event. For example, you could set the precedence bit and the CoS for all conforming packets. A submode for an action configuration could then be provided by the policing feature.

Examples: Policing Units

The following examples display the various units of
policing that are supported for QoS. The policing unit is the basis on which the token bucket
works .

The
following units of policing are supported:

CIR and PIR are specified in bits per second. The burst parameters are specified in bytes. This is the default mode; it is the unit that is assumed when no units are specified. The CIR and PIR can also be configured in percent, in which case the burst parameters have to be configured in milliseconds.

CIR and PIR are specified in packets per second. In this case, the burst parameters are configured in packets as well.

The following is an example of a policer configuration in bits per second:

The following is an example of a policer configuration in packets per second. In this configuration, a dual-rate three-color policer is configured where the units of measurement is packet. The burst and peak burst are all specified in packets.

Examples: Table Map Marking Configuration

The following steps and examples show how to use table map marking for your QoS configuration:

Define the table map.
Define the table-map using the table-map command and indicate the mapping of the values. This table does not know of the policies or classes within which it will be used. The default command in the table map indicates the value to be copied into the ‘to’ field when there is no matching ‘from’ field. In the example, a table map named table-map1 is created. The mapping defined is to convert the value from 0 to 1 and from 2 to 3, while setting the default value to 4.

Define the policy map where the table map will be used.
In the example, the incoming CoS is mapped to the DSCP based on the mapping specified in the table table-map1. For this example, if the incoming packet has a DSCP of 0, the CoS in the packet is set 1. If no table map name is specified the command assumes a default behavior where the value is copied as is from the ‘from’ field (DSCP in this case) to the ‘to’ field (CoS in this case). Note however, that while the CoS is a 3-bit field, the DSCP is a 6-bit field, which implies that the CoS is copied to the first three bits in the DSCP.

Example: Table Map Configuration to Retain CoS Markings

The following example shows how to use table maps to retain CoS markings on an interface for your QoS configuration.

The cos-trust-policy policy (configured in the example) is enabled in the ingress direction to retain the CoS marking coming into the interface. If the policy is not enabled, only the DSCP is trusted by default. If a pure Layer 2 packet arrives at the interface, then the CoS value will be rewritten to 0 when there is no such policy in the ingress port for CoS.

Technical
Assistance

Description

Link

The Cisco
Support website provides extensive online resources, including documentation
and tools for troubleshooting and resolving technical issues with Cisco
products and technologies.

To receive
security and technical information about your products, you can subscribe to
various services, such as the Product Alert Tool (accessed from Field Notices),
the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS)
Feeds.

Access to
most tools on the Cisco Support website requires a Cisco.com user ID and
password.

Feature History and Information for QoS

Release

Modification

Cisco IOS XE 3.2SE

This feature was introduced.

Cisco IOS XE 3.3SE

Consistent
system default trust behavior for both wired and wireless ports.

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
controller came up, all markings for the wireless
ports were defaulted to zero and no traffic received priority treatment. For
compatibility with an existing wired
controller, all traffic went to the best-effort queue
by default. The access point performed priority queuing by default.

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

Cisco IOS XE 3.3SE

Support
for IPv6 wireless clients.

The Cisco
IOS XE 3.2 software release did not support IPv6 for wireless clients. This is
now supported. Client policies can now have IPv4 and IPv6 filters.