Feedback
Contents
- Configuring Wireless QoS
- Finding Feature Information
- Prerequisites for Wireless QoS
- Restrictions for Wireless QoS
- Information about Wireless QoS
- Wireless QoS Overview
- Hierarchical Wireless QoS
- Wireless Packet Format
- Hierarchical AFD
- Wireless QoS Targets
- Port
- Radio
- SSID
- Client
- Supported QoS Features on Wireless Targets
- Port Policy Format
- Wireless QoS Rate Limiting
- Wireless QoS Multicast
- Queuing in Wireless
- Wireless QoS Mobility
- Inter-Controller Roaming
- Intra-Controller Roaming
- Precious Metal Policies for Wireless QoS
- How to Configure Wireless QoS
- Configuring Precious Metal Policies
- Configuring Class Maps for Voice and Video
- Configuring Client Policies
- Configuring Table Maps
- Applying an SSID Policy
- Configuring QoS Policy for Multicast Traffic
- Configuration Examples
- Examples: Wireless QoS Policy Classified by Voice, Video, and Multicast Traffic
- Examples: SSID Policy
- Examples: Configuring Downstream BSSID Policy
- Examples: Client Policies
- Additional References
Configuring Wireless QoS
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 Wireless QoS
Before configuring wireless QoS, you must have a thorough understanding of these items:
- 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?
- Bandwidth requirements and speed of the network.
- Location of congestion points in the network.
Restrictions for Wireless QoS
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, client, or VLAN. A wireless target can be either a port, SSID, client, or radio. Wireless QoS policies for port, SSID, client, and radio are applied in the downstream direction. That is, when traffic is flowing from the controller to wireless client. 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 (traffic flowing from a wired source to a wireless target).
- 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.
- Policing at the access point is not supported.
- Client policies that are passed to the access points in the upstream direction are not supported.
- The following rules apply for QoS at the SSID:
- One table map is supported at the ingress policy.
- Up to three table maps can be configured in the egress direction for SSID when a QoS-group is involved.
Note
Table maps are not supported at the client targets.
- IPv6 QoS for wireless clients is not supported.
- Port policies are not supported. Radio, SSID, and client policies are supported.
- QoS policies are not supported on wired clients. To configure QoS on wired clients, configure the policy on the port. The UP values for wireless packets can be added when the ports are configured with the policies.
- By default, all wireless traffic is treated as untrusted. That is, in the absence of a table map on the SSID, the packets coming in and going out of the wireless targets are re-marked down to 0. To change the wireless traffic from being untrusted by default to being trusted, you must configure the table map to ensure appropriate packet markings are defined.
Wireless QoS Restrictions on SSID
The following are restrictions for applying QoS features on SSID:
- Set and priority cannot coexist under the same class.
- Set (non-table map) policies at the SSID level will be restricted.
- Policing (without priority) is not supported in both the ingress and 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.
- If set is not enabled in class-default, the classification at the SSID for voice or video must be a subset of the classification for the voice or video class at the port level.
- The mapping in the DSCP2DSCP and COS2COS table should be based on the classification mechanism for the voice and video classes in the port level policy.
- Two or three set commands with table-map related functionality is supported in the parent class-default policy.
- The set table-maps configuration can only be applied in the parent class-default at the SSID level.
- Policing not supported in the upstream direction.
- Table map action is supported only in this class-default class.
- No action is allowed under the class-default of a child policy.
- In the egress direction, the following is supported:
- Table map in parent with only police allowed in child.
- Table map and queuing configured in the parent policy—The parent policy will have a Bandwidth Remaining Ratio (BRR) or shape (either one can be configured), and the set (table-map) configuration command. The child policy should have a priority and police configuration, in which the priority matches the priority level configured at the AP port.
Wireless QoS Restrictions on Radio
The following are restrictions for applying QoS policies on radio targets:
Wireless QoS Restrictions on Clients
The following are restrictions for applying QoS policies on client targets:
- Queuing is not supported.
- Attaching or removing client policies on a WLAN in the up state is not supported. You must shut down the WLAN to apply or remove a policy.
- Table map based set is blocked at the client.
- Policing and set in class-default is blocked in both the upstream and downstream direction:
policy-map foo class class-default police X set dscp Y- The following policy configuration is not supported:
policy map foo class acl-101 (match on 3 tuple) Police X class acl-102 (match on 5 tuple) Police Y- In a flat (nonhierarchical) policy, only police is supported. For user-defined classes, only the following filters are supported:
- No child-policy support under class-default, if the parent policy contains other user-defined class maps in it.
Related Concepts
Information about Wireless QoS
Wireless QoS Overview
Wireless QoS can be configured on the following wireless targets:
QoS policies are configured by using Modular QoS CLI (MQC). Port, SSID, and client policies are user configurable. Radio policies are controlled by the wireless control module.
A target is the entity where the policy is applied. Wireless QoS policies for port, SSID, client, and radio are applied in the downstream direction. That is, when traffic is flowing from the controller to wireless client.
NoteSSID and client policies are supported only in the upstream direction.
The following are some of the specific features provided by wireless QoS:
- Policies on wireless QoS targets:
- Queuing support
- Policing of wireless traffic
- Shaping of wireless traffic
- Rate limiting in both downstream and upstream direction
- Approximate Fair Drop (AFD)
- Mobility support for QoS
- Compatibility with precious metal QoS policies available on Cisco Unified Wireless Controllers.
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.
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.
Wireless QoS Targets
This section describes the various wireless QoS targets available on a controller.
Port
The controller supports port-based policies. The port policies includes port shaper and a child policy (port_child_policy).
Port shaper specifies the traffic policy between the device to the AP. This is the sum of the radio rates supported on the access point.
The child policy determines the mapping between packets and queues defined by the port-child policy. The child policy can be configured to include voice, video, and class-default classes where voice and video are based on DSCP value (which is the outer CAPWAP header DSCP value). The definition of class-default is known to the system as any value other than voice and video DSCP.
The DSCP value is assigned when the packet reaches the port. Before the packet arrives at the port, the SSID policies are applied on the packet. Port child policy also includes multicast percentage for a given port traffic. By default, the port child policy allocates up to 10 percent of the available rate.
Radio
The controller enables you to create 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.
Related Concepts
Related References
SSID
You can create QoS policies on SSID (BSSID) in both the upstream and downstream directions. By default, there is no SSID policy. All traffic is transmitted as best effort because the wireless traffic in untrusted. 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 and RT2 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 port and 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. You can configure one queue in the upstream 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.
Related Concepts
Client
Client policies are applicable in the upstream and downstream direction. The wireless control module of the controller applies the 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.
You can configure client policies in the following ways:
- Using AAA—You can use a combination of AAA and TCLAS, AAA and SIP snooping when configuring via AAA.
- Using the IOS MQC CLI—You can use a combination of CLI and TCLAS and CLI and SIP snooping.
- Using the default configuration
Note
When an installed policy gets modified on a WLAN, the WLAN must be restarted for the changes to take effect. For SSID policies, a restart is not required.
NoteIf you configured AAA by configuring the classic unified wireless controller procedure, and using the MQC QoS commands, the policy configuration performed through the MQC QoS commands takes precedence.
Related Concepts
Related References
Supported QoS Features on Wireless Targets
This table describes the various features available on wireless targets.
Table 1 QoS Features Available on Wireless TargetsTarget Features Traffic Direction Where Policies Are Applicable Comments Port Non-Real Time (NRT), Real Time (RT) Downstream Radio Non-Real Time Downstream Radio policies are not user configurable. SSID
Note Set without table map is not supported on SSID.
Non-Real Time, Real Time Upstream and downstream Queuing actions such as shaping and BRR are allowed only in the downstream direction. Client Non-Real Time, Real time Upstream and downstream Port Policy Format
To configure quality of service (QoS) on a controller, you must configure a port map policy. Because a Cisco 5700 Series Wireless Controller contains 6 10-Gigabit ports, the policy map must be configured on all ports.
NoteThe policy must be configured on all of the six physical ports on the controller even if LAG is configured.
The following basic port policy must be configured on the physical ports. You can add further classification if required:
Policy-map <port-policy-name> Class voice Priority level 1 class video Priority level 2Wireless QoS Rate Limiting
QoS per Client Rate Limit—Wireless
Note
For client policy, the voice and video rate limits are applied at the same time.QoS Downstream Rate Limit—Wireless
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 radio has a default shaping policy. This shaping limit is the physical limit of the radio itself. For example, the 802.11b/g/n radio can shape up to 100 Mbps on a 2.4 GHz frequency. You can check the policy maps on the radio by using the show policy-map interface wireless radio command.
NoteThe controller does not support port shaping rate.
Wireless QoS Multicast
There are two modes of Multicast configuration in 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 5700.
- multicast-multicast mode: In this scenario, the controller sends the traffic to the multicast group. The APs in the multicast group are then served the multicast traffic.
Related Tasks
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.
- Video—This is a strict priority queue. Represented by Q1, this queue processes multicast or unicast video traffic.
- Data NRT—Represented by Q2, this queue processes all non-real-time unicast traffic.
- 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.
NoteBy default, the queues Q0 and Q1 are not enabled.
NoteA 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.
NoteThe queues on the controller is different from the queues on the access points.
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:
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.
NoteIf 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.
NoteQoS 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:
These policies (also known as profiles) can be applied to a WLAN based on the traffic. We recommend the configuration via 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.11p, 802.11e (WMM) and DSCP fields in the packets are affected. These values are pre configured and installed when the controller is booted.
NoteUnlike 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.
Related Tasks
How to Configure Wireless QoS
Configuring Precious Metal Policies
You can configure precious metal QoS policies on a per-WLAN basis.SUMMARY STEPS
NoteUpstream policies differ from downstream policies. The upstream policies have a suffix of -up.
1. configure terminal
2. wlan wlan-name
3. service-policy [client] output policy-name
4. end
5. show wlan {wlan-id | wlan-name}
DETAILED STEPSRelated Concepts
Configuring Class Maps for Voice and Video
SUMMARY STEPS
1. configure terminal
2. class-map class-map-name
3. match dscp dscp-value-for-voice
4. end
5. configure terminal
6. class-map class-map-name
7. match dscp dscp-value-for-video
8. end
DETAILED STEPSConfiguring Client Policies
Before You BeginSUMMARY STEPSYou must have the following features configured before configuring client policies:
1. configure terminal
2. ip access-list extended ext-name
3. permit ip host host-ip-address
4. end
5. configure terminal
6. class map acl-name
7. match access-group name access-list-name
8. end
DETAILED STEPSConfiguring Table Maps
SUMMARY STEPS
1. configure terminal
2. table-map table-map-name
3. map from from-value to to-value
4. end
DETAILED STEPSApplying an SSID Policy
SUMMARY STEPS
1. configure terminal
2. wlan wlan-name
3. service-policy [ client ] qos [ input | output ] ssid-policy-name
4. end
DETAILED STEPSProceed to configure client policies.
Configuring QoS Policy for Multicast Traffic
Before You BeginSUMMARY STEPSThe following are the prerequisites for configuring a QoS policy for multicast traffic:
1. configure terminal
2. ap capwap multicast service-policy output service -policy-name
3. end
DETAILED STEPSRelated Concepts
Configuration Examples
Examples: Wireless QoS Policy Classified by Voice, Video, and Multicast Traffic
The following example provides a template for creating a port child policy for managing quality of service for voice and video traffic.
Policy-map port_child_policy Class voice (match dscp ef) Priority level 1 Police Multicast Policer Class video (match dscp af11) Priority level 2 Police Multicast Policer Class mcast-data (match non-client-nrt) Bandwidth remaining ratio <> Class class-default (NRT Data) Bandwidth remaining ratio <> Policy-map parent_port Class class-default Shape average Port Shaper Service-policy port_child_policy
NoteMulticast 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: SSID Policy
SSID Policy 1
The following is an example of an SSID policy for voice and video:
Policy-map enterprise-ssid-1 Class voice (match dscp ef) Priority level 1 Police Unicast Policer Class video (match dscp af11) Priority level 2 Police Unicast Policer Policy-map ssid-shaper Class class-default (NRT Data) queue-buffer 0 shape average 100000000 set wlan-user-priority dscp table dscp2up set dscp dscp table dscp2dscp service-policy enterprise-ssid-1SSID Policy 2
The following is an example of SSID policy configured with an average SSID shaping rate:
Policy-map enterprise-ssid-2 Class voice (match dscp af11) Priority level 1 Police Unicast Policer Class video (match dscp ef) Priority level 2 Police Unicast Policer Policy-map ssid-shaper Class class-default (NRT Data) shape average 1000000000 service-policy enterprise-ssid-2 set wlan-user-priority dscp table dscp2up set dscp dscp table dscp2dscpRelated Concepts
Examples: Configuring Downstream BSSID Policy
Configuring a User-Defined Port Child Policy
To configure a downstream BSSID policy, you must first configure a port child policy with priority level queuing.
The following is an example of configuring a user-defined port child policy:
policy-map port_child_policy class voice priority level 1 20000 class video priority level 2 10000 class non-client-nrt-class bandwidth remaining ratio 10 class class-default bandwidth remaining ratio 15The following configuration example displays how to configure a downstream BSSID policy:
policy-map bssid-policer class class-default shape average 30000000 set dscp dscp table dscp2dscp set wlan user-priority dscp table dscp2up service-policy ssid_child_qosThe SSID child QoS policy may be defined as below:
Policy Map ssid-child_qos Class voice priority level 1 police cir 5m admit cac wmm-tspec UP 6,7 / tells WCM allow ‘voice’ TSPEC\SIP snoop for this ssid rate 4000 / must be police rate value is in kbps) Class video priority level 2 police cir 60000Related Concepts
Examples: Client Policies
The following example shows a default client policy in the downstream direction. Any incoming traffic contains the user-priority as 0:
Policy-map client-def-down class class-default set wlan user-priority 0The following example shows the default client policy in the upstream direction. Any traffic that is sent to the wired network from wireless network will result in the DSCP value being set to 0.
Policy-map client-def-up class class-default set dscp 0The following examples shows client policies that are generated automatically and applied to the client when the client authenticates to a profile in AAA with a QoS-level attribute configured.
Policy Map platinum-WMM Class voice-plat set wlan user-priority 6 Class video-plat set wlan user-priority 4 Class class-default set wlan user-priority 0Policy Map gold-WMM Class voice-gold set wlan user-priority 4 Class video-gold set wlan user-priority 4 Class class-default set wlan user-priority 0The following is an example of client precious metal policies:
Policy Map platinum set wlan user-priority 6Any traffic matching class voice1 the user priority is set to a pre-defined value. The class can be set to assign a DSCP or ACL.
Policy Map client1-down Class voice1 //match dscp, cos set wlan user-priority <> Class voice2 //match acl set wlan user-priority <> Class voice3 set wlan user-priority <> Class class-default set wlan user-priority 0The following is an example of a client policy based on AAA and TCLAS:
Policy Map client2-down[ AAA+ TCLAS pol example] Class voice\\match dscp police <> set <> Class class-default set <> Class voice1|| voice2 [match acls] police <> class voice1 set <> class voice2 set <>The following is an example of a client policy for voice and video for traffic in the downstream direction:
Policy Map client3-down class voice \\match dscp, cos police X class video police Y class default police ZThe following is an example of a client policy for voice and video for traffic in the upstream direction using policing:
Policy Map client1-up class voice \\match dscp, up, cos police X class video police Y class class-default police ZThe following is an example of a client policy for voice and video based on DSCP:
Policy Map client2-up class voice \\match dscp, up, cos set dscp <> class video set dscp <> class class-default set dscp <>Related Concepts
Additional References
Related Documents
Related Topic Document Title QoS Command Reference QoS Command Reference (Cisco WLC 5700 Series) Mobility Configuration Guide Mobility Configuration Guide, Cisco IOS XE Release 3SE (Cisco WLC 5700 Series) Quality of Service Solutions Configuration Guide (Cisco IOS Software) Quality of Service Solutions Configuration Guide Library, Cisco IOS XE Release 3SE (Cisco WLC 5700 Series) MIBs
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.
