Software Configuration Guide, Cisco IOS XE Denali 16.3.x (Catalyst 3850 Switches)

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

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 Auto-QoS

The prerequisites for auto-QoS are the same as the prerequisites for standard QoS.

Restrictions for Auto-QoS

The following are restrictions for auto-QoS:

Auto-qos is not supported on SVI interfaces.
Auto-QoS is not supported on an Etherchannel interface. When applied on member ports, all port-channel interfaces should share the same Auto-QoS policy.
The trust device device_type command available in interface configuration mode is a stand-alone command on the switch. When using this command, if the connected peer device is not a corresponding device (defined as a device matching your trust policy), both CoS and DSCP values are set to "0" and any input policy will not take effect. If the connected peer device is a corresponding device, input policy will take effect.
When upgrading your software release from a pre- 3.2.2 software version to a 3.2.2 or later software version, you must follow the auto-QoS upgrade procedure described in this chapter.
Do not configure the auto qos voip cisco-phone option for IP phones that support video. This option causes DSCP markings of video packets to get overwritten, because these packets do not have Expedited Forwarding priority, which results in these packets getting classified in the class-default class.
Auto-QoS does not generate configuration when it is pushed from the startup-configuration using the auto qos voip cisco-phone command to the running-configuration. This is expected behavior and this is to prevent overwriting of user-created customized QoS policies by the default configuration, if any, every time the command auto qos voip cisco-phone is pushed from the startup-config.
You can use any of the following workarounds for this limitation:
- Configure the auto qos voip cisco-phone command manually on the switch interfaces.
- For new switches, if you push auto-QoS commands through startup-config, the command should include each of the following as part of the standard template
  1. Interface-level:
    - trust device cisco-phone
    - auto qos voip cisco-phone
    - service-policy input AutoQos-4.0-CiscoPhone-Input-Policy
    - service-policy output AutoQos-4.0-Output-Policy
  2. Global-level:
    - Class-map
    - Policy-map
    - ACL(ACE)
- If the auto qos voip cisco-phone command is already configured on an interface but policies are not being generated, disable the command from all the interfaces and reconfigure the command on each interface manually.

Auto-QoS Overview

You can use the auto-QoS feature to simplify the deployment of QoS features. Auto-QoS determines the network design and enables QoS configurations so that the switch can prioritize different traffic flows.

The switch employs the MQC model. This means that instead of using certain global configurations, auto-QoS applied to any interface on a switch configures several global class maps and policy maps.

Auto-QoS matches traffic and assigns each matched packet to qos-groups. This allows the output policy map to put specific qos-groups into specific queues, including into the priority queue.

QoS is needed in both directions, both on inbound and outbound. When inbound, the switch port needs to trust the DSCP in the packet (done by default). When outbound, the switch port needs to give voice packets "front of line" priority. If voice is delayed too long by waiting behind other packets in the outbound queue, the end host drops the packet because it arrives outside of the receive window for that packet.

Auto-QoS Compact Overview

When you enter an auto-QoS command, the switch displays all the generated commands as if the commands were entered from the CLI. You can use the auto-QoS compact feature to hide the auto-QoS generated commands from the running configuration. This would make it easier to comprehend the running-configuration and also help to increase efficient usage of memory.

Auto-QoS Global Configuration Templates

In general, an auto-QoS command generates a series of class maps that either match on ACLs or on DSCP and/or CoS values to differentiate traffic into application classes. An input policy is also generated, which matches the generated classes and in some cases, polices the classes to a set bandwidth. Eight egress-queue class maps are generated. The actual egress output policy assigns a queue to each one of these eight egress-queue class maps.

The auto-QoS commands only generate templates as needed. For example, the first time any new auto-QoS command is used, global configurations that define the eight queue egress service-policy are generated. From this point on, auto-QoS commands applied to other interfaces do not generate templates for egress queuing because all auto-QoS commands rely on the same eight queue models, which have already been generated from the first time a new auto-QoS command was used.

Auto-QoS Policy and Class Maps

After entering the appropriate auto-QoS command, the following actions occur:

Specific class maps are created.
Specific policy maps (input and output) are created.
Policy maps are attached to the specified interface.
Trust level for the interface is configured.

Effects of Auto-QoS on Running Configuration

When auto-QoS is enabled, the auto qos interface configuration commands and the generated global configuration are added to the running configuration.

The switch applies the auto-QoS-generated commands as if the commands were entered from the CLI. An existing user configuration can cause the application of the generated commands to fail or to be overridden by the generated commands. These actions may occur without warning. If all the generated commands are successfully applied, any user-entered configuration that was not overridden remains in the running configuration. Any user-entered configuration that was overridden can be retrieved by reloading the switch without saving the current configuration to memory. If the generated commands are not applied, the previous running configuration is restored.

Effects of Auto-Qos Compact on Running Configuration

If auto-QoS compact is enabled:

Only the auto-QoS commands entered from the CLI are displayed in running-config.
The generated global and interface configurations are hidden.
When you save the configuration, only the auto-qos commands you have entered are saved (and not the hidden configuration).
When you reload the switch, the system detects and re-executes the saved auto-QoS commands and the AutoQoS SRND4.0 compliant config-set is generated .

Note

Do not make changes to the auto-QoS-generated commands when auto-QoS compact is enabled, because user-modifications are overridden when the switch reloads.

When auto-qos global compact is enabled:

show derived-config command can be used to view hidden AQC derived commands.
AQC commands will not be stored to memory. They will be regenerated every time the switch is reloaded.
When compaction is enabled, auto-qos generated commands should not be modified .
If the interface is configured with auto-QoS and if AQC needs to be disabled, auto-qos should be disabled at interface level first.

Configuring Auto-QoS (CLI)

For optimum QoS performance, configure auto-QoS on all the devices in your network.

Procedure

Command or Action Purpose

Step 1

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:


Device(config)# interface 
gigabitethernet 3/0/1

Specifies the port that is connected to a VoIP port, video device, or the uplink port that is connected to another trusted switch or router in the network interior, and enters the interface configuration mode.

Step 3

Depending on your auto-QoS configuration, use one of the following commands:

auto qos voip {cisco-phone | cisco-softphone | trust}
auto qos video {cts | ip-camera | media-player}
auto qos classify [police]
auto qos trust {cos | dscp}

Example:


Device(config-if)# auto qos trust dscp

The following commands enable auto-QoS for VoIP:

auto qos voip cisco-phone —If the port is connected to a Cisco IP Phone, the QoS labels of incoming packets are only trusted (conditional trust through CDP) when the telephone is detected.

Note

Do not configure the auto qos voip cisco-phone option for IP phones that support video. This option causes DSCP markings of video packets to get overwritten, because these packets do not have Expedited Forwarding priority, which results in these packets getting classified in the class-default class.

auto qos voip cisco-softphone —The port is connected to device running the Cisco SoftPhone feature. This command generates a QoS configuration for interfaces connected to PCs running the Cisco IP SoftPhone application and mark, as well as police traffic coming from such interfaces. Ports configured with this command are considered untrusted.
auto qos voip trust —The uplink port is connected to a trusted switch or router, and the VoIP traffic classification in the ingress packet is trusted.

The following commands enable auto-QoS for the specified video device (system, camera, or media player):

auto qos video cts —A port connected to a Cisco Telepresence system. QoS labels of incoming packets are only trusted (conditional trust through CDP) when a Cisco TelePresence is detected.
auto qos video ip-camera —A port connected to a Cisco video surveillance camera. QoS labels of incoming packets are only trusted (conditional trust through CDP) when a Cisco camera is detected.
auto qos video media-player —A port connected to a CDP-capable Cisco digital media player. QoS labels of incoming packets are only trusted (conditional trust through CDP) when a digital media player is detected.

The following command enables auto-QoS for classification:

auto qos classify police — This command generates a QoS configuration for untrusted interfaces. The configuration places a service-policy on the interface to classify traffic coming from untrusted desktops/devices and mark them accordingly. The service-policies generated do police.

The following commands enable auto-QoS for trusted interfaces:

auto qos trust cos —Class of service.
auto qos trust dscp —Differentiated Services Code Point.

Step 4

end

Example:


Device(config-if)# end

Returns to privileged EXEC mode.

Step 5

show auto qos interface interface-id

Example:


Device# show auto qos interface 
gigabitethernet 3/0/1

(Optional) Displays the auto-QoS command on the interface on which auto-QoS was enabled. Use the show running-config command to display the auto-QoS configuration and user modifications.

Upgrading Auto-QoS (CLI)

This procedure should only be followed when upgrading your software release from a pre- 3.2.2 software version to a 3.2.2 or later software version.

Before you begin

Prior to upgrading, you need to remove all auto-QoS configurations currently on the switch. This sample procedure describes that process.

After following this sample procedure, you must then reboot the switch with the new or upgraded software image and reconfigure auto-QoS.

Procedure

Step 1	show auto qos Example: `Device# show auto qos GigabitEthernet2/0/3 auto qos voip cisco-phone GigabitEthernet2/0/27 auto qos voip cisco-softphone` In privileged EXEC mode, record all current auto QoS configurations by entering this command.
Step 2	no auto qos Example: `Device(config-if)#no auto qos` In interface configuration mode, run the appropriate no auto qos command on each interface that has an auto QoS configuration.
Step 3	show running-config \| i autoQos Example: `Device# show running-config \| i autoQos` Return to privileged EXEC mode, and record any remaining auto QoS maps class maps, policy maps, access lists, table maps, or other configurations by entering this command.
Step 4	no policy-map `policy-map_name` Example: `Device)config# no policy-map pmap_101 Device)config# no class-map cmap_101 Device)config# no ip access-list extended AutoQos-101 Device)config# no table-map 101 Device)config# no table-map policed-dscp` In global configuration mode, remove the QoS class maps, policy maps, access-lists, table maps, and any other auto QoS configurations by entering these commands: no policy-map `policy-map-name` no class-map `class-map-name` no ip access-list extended `Auto-QoS-x` no table-map `table-map-name` no table-map policed-dscp
Step 5	show running-config \| i AutoQoS Example: `Device# show running-config \| i AutoQos` Return to privileged EXEC mode, run this command again to ensure that no auto-QoS configuration or remaining parts of the auto-QoS configuration exists
Step 6	show auto qos Example: `Device# show auto qos` Run this command to ensure that no auto-QoS configuration or remaining parts of the configuration exists.
Step 7	write memory Example: `Device# write memory` Write the changes to the auto QoS configuration to NV memory by entering the write memory command.

What to do next

Reboot the switch with the new or upgraded software image.

After rebooting with the new or upgraded software image, re-configure auto-QoS for the appropriate switch interfaces as determined by running the show auto qos command described in step 1.

Note

There is only one table-map for exceed and another table-map for violate markdown per switch or stack. If the switch already has a table-map under the exceed action, then the auto-qos policy cannot be applied.

Enabling Auto-Qos Compact

To enable auto-Qos compact, enter this command:

Procedure

Command or Action Purpose

Step 1

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 2

auto qos global compact

Example:


Device(config)# auto qos global compact

Enables auto-Qos compact and generates (hidden) the global configurations for auto-QoS.

You can then enter the auto-QoS command you want to configure in the interface configuration mode and the interface commands that the system generates are also hidden.

To display the auto-QoS configuration that has been applied, use these the privileged EXEC commands:

show derived-config
show policy-map
show access-list
show class-map
show table-map
show auto-qos
show policy-map interface
show ip access-lists

These commands will have keyword "AutoQos- ".

What to do next

To disable auto-QoS compact, remove auto-Qos instances from all interfaces by entering the no form of the corresponding auto-QoS commands and then enter the no auto qos global compact global configuration command.

Monitoring Auto-QoS

Table 1. Commands for Monitoring Auto-QoS
Command	Description
show auto qos [interface [`interface-id`]]	Displays the initial auto-QoS configuration. You can compare the show auto qos and the show running-config command output to identify the user-defined QoS settings.
show running-config	Displays information about the QoS configuration that might be affected by auto-QoS. You can compare the show auto qos and the show running-config command output to identify the user-defined QoS settings.
show derived-config	Displays the hidden mls qos command which get configured along with the running configs because of auto-qos template.

Troubleshooting Auto-QoS

To troubleshoot auto-QoS, use the debug auto qos privileged EXEC command. For more information, see the debug auto qos command in the command reference for this release.

To disable auto-QoS on a port, use the no form of the auto qos command interface configuration command, such as no auto qos voip . Only the auto-QoS-generated interface configuration commands for this port are removed. If this is the last port on which auto-QoS is enabled and you enter the no auto qos voip command, auto-QoS is considered disabled even though the auto-QoS-generated global configuration commands remain (to avoid disrupting traffic on other ports affected by the global configuration).

Example: auto qos trust cos

The following is an example of the auto qos trust cos command and the applied policies and class maps.

The following policy maps are created and applied when running this command:

AutoQos-4.0-Trust-Cos-Input-Policy
AutoQos-4.0-Output-Policy

The following class maps are created and applied when running this command:

class-default (match-any)
AutoQos-4.0-Output-Priority-Queue (match-any)
AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
AutoQos-4.0-Output-Trans-Data-Queue (match-any)
AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
AutoQos-4.0-Output-Scavenger-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)


Device(config)# interface GigabitEthernet1/0/17
Device(config-if)# auto qos trust cos
Device(config-if)# end
Device# show policy-map interface GigabitEthernet1/0/17

GigabitEthernet1/0/17

  Service-policy input: AutoQos-4.0-Trust-Cos-Input-Policy

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        cos cos table AutoQos-4.0-Trust-Cos-Table

  Service-policy output: AutoQos-4.0-Output-Policy

    queue stats for all priority classes:
      Queueing
      priority level 1

      (total drops) 0
      (bytes output) 0

    Class-map: AutoQos-4.0-Output-Priority-Queue (match-any)
      0 packets
      Match:  dscp cs4 (32) cs5 (40) ef (46)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 30% (300000 kbps), burst bytes 7500000,

      Priority Level: 1

    Class-map: AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
      0 packets
      Match:  dscp cs2 (16) cs3 (24) cs6 (48) cs7 (56)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue-limit dscp 16 percent 80
      queue-limit dscp 24 percent 90
      queue-limit dscp 48 percent 100
      queue-limit dscp 56 percent 100

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%

      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
      0 packets
      Match:  dscp af41 (34) af42 (36) af43 (38)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  4
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Trans-Data-Queue (match-any)
      0 packets
      Match:  dscp af21 (18) af22 (20) af23 (22)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  2
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
      0 packets
      Match:  dscp af11 (10) af12 (12) af13 (14)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  1
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 4%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Scavenger-Queue (match-any)
      0 packets
      Match:  dscp cs1 (8)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 1%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)
      0 packets
      Match:  dscp af31 (26) af32 (28) af33 (30)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 25%
      queue-buffers ratio 25

Example: auto qos trust dscp

The following is an example of the auto qos trust dscp command and the applied policies and class maps.

The following policy maps are created and applied when running this command:

AutoQos-4.0-Trust-Dscp-Input-Policy
AutoQos-4.0-Output-Policy

The following class maps are created and applied when running this command:

class-default (match-any)
AutoQos-4.0-Output-Priority-Queue (match-any)
AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
AutoQos-4.0-Output-Trans-Data-Queue (match-any)
AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
AutoQos-4.0-Output-Scavenger-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)


Device(config)# interface GigabitEthernet1/0/18
Device(config-if)# auto qos trust dscp
Device(config-if)# end
Device#show policy-map interface GigabitEthernet1/0/18


GigabitEthernet1/0/18

  Service-policy input: AutoQos-4.0-Trust-Dscp-Input-Policy

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp dscp table AutoQos-4.0-Trust-Dscp-Table

  Service-policy output: AutoQos-4.0-Output-Policy

    queue stats for all priority classes:
      Queueing
      priority level 1

      (total drops) 0
      (bytes output) 0

    Class-map: AutoQos-4.0-Output-Priority-Queue (match-any)
      0 packets
      Match:  dscp cs4 (32) cs5 (40) ef (46)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 30% (300000 kbps), burst bytes 7500000,

      Priority Level: 1

    Class-map: AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
      0 packets
      Match:  dscp cs2 (16) cs3 (24) cs6 (48) cs7 (56)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue-limit dscp 16 percent 80
      queue-limit dscp 24 percent 90
      queue-limit dscp 48 percent 100
      queue-limit dscp 56 percent 100

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%

      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
      0 packets
      Match:  dscp af41 (34) af42 (36) af43 (38)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  4
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Trans-Data-Queue (match-any)
      0 packets
      Match:  dscp af21 (18) af22 (20) af23 (22)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  2
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
      0 packets
      Match:  dscp af11 (10) af12 (12) af13 (14)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  1
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 4%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Scavenger-Queue (match-any)
      0 packets
      Match:  dscp cs1 (8)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 1%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)
      0 packets
      Match:  dscp af31 (26) af32 (28) af33 (30)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 25%
      queue-buffers ratio 25

Example: auto qos video cts

The following is an example of the auto qos video cts command and the applied policies and class maps.

The following policy maps are created and applied when running this command:

AutoQos-4.0-Trust-Cos-Input-Policy
AutoQos-4.0-Output-Policy

The following class maps are created and applied when running this command:

class-default (match-any)
AutoQos-4.0-Output-Priority-Queue (match-any)
AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
AutoQos-4.0-Output-Trans-Data-Queue (match-any)
AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
AutoQos-4.0-Output-Scavenger-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)


Device(config)# interface GigabitEthernet1/0/12
Device(config-if)# auto qos video cts
Device(config-if)# end
Device# show policy-map interface GigabitEthernet1/0/12

GigabitEthernet1/0/12

  Service-policy input: AutoQos-4.0-Trust-Cos-Input-Policy

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        cos cos table AutoQos-4.0-Trust-Cos-Table

  Service-policy output: AutoQos-4.0-Output-Policy

    queue stats for all priority classes:
      Queueing
      priority level 1

      (total drops) 0
      (bytes output) 0

    Class-map: AutoQos-4.0-Output-Priority-Queue (match-any)
      0 packets
      Match:  dscp cs4 (32) cs5 (40) ef (46)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 30% (300000 kbps), burst bytes 7500000,

      Priority Level: 1

    Class-map: AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
      0 packets
      Match:  dscp cs2 (16) cs3 (24) cs6 (48) cs7 (56)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue-limit dscp 16 percent 80
      queue-limit dscp 24 percent 90
      queue-limit dscp 48 percent 100
      queue-limit dscp 56 percent 100

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%

      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
      0 packets
      Match:  dscp af41 (34) af42 (36) af43 (38)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  4
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Trans-Data-Queue (match-any)
      0 packets
      Match:  dscp af21 (18) af22 (20) af23 (22)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  2
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
      0 packets
      Match:  dscp af11 (10) af12 (12) af13 (14)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  1
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 4%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Scavenger-Queue (match-any)
      0 packets
      Match:  dscp cs1 (8)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 1%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)
      0 packets
      Match:  dscp af31 (26) af32 (28) af33 (30)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 25%
      queue-buffers ratio 25

Example: auto qos video ip-camera

The following is an example of the auto qos video ip-camera command and the applied policies and class maps.

The following policy maps are created and applied when running this command:

AutoQos-4.0-Trust-Dscp-Input-Policy
AutoQos-4.0-Output-Policy

The following class maps are created and applied when running this command:

class-default (match-any)
AutoQos-4.0-Output-Priority-Queue (match-any)
AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
AutoQos-4.0-Output-Trans-Data-Queue (match-any)
AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
AutoQos-4.0-Output-Scavenger-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)


Device(config)# interface GigabitEthernet1/0/9
Device(config-if)# auto qos video ip-camera
Device(config-if)# end
Device# show policy-map interface GigabitEthernet1/0/9


GigabitEthernet1/0/9

  Service-policy input: AutoQos-4.0-Trust-Dscp-Input-Policy

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp dscp table AutoQos-4.0-Trust-Dscp-Table

  Service-policy output: AutoQos-4.0-Output-Policy

    queue stats for all priority classes:
      Queueing
      priority level 1

      (total drops) 0
      (bytes output) 0

    Class-map: AutoQos-4.0-Output-Priority-Queue (match-any)
      0 packets
      Match:  dscp cs4 (32) cs5 (40) ef (46)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 30% (300000 kbps), burst bytes 7500000,

      Priority Level: 1

    Class-map: AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
      0 packets
      Match:  dscp cs2 (16) cs3 (24) cs6 (48) cs7 (56)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue-limit dscp 16 percent 80
      queue-limit dscp 24 percent 90
      queue-limit dscp 48 percent 100
      queue-limit dscp 56 percent 100

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%

      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
      0 packets
      Match:  dscp af41 (34) af42 (36) af43 (38)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  4
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Trans-Data-Queue (match-any)
      0 packets
      Match:  dscp af21 (18) af22 (20) af23 (22)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  2
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
      0 packets
      Match:  dscp af11 (10) af12 (12) af13 (14)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  1
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 4%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Scavenger-Queue (match-any)
      0 packets
      Match:  dscp cs1 (8)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 1%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)
      0 packets
      Match:  dscp af31 (26) af32 (28) af33 (30)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 25%
      queue-buffers ratio 25

Example: auto qos video media-player

The following is an example of the auto qos video media-player command and the applied policies and class maps.

The following policy maps are created and applied when running this command:

AutoQos-4.0-Trust-Dscp-Input-Policy
AutoQos-4.0-Output-Policy

The following class maps are created and applied when running this command:

class-default (match-any)
AutoQos-4.0-Output-Priority-Queue (match-any)
AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
AutoQos-4.0-Output-Trans-Data-Queue (match-any)
AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
AutoQos-4.0-Output-Scavenger-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)


Device(config)# interface GigabitEthernet1/0/7
Device(config-if)# auto qos video media-player
Device(config-if)# end
Device# show policy-map interface GigabitEthernet1/0/7


 GigabitEthernet1/0/7

  Service-policy input: AutoQos-4.0-Trust-Dscp-Input-Policy

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp dscp table AutoQos-4.0-Trust-Dscp-Table

  Service-policy output: AutoQos-4.0-Output-Policy

    queue stats for all priority classes:
      Queueing
      priority level 1

      (total drops) 0
      (bytes output) 0

    Class-map: AutoQos-4.0-Output-Priority-Queue (match-any)
      0 packets
      Match:  dscp cs4 (32) cs5 (40) ef (46)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 30% (300000 kbps), burst bytes 7500000,

      Priority Level: 1

    Class-map: AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
      0 packets
      Match:  dscp cs2 (16) cs3 (24) cs6 (48) cs7 (56)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue-limit dscp 16 percent 80
      queue-limit dscp 24 percent 90
      queue-limit dscp 48 percent 100
      queue-limit dscp 56 percent 100

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%

      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
      0 packets
      Match:  dscp af41 (34) af42 (36) af43 (38)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  4
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Trans-Data-Queue (match-any)
      0 packets
      Match:  dscp af21 (18) af22 (20) af23 (22)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  2
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
      0 packets
      Match:  dscp af11 (10) af12 (12) af13 (14)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  1
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 4%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Scavenger-Queue (match-any)
      0 packets
      Match:  dscp cs1 (8)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 1%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)
      0 packets
      Match:  dscp af31 (26) af32 (28) af33 (30)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 25%
      queue-buffers ratio 25

Example: auto qos voip trust

The following is an example of the auto qos voip trust command and the applied policies and class maps.

The following policy maps are created and applied when running this command:

AutoQos-4.0-Trust-Cos-Input-Policy
AutoQos-4.0-Output-Policy

The following class maps are created and applied when running this command:

class-default (match-any)
AutoQos-4.0-Output-Priority-Queue (match-any)
AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
AutoQos-4.0-Output-Trans-Data-Queue (match-any)
AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
AutoQos-4.0-Output-Scavenger-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)


Device(config)# interface GigabitEthernet1/0/31
Device(config-if)# auto qos voip trust
Device(config-if)# end
Device# show policy-map interface GigabitEthernet1/0/31

GigabitEthernet1/0/31

  Service-policy input: AutoQos-4.0-Trust-Cos-Input-Policy

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        cos cos table AutoQos-4.0-Trust-Cos-Table

  Service-policy output: AutoQos-4.0-Output-Policy

    queue stats for all priority classes:
      Queueing
      priority level 1

      (total drops) 0
      (bytes output) 0

    Class-map: AutoQos-4.0-Output-Priority-Queue (match-any)
      0 packets
      Match:  dscp cs4 (32) cs5 (40) ef (46)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 30% (300000 kbps), burst bytes 7500000,

      Priority Level: 1

    Class-map: AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
      0 packets
      Match:  dscp cs2 (16) cs3 (24) cs6 (48) cs7 (56)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue-limit dscp 16 percent 80
      queue-limit dscp 24 percent 90
      queue-limit dscp 48 percent 100
      queue-limit dscp 56 percent 100

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%

      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
      0 packets
      Match:  dscp af41 (34) af42 (36) af43 (38)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  4
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Trans-Data-Queue (match-any)
      0 packets
      Match:  dscp af21 (18) af22 (20) af23 (22)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  2
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
      0 packets
      Match:  dscp af11 (10) af12 (12) af13 (14)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  1
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 4%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Scavenger-Queue (match-any)
      0 packets
      Match:  dscp cs1 (8)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 1%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)
      0 packets
      Match:  dscp af31 (26) af32 (28) af33 (30)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 25%
      queue-buffers ratio 25

Example: auto qos voip cisco-phone

The following is an example of the auto qos voip cisco-phone command and the applied policies and class maps.

The following policy maps are created and applied when running this command:

AutoQos-4.0-CiscoPhone-Input-Policy
AutoQos-4.0-Output-Policy

The following class maps are created and applied when running this command:

AutoQos-4.0-Voip-Data-CiscoPhone-Class (match-any)
AutoQos-4.0-Voip-Signal-CiscoPhone-Class (match-any)
AutoQos-4.0-Default-Class (match-any)
class-default (match-any)
AutoQos-4.0-Output-Priority-Queue (match-any)
AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
AutoQos-4.0-Output-Trans-Data-Queue (match-any)
AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
AutoQos-4.0-Output-Scavenger-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)


Device(config)# interface GigabitEthernet1/0/5
Device(config-if)# auto qos voip cisco-phone
Device(config-if)# end
Device# show policy-map interface GigabitEthernet1/0/5

GigabitEthernet1/0/5

  Service-policy input: AutoQos-4.0-CiscoPhone-Input-Policy

    Class-map: AutoQos-4.0-Voip-Data-CiscoPhone-Class (match-any)
      0 packets
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp ef
      police:
          cir 128000 bps, bc 8000 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          set-dscp-transmit dscp table policed-dscp
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Voip-Signal-CiscoPhone-Class (match-any)
      0 packets
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp cs3
      police:
          cir 32000 bps, bc 8000 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          set-dscp-transmit dscp table policed-dscp
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Default-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Default
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp default

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps

  Service-policy output: AutoQos-4.0-Output-Policy

    queue stats for all priority classes:
      Queueing
      priority level 1

      (total drops) 0
      (bytes output) 0

    Class-map: AutoQos-4.0-Output-Priority-Queue (match-any)
      0 packets
      Match:  dscp cs4 (32) cs5 (40) ef (46)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 30% (300000 kbps), burst bytes 7500000,

      Priority Level: 1

    Class-map: AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
      0 packets
      Match:  dscp cs2 (16) cs3 (24) cs6 (48) cs7 (56)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue-limit dscp 16 percent 80
      queue-limit dscp 24 percent 90
      queue-limit dscp 48 percent 100
      queue-limit dscp 56 percent 100

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%

      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
      0 packets
      Match:  dscp af41 (34) af42 (36) af43 (38)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  4
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Trans-Data-Queue (match-any)
      0 packets
      Match:  dscp af21 (18) af22 (20) af23 (22)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  2
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
      0 packets
      Match:  dscp af11 (10) af12 (12) af13 (14)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  1
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 4%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Scavenger-Queue (match-any)
      0 packets
      Match:  dscp cs1 (8)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 1%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)
      0 packets
      Match:  dscp af31 (26) af32 (28) af33 (30)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 25%
      queue-buffers ratio 25

Example: auto qos voip cisco-softphone

The following is an example of the auto qos voip cisco-softphone command and the applied policies and class maps.

The following policy maps are created and applied when running this command:

AutoQos-4.0-CiscoSoftPhone-Input-Policy
AutoQos-4.0-Output-Policy

The following class maps are created and applied when running this command:

AutoQos-4.0-Voip-Data-Class (match-any)
AutoQos-4.0-Voip-Signal-Class (match-any)
AutoQos-4.0-Multimedia-Conf-Class (match-any)
AutoQos-4.0-Bulk-Data-Class (match-any)
AutoQos-4.0-Transaction-Class (match-any)
AutoQos-4.0-Scavanger-Class (match-any)
AutoQos-4.0-Signaling-Class (match-any)
AutoQos-4.0-Default-Class (match-any)
class-default (match-any)
AutoQos-4.0-Output-Priority-Queue (match-any)
AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
AutoQos-4.0-Output-Trans-Data-Queue (match-any)
AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
AutoQos-4.0-Output-Scavenger-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)


Device(config)# interface GigabitEthernet1/0/20
Device(config-if)# auto qos voip cisco-softphone
Device(config-if)# end
Device# show policy-map interface GigabitEthernet1/0/20


GigabitEthernet1/0/20

  Service-policy input: AutoQos-4.0-CiscoSoftPhone-Input-Policy

    Class-map: AutoQos-4.0-Voip-Data-Class (match-any)
      0 packets
      Match:  dscp ef (46)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp ef
      police:
          cir 128000 bps, bc 8000 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          set-dscp-transmit dscp table policed-dscp
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Voip-Signal-Class (match-any)
      0 packets
      Match:  dscp cs3 (24)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp cs3
      police:
          cir 32000 bps, bc 8000 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          set-dscp-transmit dscp table policed-dscp
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Multimedia-Conf-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-MultiEnhanced-Conf
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp af41
      police:
          cir 5000000 bps, bc 156250 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          drop
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Bulk-Data-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Bulk-Data
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp af11
      police:
          cir 10000000 bps, bc 312500 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          set-dscp-transmit dscp table policed-dscp
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Transaction-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Transactional-Data
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp af21
      police:
          cir 10000000 bps, bc 312500 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          set-dscp-transmit dscp table policed-dscp
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Scavanger-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Scavanger
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp cs1
      police:
          cir 10000000 bps, bc 312500 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          drop
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Signaling-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Signaling
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp cs3
      police:
          cir 32000 bps, bc 8000 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          drop
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Default-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Default
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp default
      police:
          cir 10000000 bps, bc 312500 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          set-dscp-transmit dscp table policed-dscp
        conformed 0000 bps, exceed 0000 bps

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps

  Service-policy output: AutoQos-4.0-Output-Policy

    queue stats for all priority classes:
      Queueing
      priority level 1

      (total drops) 0
      (bytes output) 0

    Class-map: AutoQos-4.0-Output-Priority-Queue (match-any)
      0 packets
      Match:  dscp cs4 (32) cs5 (40) ef (46)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 30% (300000 kbps), burst bytes 7500000,

      Priority Level: 1

    Class-map: AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
      0 packets
      Match:  dscp cs2 (16) cs3 (24) cs6 (48) cs7 (56)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue-limit dscp 16 percent 80
      queue-limit dscp 24 percent 90
      queue-limit dscp 48 percent 100
      queue-limit dscp 56 percent 100

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%

      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
      0 packets
      Match:  dscp af41 (34) af42 (36) af43 (38)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  4
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Trans-Data-Queue (match-any)
      0 packets
      Match:  dscp af21 (18) af22 (20) af23 (22)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  2
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
      0 packets
      Match:  dscp af11 (10) af12 (12) af13 (14)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  1
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 4%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Scavenger-Queue (match-any)
      0 packets
      Match:  dscp cs1 (8)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 1%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)
      0 packets
      Match:  dscp af31 (26) af32 (28) af33 (30)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 25%
      queue-buffers ratio 25

auto qos classify police

The following is an example of the auto qos classify police command and the applied policies and class maps.

The following policy maps are created and applied when running this command:

AutoQos-4.0-Classify-Police-Input-Policy
AutoQos-4.0-Output-Policy

The following class maps are created and applied when running this command:

AutoQos-4.0-Multimedia-Conf-Class (match-any)
AutoQos-4.0-Bulk-Data-Class (match-any)
AutoQos-4.0-Transaction-Class (match-any)
AutoQos-4.0-Scavanger-Class (match-any)
AutoQos-4.0-Signaling-Class (match-any)
AutoQos-4.0-Default-Class (match-any)
class-default (match-any)
AutoQos-4.0-Output-Priority-Queue (match-any)
AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
AutoQos-4.0-Output-Trans-Data-Queue (match-any)
AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
AutoQos-4.0-Output-Scavenger-Queue (match-any)
AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)


Device(config)# interface GigabitEthernet1/0/6
Device(config-if)# auto qos classify police
Device(config-if)# end
Device# show policy-map interface GigabitEthernet1/0/6


GigabitEthernet1/0/6

  Service-policy input: AutoQos-4.0-Classify-Police-Input-Policy

    Class-map: AutoQos-4.0-Multimedia-Conf-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-MultiEnhanced-Conf
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp af41
      police:
          cir 5000000 bps, bc 156250 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          drop
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Bulk-Data-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Bulk-Data
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp af11
      police:
          cir 10000000 bps, bc 312500 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          set-dscp-transmit dscp table policed-dscp
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Transaction-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Transactional-Data
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp af21
      police:
          cir 10000000 bps, bc 312500 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          set-dscp-transmit dscp table policed-dscp
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Scavanger-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Scavanger
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp cs1
      police:
          cir 10000000 bps, bc 312500 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          drop
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Signaling-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Signaling
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp cs3
      police:
          cir 32000 bps, bc 8000 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          drop
        conformed 0000 bps, exceed 0000 bps

    Class-map: AutoQos-4.0-Default-Class (match-any)
      0 packets
      Match: access-group name AutoQos-4.0-Acl-Default
        0 packets, 0 bytes
        5 minute rate 0 bps
      QoS Set
        dscp default
      police:
          cir 10000000 bps, bc 312500 bytes
        conformed 0 bytes; actions:
          transmit
        exceeded 0 bytes; actions:
          set-dscp-transmit dscp table policed-dscp
        conformed 0000 bps, exceed 0000 bps

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps

  Service-policy output: AutoQos-4.0-Output-Policy

    queue stats for all priority classes:
      Queueing
      priority level 1

      (total drops) 0
      (bytes output) 0

    Class-map: AutoQos-4.0-Output-Priority-Queue (match-any)
      0 packets
      Match:  dscp cs4 (32) cs5 (40) ef (46)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 30% (300000 kbps), burst bytes 7500000,

      Priority Level: 1

    Class-map: AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)
      0 packets
      Match:  dscp cs2 (16) cs3 (24) cs6 (48) cs7 (56)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  3
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue-limit dscp 16 percent 80
      queue-limit dscp 24 percent 90
      queue-limit dscp 48 percent 100
      queue-limit dscp 56 percent 100

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%

      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)
      0 packets
      Match:  dscp af41 (34) af42 (36) af43 (38)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  4
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Trans-Data-Queue (match-any)
      0 packets
      Match:  dscp af21 (18) af22 (20) af23 (22)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  2
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Bulk-Data-Queue (match-any)
      0 packets
      Match:  dscp af11 (10) af12 (12) af13 (14)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: cos  1
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 4%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Scavenger-Queue (match-any)
      0 packets
      Match:  dscp cs1 (8)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 1%
      queue-buffers ratio 10

    Class-map: AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)
      0 packets
      Match:  dscp af31 (26) af32 (28) af33 (30)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 10%
      queue-buffers ratio 10

    Class-map: class-default (match-any)
      0 packets
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing

      (total drops) 0
      (bytes output) 0
      bandwidth remaining 25%
      queue-buffers ratio 25

auto qos global compact

The following is an example of the auto qos global compact command.


Device# configure terminal
Device(config)# auto qos global compact
Device(config)# interface GigabitEthernet1/2
Device(config-if)# auto qos voip cisco-phone

Device# show auto-qos

GigabitEthernet1/2
auto qos voip cisco-phone

Device# show running-config interface GigabitEthernet 1/0/2

interface GigabitEthernet1/0/2
auto qos voip cisco-phone
end

Where to Go Next for Auto-QoS

Review the QoS documentation if you require any specific QoS changes to your auto-QoS configuration.

Additional References for Auto-QoS

Related Topic	Document Title
For complete syntax and usage information for the commands used in this chapter.	QoS Command Reference (Catalyst 3850 Switches) Cisco IOS Quality of Service Solutions Command Reference

Error Message Decoder


Description	Link
To help you research and resolve system error messages in this release, use the Error Message Decoder tool.	https://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi

Standards and RFCs


Standard/RFC	Title
—

MIBs


MIB	MIBs Link
All the supported MIBs for this release.	To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: http://www.cisco.com/go/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.	http://www.cisco.com/support

Feature History and Information for Auto-QoS


Release	Modification
Cisco IOS XE 3.2SE	This feature was introduced.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

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 Quality of Service

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?
Bandwidth requirements and speed of the network.
Location of congestion points in the network.

QoS Components

Quality of service (QoS) consists of the following key components:

Classification— Classification is the process of distinguishing one type of traffic from another based upon access control lists (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 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 , and the Differentiated Services Code Point (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 device) is the same as ingress.
Downstream (direction from the device) is the same as egress.

Note

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

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

The following are specific features provided by QoS:

Low latency
Bandwidth guarantee
Buffering capabilities and dropping disciplines
Traffic policing
Enables the changing of the attribute of the frame or packet header
Relative services

Modular QoS Command-Line Interface

With the device, 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:

Wireless ports, including all physical ports to which an access point can be associated.
Radio
SSID (applicable on a per-radio, per-AP, and per-SSID)
Client

From Cisco IOS XE Release 3E, marking and policing actions for ingress SSID and client policies are applied at the access point. The SSID and client ingress policies that you configure in the are moved to the access point. The access point performs policing and marking actions for each packet. However, the selects the QoS policies. Marking and policing of egress SSID and client policies are applied at the .

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

Table 2. Wireless Targets Policies Support
Wireless Target	Policies on Wireless Targets Supported	Policies Supported Egress Direction	Policies Supported Ingress Direction
Wireless port	Yes	Yes - user configurable	No
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 multidestination policers and VLANs.

Wireless QoS supports the following features:

Queuing in the egress direction.
Policing of wireless traffic
Marking of wireless traffic.
Shaping of wireless traffic in the egress direction.
Approximate Fair Drop (AFD) in the egress direction.
Mobility support for QoS.
Compatibility with precious metal QoS policies available on Cisco Unified Wireless Controllers.
Combination of CLI/Traffic Class (TCLAS) and CLI/snooping.
Application control (can drop or mark the data traffic) by configuring an AVC QoS client policy.
Drop action for ingress policies.
QoS statistics for client and SSID targets in the ingress direction.
QoS attribute for local profiling policy.
Hierarchical policies.

QoS and IPv6 for Wireless

The supports QoS for both IPv4 and IPv6 traffic, and client policies can now have IPv4 and IPv6 filters.

Wired and Wireless Access Supported Features

The following table describes the supported features for both wired and wireless access.

Table 3. Supported QoS Features for Wired and Wireless Access
Feature	Wired	Wireless
Targets	Gigabit Ethernet 10 Gigabit Ethernet VLAN	Wireless port (CAPWAP tunnel) SSID Client Radio CAPWAP multicast tunnel
Configuration Sequence	QoS policy installed using the service-policy command.	When an access point joins the switch, the switch installs a policy on the port. The port policy has a child policy called port_child_policy. A policy is installed on the radio which has a shaper configured to the radio rate. The default radio policy (which cannot be modified) is attached to the radio. The default client policies take effect when a WMM client associates, and if admission control is enabled on the radio. User can modify the port_child_policy to add more classes. User can attach a user-defined policy at the SSID level. User can attach a user-defined policy at the client level.
Number of queues permitted at port level	Up to 8 queues supported on a port.	Only four queues supported.
Classification mechanism	DSCP IP precedence CoS QoS-group ACL membership including: IPv4 ACLs IPv6 ACLS MAC ACLs	Port level Ingress: QoS policies not supported on ingress in wireless ports. Egress: Only DSCP based classification. SSID level Ingress: DSCP, UP Egress: DSCP,COS, QoS group Client level Ingress: ACL, DSCP, UP Egress: DSCP and COS

Supported QoS Features on Wireless Targets

This table describes the various features available on wireless targets.

Table 4. QoS Features Available on Wireless Targets
Target	Features	Traffic	Direction Where Policies Are Applicable	Comments
Port	Port shaper Priority queuing Multicast policing	Non-Real Time (NRT), Real Time (RT)	Egress
Radio	Shaping	Non-Real Time	Egress	Radio policies are not user configurable.
SSID	Police Table map	Non-Real Time, Real Time	Ingress and egress
	Shaping		Egress
	BRR		Egress
	Set actions Table map set dscp set cos		Ingress	You can use set in both class-default and user-defined classes of SSID ingress policies. You can define table maps only in the class-default class of an SSID policy.
	Set actions Table map set dscp set wlan user-priority		Egress
	Drop		Ingress
Client	Police	Non-Real Time, Real time	Ingress and egress	For client policies, the following filters are supported: ACL DSCP CoS (only for egress) WLAN UP protocol
	Drop		Ingress
	Set actions set dscp set cos		Ingress
	Set actions set dscp set wlan user-priority		Egress

Port Policies

Note

Port child policies only apply to wireless ports and not to wired ports on the switch. A wireless port is defined as a port to which APs join. A default port child policy is applied on the switch to the wireless ports at start up.The port shaper rate is limited to 1G

Port shaper specifies the traffic policy applicable between the device and 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, class-default, and non-client-nrt 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.

Port Policy Format

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

Default class map:



Class Map match-any non-client-nrt-class
   Match non-client-nrt

The above port policy processes all network traffic to the Q3 queue. You can view the class map by executing the show class-map command.

Default policy map:

Policy Map port_child_policy
    Class non-client-nrt-class
      bandwidth remaining ratio 10

Note

The class map and policy map listed are system-defined policies and cannot be changed.

The following is the system-defined policy map available on the ports on which wireless devices are associated. The format consists of a parent policy and a service child policy (port_child_policy). To customize the policies to suite your network needs, you must configure the port child policy.


Policy-map policy_map_name
    Class class-default 
         Shape average average_rate
         Service-policy port_child_policy

Note

The parent policy is system generated and cannot be changed. You must configure the port_child_policy policy to suit the QoS requirements on your network.

Depending on the type of traffic in your network, you can configure the port child policy. For example, in a typical wireless network deployment, you can assign specific priorities to voice and video traffic. Here is an example:


Policy-map port_child_policy 
     Class  voice-policy-name (match dscp ef)
          Priority level 1
         Police (multicast-policer-name-voice) Multicast Policer
    Class video-policy-name (match dscp af41)
        Priority level 2
        Police (multicast-policer-name-video) Multicast Policer
Class non-client-nrt-class traffic(match non-client-nrt)
        Bandwidth remaining ratio (brr-value-nrt-q2)
    Class class-default  (NRT Data)
        Bandwidth remaining ratio (brr-value-q3)

In the above port child policy:

voice-policy-name— Refers to the name of the class that specifies rules for the traffic for voice packets. Here the DSCP value is mapped to a value of 46 (represented by the keyword ef ). The voice traffic is assigned the highest priority of 1.
video-policy-name— Refers to the name of the class that specifies rules for the traffic for video packets. The DSCP value is mapped to a value of 34 (represented by the keyword af41 ).
multicast-policer-name-voice— If you need to configure multicast voice traffic, you can configure policing for the voice class map.
multicast-policer-name-video— If you need to configure multicast video traffic, you can configure policing for the video class map.

In the above sample configuration, all voice and video traffic is directed to the Q0 and Q1 queues, respectively. These queues maintain a strict priority. The packets in Q0 and Q1 are processed in that order. The bandwidth remaining ratios brr-value-nrt-q2 and brr-value-q3 are directed to the Q2 and Q3 respectively specified by the class maps and class-default and non-client-nrt. The processing of packets on Q2 and Q3 are based on a weighted round-robin approach. For example, if the brr-value-nrtq2 has a value of 90 and brr-value-nrtq3 is 10, the packets in queue 2 and queue 3 are processed in the ratio of 9:1.

Radio Policies

The radio policies are system defined and are not user configurable. Radio wireless targets are only applicable in the egress 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.

The following radios are supported:

802.11 a/n
802.11 b/n
802.11 ac

SSID Policies

You can create QoS policies on SSID BSSID (Basic Service Set Identification) in both the ingress and egress 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 (Real Time 1) and RT2 (Real Time 2) policiers. If traffic is ingress, you usually configure a marking and policing 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.

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

Client Policies

Client policies are applicable in the ingress and egress direction. The wireless control module of the device 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
Using the Cisco IOS MQC CLI
- You can use service policy client command in the WLAN configuration.
Using the default configuration
Using local policies (native profiling)

Use the show wireless client mac address mac_address service-policy command to display the source of the client policy (for example, local profiling policy, AAA, or CLI). The precedence order of client policies is AAA > local policy > WLAN service client policy CLI > default configuration.

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.

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.

The default client policy is enabled only on Wi-Fi Multimedia (WMM) clients that are admission control (ACM)-enabled.

Policy Chaining

Every packet has a maximum of two applicable policies, first at the client target and second at the SSID target. The client policing action is applied to the packet before the marking action that is specified in the client policy. After the client policing and marking actions are applied to the packet, the SSID policy action is applied to the updated packet. If no custom policies are specified, the system trust configuration is applied to the packet. Egress trust is based on DSCP, and ingress trust is based on WLAN user priority.

Hierarchical QoS

The supports hierarchical QoS (HQoS). HQoS allows you to perform:

Hierarchical classification— Traffic classification is based upon other classes.
Hierarchical policing—The process of having the policing configuration at multiple levels in a hierarchical policy.

Hierarchical shaping—Shaping can also be configured at multiple levels in the hierarchy.

Note

Hierarchical shaping is only supported for the port shaper, where for the parent you only have a configuration for the class default, and the only action for the class default is shaping.

Hierarchical Wireless QoS

The device 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. You can configure policing in both the parent and child policies.

Note

For hierarchical client and SSID policies, you only configure marking either in the parent or child policy.

Wireless Packet Format

Figure 1. 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 device. The device 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 2. 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.

IP precedence values range from 0 to 7. DSCP values range from 0 to 63.

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

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 information that is device specific
Hierarchical classification

Classification Based on Information That is Propagated with the Packet

Classification that is based on information that is part of the packet and propagated either end-to-end or between hops, typically includes the following:

Classification based on Layer 3 or 4 headers
Classification based on Layer 2 information

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 5. 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 device 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 device 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 device. It is important to note that a QoS group is an internal label to the device and is not part of the packet header.

Hierarchical Classification

The device 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 device 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 device, 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 device meets a specific traffic profile.

Ingress Port Activity

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

Classification—Classifying a distinct path for a packet by associating it with a QoS label. For example, the device 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 device.

Egress Port Activity

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

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

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

Note

Deny action is supported in Cisco IOS Release 3.7.4E and later releases.

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

You implement IP ACLs to classify IP traffic by using the access-list global configuration command; you implement Layer 2 MAC ACLs to classify non-IP traffic by using the mac access-list extended global configuration command.

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

Note

You cannot configure both priority and set for a policy map. If both these commands are configured for a policy map, and when the policy map is applied to an interface, error messages are displayed. The following example shows this restriction:

Switch# configure terminal
Switch(config)# class-map cmap
Switch(config-cmap)# exit
Switch(config)# class-map classmap1
Switch(config-cmap)# exit
Switch(config)# policy-map pmap
Switch(config-pmap)# class cmap
Switch(config-pmap-c)# priority
Switch(config-pmap-c)# exit
Switch(config-pmap)# class classmap1
Switch(config-pmap-c)# set
Switch(config-pmap-c)# exit
Switch(config-pmap)# exit
Switch(config)# interface gigabitethernet 0/1/1
Switch(config-if)# service-policy output pmap

Non-queuing action only is unsupported in a queuing policy!!!
%QOS-6-POLICY_INST_FAILED:
Service policy installation failed

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 class class-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 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 Multicast

You can configure multicast policing rate at the port level.

Policing

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

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

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

Note

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

You can only configure policing on a physical port.

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

Token-Bucket Algorithm

Policing uses a token-bucket algorithm. As each frame is received by the device, a token is added to the bucket. The bucket has a hole in it and leaks at a rate that you specify as the average traffic rate in bits per second. Each time a token is added to the bucket, the device verifies that there is enough room in the bucket. If there is not enough room, the packet is marked as nonconforming, and the specified policer action is taken (dropped or marked down).

How quickly the bucket fills is a function of the bucket depth (burst-byte), the rate at which the tokens are removed (rate-bps), and the duration of the burst above the average rate. The size of the bucket imposes an upper limit on the burst length and limits the number of frames that can be transmitted back-to-back. If the burst is short, the bucket does not overflow, and no action is taken against the traffic flow. However, if a burst is long and at a higher rate, the bucket overflows, and the policing actions are taken against the frames in that burst.

You configure the bucket depth (the maximum burst that is tolerated before the bucket overflows) by using the burst-byte option of the police policy-map class configuration command. You configure how fast (the average rate) that the tokens are removed from the bucket by using the rate option of the police policy-map class configuration command.

Marking

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

Packet header
Device ) specific information
Table maps

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

Note

QoS marking is not supported on the 802.11ac Wave 2 APs. This is because table-maps used for QoS marking are not supported on the 802.11ac Wave 2 APs.

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 device allows configuring both ingress table map policies and egress table map policies.

Note

The device stack supports a total of 14 table maps. Only one table map is supported per wired port, per direction.

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 6. 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 7. 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 [ B_c] and extended burst size [B_e] ) are all configured in bytes per second.

The following policing forms or policers are supported for QoS:

Single-rate two-color policing
Dual-rate three-color policing

Note

Single-rate three-color policing is not supported.

Single-Rate Two-Color Policing

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

The B_c 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 B_c, the packet is considered to have exceeded the configured rate.

Note

For information about the token-bucket algorithm, see Token-Bucket Algorithm.

Dual-Rate Three-Color Policing

With the dual rate policer, the device 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.

Note

For information about the token-bucket algorithm, see Token-Bucket Algorithm.

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:

Time interval between packets (T2-T1) * CIR)/8 bytes

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 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, B_c and B_e determine the rate at which the packets are sent out and the rate at which the tokens are replenished.

Note

For information about the token-bucket algorithm, see Token-Bucket Algorithm.

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

Queueing and Scheduling

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

Bandwidth
Weighted Tail Drop
Priority queues
Queue buffers

When you define a queuing policy on a port, control packets are mapped to the best priority queue with the highest threshold. Control packets queue mapping works differently in the following scenarios:

Without a quality of service (QoS) policy—If no QoS policy is configured, control packets with DSCP values 16, 24, 48, and 56 are mapped to queue 0 with the highest threshold of threshold2.

With an user-defined policy—An user-defined queuing policy configured on egress ports can affect the default priority queue setting on control packets.

Control traffic is redirected to the best queue based on the following rules:

If defined in a user policy, the highest- level priority queue is always chosen as the best queue.
In the absence of a priority queue, Cisco IOS software selects queue 0 as the best queue. When the software selects queue 0 as the best queue, you must define the highest bandwidth to this queue to get the best QoS treatment to the control plane traffic.
If thresholds are not configured on the best queue, Cisco IOS software assigns control packets with Differentiated Services Code Point (DSCP) values 16, 24, 48, and 56 are mapped to threshold2 and reassigns the rest of the control traffic in the best queue to threshold1.

If a policy is not configured explicitly for control traffic, the Cisco IOS software maps all unmatched control traffic to the best queue with threshold2, and the matched control traffic is mapped to the queue as configured in the policy.

Note

To provide proper QoS for Layer 3 packets, you must ensure that packets are explicitly classified into appropriate queues. When the software detects DSCP values in the default queue, then it automatically reassigns this queue as the best queue.

Bandwidth

The supports the following bandwidth configurations:

Bandwidth percent
Bandwidth remaining ratio

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 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 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 3. 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 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 8. 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.

Note

You can configure a priority only with a level.

Only one strict priority or a priority with levels is allowed in one policy map. Multiple priorities with the same priority levels without kbps/percent are allowed in a policy map only if all of them are configured with police.

Queue Buffer

In Cisco IOS XE Release 3.7.5 E and later releases, all downlink ports are allocated 1 GB port buffer, even though the downlink port size is 10GB. Prior to this change, all 1 GB downlink ports had 1 GB buffer and 10 GB downlink ports had 10 GB buffer.

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 9. 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 Buffer Allocation

The buffer allocation to any queue can be tuned using the queue-buffers ratio policy-map class configuration command.

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

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.

Note

The wired ports support eight queues.

Trust Behavior for Wired and Wireless Ports

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

Port Security on a Trusted Boundary for Cisco IP Phones

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

Note

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

With the trusted setting, you also can use the trusted boundary feature to prevent misuse of a high-priority queue if a user bypasses the telephone and connects the PC directly to the device. Without trusted boundary, the CoS labels generated by the PC are trusted by the device (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 device port. If the telephone is not detected, the trusted boundary feature disables the trusted setting on the device 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 device.

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 device. Wireless client roaming can be classified into two types:

Intra-device roaming
Inter-device roaming

Note

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

Inter-Device Roaming

When a client roams from one location to another, the client can get associated to access points either associated to the same device (anchor device) or a different device (foreign device). Inter-device 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-device roaming, the client QoS policy is always executed on the foreign controller. When a client roams from anchor device to foreign device, the QoS policy is uninstalled on the anchor device and installed on the foreign device. In the mobility handoff message, the anchor device passes the name of the policy to the foreign device. The foreign device should have a policy with the same name configured for the QoS policy to be applied correctly.

In the case of inter-device 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.

During inter-device roaming, client and SSID policy statistics are collected only for the duration that the client is associated with the foreign device. Cumulative statistics for the whole roaming (anchor device and foreign device) are not collected.

Intra-Device Roaming

With intra-device roaming, the client gets associated to an access point that is associated to the same device 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-device 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. You can configure precious metal policies only for SSID ingress and egress policies.

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

Default Wired QoS Configuration

There are two queues configured by default on each wired interface on the device. 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

When DSCP transparency mode is disabled, the DSCP values are derived from CoS as per the following table. If these values are not appropriate for your network, you need to modify them.

Note

The DSCP transparency mode is disabled by default. If it is enabled (no mls qos rewrite ip dscp interface configuration command), DSCP rewrite will not happen.

Table 11. 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 12. 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 13. 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

Default Wireless QoS Configuration

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

Guidelines for QoS Policies

Follow these guidelines to prevent clients from getting excluded due to malformed QoS policies:

When a new QoS policy is added to the device, a QoS policy with the same name should be added to other device within the same roam or mobility domain.
When a device is loaded with a software image of a later release, the new policy formats are supported. If you have upgraded the software image from an earlier release to a later release, you should save the configuration separately. When an earlier release image is loaded, some QoS policies might show as not supported, and you should restore those QoS policies to supported policy formats.

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

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

A maximum of 8 queuing classes are supported on the device port for the wired target.
A maximum of 63 policers are supported per policy on the wired port for the wired target.
In Cisco IOS XE Release 3.7.5E and later releases, by default all downlink ports are allocated 1 GB port buffer, even though the downlink port size is 10 GB. Prior to this change, all 1 GB downlink ports had 1 GB buffer and 10 GB downlink ports had 10 GB buffer.
A maximum of 1599 policy-maps can be created.
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 device because the queue-buffer command handles this functionality. Queue limit is only supported with the DSCP and CoS extensions.

With shaping, there is an IPG overhead of 20Bytes for every packet that is accounted internally in the hardware. Shaping accuracy will be effected by this, specially for packets of small size.
The classification sequence for all wired queuing-based policies should be the same across all wired upstream ports (10-Gigabit Ethernet), and the same for all downstream wired ports (1-Gigabit Ethernet).
Empty classes are not supported.
Class-maps with empty actions are not supported. If there are two policies with the same order of class-maps and if there are class-maps with no action in one of the policies, there may be traffic drops. As a workaround, allocate minimal bandwidth for all the classes in PRIORITY_QUEUE.
A maximum of 256 classes are supported per policy on the wired port for the wired target.
The actions under a policer within a policy map have the following restrictions:
- The conform action must be transmit.
- The exceed/violate action for markdown type can only be cos2cos, prec2prec, dscp2dscp.
- The markdown types must be the same within a policy.
A port-level input marking policy takes precedence over an SVI policy; however, if no port policy is configured, the SVI policy takes precedence. For a port policy to take precedence, define a port-level policy; so that the SVI policy is overwritten.
Classification counters have the following specific restrictions:
- Classification counters count packets instead of bytes.
- Filter-based classification counters are not supported
- Only QoS configurations with marking or policing trigger the classification counter.
- The classification counter is not port based. This means that the classification counter aggregates all packets belonging to the same class of the same policy which attach to different interfaces.
- As long as there is policing or marking action in the policy, the class-default will have classification counters.
- When there are multiple match statements in a class, then the classification counter only shows the traffic counter for one of the match statements.
Table maps have the following specific restrictions:
- Only one table map for policing exceeding the markdown and one table map for policing violating the markdown per direction per target is supported.
- Table maps must be configured under the class-default; table maps are unsupported for a user-defined class.
Hierarchical policies are required for the following:
- Port-shapers
- Aggregate policers
- PV policy
- Parent shaping and child marking/policing
In a HQoS policy with parent shaping and child policy having priority level queuing and priority level policing, the statistics for policing are not updated. Only QoS shaper statistics are updated. To view the QoS shaper statistics, use the show policy-map interface command in global configuration mode.
For ports with wired targets, these are the only supported hierarchical policies:
- Police chaining in the same policy is unsupported, except for wireless client.
- Hierarchical queueing is unsupported in the same policy (port shaper is the exception).
- In a parent class, all filters must have the same type. The child filter type must match the parent filter type with the following exceptions:
  - If the parent class is configured to match IP, then the child class can be configured to match the ACL.
  - If the parent class is configured to match CoS, then the child class can be configured to match the ACL.
The trust device device_type command available in interface configuration mode is a stand-alone command on the device. When using this command in an AutoQoS configuration, if the connected peer device is not a corresponding device (defined as a device matching your trust policy), both CoS and DSCP values are set to "0" and any input policy will not take effect. If the connected peer device is a corresponding device, input policy will take effect.

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

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

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

QoS is not supported on an EtherChannel interface.
QoS is supported on EtherChannel member interfaces in both ingress and egression directions. All EtherChannel members must have the same QoS policy applied. If the QoS policy is not the same, each individual policy on the different link acts independently.
On attaching a service policy to channel members, the following warning message appears to remind the user to make sure the same policy is attached to all ports in the EtherChannel: ' Warning: add service policy will cause inconsistency with port xxx in ether channel xxx. '.
Auto QoS is not supported on EtherChannel members.

Note

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

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

Note

Auto QOS SRND is enabled by default on the Cisco Catalyst 4500E Supervisor Engine 8-E. When AP is connected, egress QoS policy is automatically applied on the AP connected ports and the QoS policy is removed when the AP is disconnected. This policy classification is applied through DSCP, so the drop threshold can be configured for voice and CAPWAP control packets. All other traffic goes to different queues.If you prefer to have a different QoS policy to prioritize different class of traffic, you can configure it using the ’no auto qos srnd4' command. This will remove the Auto QOS SRND4 policies attached to AP connected port and BB-DC inter-link port, and a default policy to protect CAPWAP control and voice traffic will be attached to BB-DC inter-link port.

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 egress direction.
SSID and client targets can be configured only with marking and policing policies.
One policy per target per direction is supported.
For the egress class-default SSID policy, you must configure the queue buffer ratio as 0 after you configure the average shape rate.
Class maps in a policy map can have different types of filters. However, only one marking action (either table map, or set dscp, or set cos) is supported in a map in egress direction.
For hierarchical client and SSID ingress policies, you cannot configure marking in both the parent and child policies. You can only configure marking either in the parent or child policy.
You cannot configure multiple set actions in the same class.
For both SSID and client ingress policies, supported set actions are only for DSCP, and CoS values.
You cannot delete a group of WLANs or QoS policy.

Wireless QoS Restrictions on Ports

The following are restrictions for applying QoS features on a wireless port target:

All wireless ports have similar parent policy with one class-default and one action shape under class-default. Shape rates are dependent on the 802.11a/b/g/ac bands.
You can create a maximum of four classes in a child policy by modifying the port_chlid_policy.
If there are four classes in the port_child_policy at the port level, one must be a non-client-nrt class and one must be class-default.
No two classes can have the same priority level. Only priority level 1 (for voice traffic and control traffic) and 2 (for video) are supported.
Priority is not supported in the multicast NRT class (non-client-nrt class) and class-default.
If four classes are configured, two of them have to be priority classes. If only three classes are configured, at least one of them should be a priority class. If three classes are configured and there is no non-client-nrt class, both priority levels must be present.
Only match DSCP is supported.
The port policy applied by the wireless control module cannot be removed using the CLI.
Both priority rate and police CIR (using MQC) in the same class is unsupported.
Queue limit (which is used to configure Weighted Tail Drop) is unsupported.

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.

If a wireless port has a default policy with only two queues (one for multicast-NRT, one for class-default), the policy at SSID level cannot have voice and video class in the egress direction.
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.
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 function for the voice and video classes in the port level policy.
No action is allowed under the class-default of a child policy.
For SSID ingress policies, only UP and DSCP filters (match criteria) are supported. ACL and protocol match criteria are not supported.
For a flat policy (non hierarchical), in the ingress direction, the policy configuration must be a set (table map) or policing or both.

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 egress 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.
Only set marking actions are supported in the client policies.
For client ingress policies, only ACL, UP, DSCP, and protocol filters (match criteria) are supported.

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.

For filters matching on ACLs, all ACEs (Access Control Entry) in the access list should have the same type and number of attributes.
In client egress policies, all filters in the policy-map must match on the same marking attribute for filters matching on marking attributes. For example, If filter matches on DSCP, then all filters in the policy must match on DSCP.
ACL matching on port ranges and subnet are only supported in ingress direction.

Creating a Traffic Class (CLI)

To create a traffic class containing match criteria, use the class-map command to specify the traffic class name, and then use the following match commands in class-map configuration mode, as needed.

Before you begin

All match commands specified in this configuration task are considered optional, but you must configure at least one match criterion for a class.

Procedure

Command or Action Purpose

Step 1

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 2

class-map class-map name{ match-any | match-all}

Example:


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

Enters class map configuration mode.

Creates a class map to be used for matching packets to the class whose name you specify.
match-any: Any one of the match criteria must be met for traffic entering the traffic class to be classified as part of it.

match-all: All of the match criteria must be met for traffic entering the traffic class to be classified as part of the traffic class.

Note

This is the default. If match-any or match-all is not explicitly defined, match-all is chosen by default.

Step 3

match access-group { index number| name}

Example:


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

The following parameters are available for this command:

access-group
class-map
cos
dscp
ip
non-client-nrt
precedence
qos-group
vlan
wlan user priority

(Optional) For this example, enter the access-group ID:

Access list index (value from 1 to 2799)
Named access list

Step 4

match class-map class-map name

Example:


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

(Optional) Matches to another class-map name.

Step 5

match cos cos value

Example:


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

(Optional) Matches IEEE 802.1Q or ISL class of service (user) priority values.

Enters up to 4 CoS values separated by spaces (0 to 7).

Step 6

match dscp dscp value

Example:


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

(Optional) Matches the DSCP values in IPv4 and IPv6 packets.

Step 7

match ip { dscp dscp value| precedence precedence value}

Example:


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

(Optional) Matches IP values including the following:

dscp—Matches IP DSCP (DiffServ codepoints).

precedence—Matches IP precedence (0 to 7).

Note

Since CPU generated packets are not marked at egress, the packet will not match the configured class-map.

Step 8

match non-client-nrt

Example:


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

(Optional) Matches non-client NRT (Non-Real-Time).

Note

This match is applicable only for policies on a wireless port. It carries all the multi-destination and AP (non-client) bound traffic.

Step 9

match qos-group qos group value

Example:


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

(Optional) Matches QoS group value (from 0 to 31).

Step 10

match vlan vlan value

Example:


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

(Optional) Matches a VLAN ID (from 1 to 4095).

Step 11

match wlan user-priority wlan value

Example:


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

(Optional) Matches 802.11e specific values. Enter the user priority 802.11e user priority (0 to 7).

Step 12

end

Example:


Device(config-cmap)# end

Saves the configuration changes.

What to do next

Configure the policy map.

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 device is automatically in policy map class configuration mode, which is where the QoS policies for the traffic policy are defined.

The following policy map class-actions are supported:

admit—Admits the request for Call Admission Control (CAC).
bandwidth—Bandwidth configuration options.
exit—Exits from the QoS class action configuration mode.
no—Negates or sets default values for the command.
police—Policer configuration options.
priority—Strict scheduling priority configuration options for this class.
queue-buffers—Queue buffer configuration options.
queue-limit—Queue maximum threshold for Weighted Tail Drop (WTD) configuration options.
service-policy—Configures the QoS service policy.
set—Sets QoS values using the following options:
- CoS values
- DSCP values
- Precedence values
- QoS group values
- WLAN values
shape—Traffic-shaping configuration options.

Before you begin

You should have first created a class map.

Procedure

Command or Action Purpose

Step 1

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 2

policy-map policy-map name

Example:


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

Enters policy map configuration mode.

Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.

Step 3

class { class-name| class-default}

Example:


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

Specifies the name of the class whose policy you want to create or change.

You can also create a system default class for unclassified packets.

Step 4

admit

Example:


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

(Optional) Admits the request for Call Admission Control (CAC). For a more detailed example of this command and its usage, see the section Configuring Call Admission Control.

Note

This command only configures CAC for wireless QoS.

Step 5

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

Example:


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

(Optional) Sets the bandwidth using one of the following:

kb/s—Kilobits per second, enter a value between 20000 and 10000000 for Kb/s.
percent—Enter the percentage of the total bandwidth to be used for this policy map.
remaining—Enter the percentage ratio of the remaining bandwidth.

For a more detailed example of this command and its usage, see Configuring Bandwidth (CLI).

Step 6

exit

Example:


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

(Optional) Exits from QoS class action configuration mode.

Step 7

no

Example:


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

(Optional) Negates the command.

Step 8

police { target_bit_rate |cir | rate}

Example:


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

(Optional) Configures the policer:

target_bit_rate—Enter the bit rate per second, enter a value between 8000 and 10000000000.
cir—Committed Information Rate
rate—Specify police rate, PCR for hierarchical policies or SCR for single-level ATM 4.0 policer policies.

For a more detailed example of this command and its usage, see Configuring Police (CLI).

Step 9

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

Example:


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

(Optional) Sets the strict scheduling priority for this class. Command options include:

kb/s—Kilobits per second, enter a value between 1 and 2000000.
level—Establishes a multi-level priority queue. Enter a value (1 or 2).
percent—Enter a percent of the total bandwidth for this priority.

For a more detailed example of this command and its usage, see Configuring Priority (CLI).

Step 10

queue-buffers ratio ratio limit

Example:


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

(Optional) Configures the queue buffer for the class. Enter the queue buffers ratio limit (0 to 100).

For a more detailed example of this command and its usage, see Configuring Queue Buffers (CLI).

Step 11

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

Example:


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

(Optional) Specifies the queue maximum threshold for the tail drop:

packets—Packets by default, enter a value between 1 to 2000000.
cos—Enter the parameters for each COS value.
dscp—Enter the parameters for each DSCP value.
percent—Enter the percentage for the threshold.

For a more detailed example of this command and its usage, see Configuring Queue Limits (CLI).

Step 12

service-policy policy-map name

Example:


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

(Optional) Configures the QoS service policy.

Step 13

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

Example:


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

(Optional) Sets the QoS values. Possible QoS configuration values include:

cos—Sets the IEEE 802.1Q/ISL class of service/user priority.
dscp—Sets DSCP in IP(v4) and IPv6 packets.
ip—Sets IP specific values.
precedence—Sets precedence in IP(v4) and IPv6 packet.
qos-group—Sets the QoS Group.
wlan—Sets the WLAN user-priority.

Step 14

shape average { target _bit_rate| percent}

Example:


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

(Optional) Sets the traffic shaping. Command parameters include:

target_bit_rate—Target bit rate.
percent—Percentage of interface bandwidth for Committed Information Rate.

For a more detailed example of this command and its usage, see Configuring Shaping (CLI).

Step 15

end

Example:


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

Saves the configuration changes.

What to do next

Configure the interface.

Configuring Client Policies

You can configure client policies using one of the following methods:


Method	Topic/ Details
Default client policies	The wireless control module of the applies the default client policies when admission control (ACM) is enabled for WMM clients. When ACM is disabled, there is no default client policy. The default policies are: Ingress—cldeffromWMM Egress—cldeftoWMM You can verify if ACM is enabled by using the show ap dot11 `{` 5ghz `\|` 24ghz`}` command. To enable ACM, use the ap dot11 `{` 5ghz `\|` 24ghz`}` cac voice acm command.
Apply the client policy on the WLAN using the CLI.	Applying an SSID or Client Policy on a WLAN (CLI)
Apply the QoS attributes policy using a local profiling policy using the CLI.	Applying a Local Policy for a Device on a WLAN (CLI)
Apply policy map through a AAA server (ACS/ISE)	Cisco Identity Services Engine User Guide Cisco Secure Access Control System User Guide

Configuring Class-Based Packet Marking (CLI)

This procedure explains how to configure the following class-based packet marking features on your device:

CoS value
DSCP value
IP value
Precedence value
QoS group value
WLAN value

Before you begin

You should have created a class map and a policy map before beginning this procedure.

Procedure

Command or Action Purpose

Step 1

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 2

policy-map policy name

Example:


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

Enters policy map configuration mode.

Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.

Step 3

class class name

Example:


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

Enters policy class map configuration mode. Specifies the name of the class whose policy you want to create or change.

Command options for policy class map configuration mode include the following:

admit—Admits the request for Call Admission Control (CAC).
bandwidth—Bandwidth configuration options.
exit—Exits from the QoS class action configuration mode.
no—Negates or sets default values for the command.
police—Policer configuration options.
priority—Strict scheduling priority configuration options for this class.
queue-buffers—Queue buffer configuration options.
queue-limit—Queue maximum threshold for Weighted Tail Drop (WTD) configuration options.
service-policy—Configures the QoS service policy.
set—Sets QoS values using the following options:
- CoS values
- DSCP values
- Precedence values
- QoS group values
- WLAN values
shape—Traffic-shaping configuration options.

Note

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.

Step 4

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

Example:


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

(Optional) Sets the specific IEEE 802.1Q Layer 2 CoS value of an outgoing packet. Values are from 0 to7.

You can also set the following values using the set cos command:

cos table—Sets the CoS value based on a table map.
dscp table—Sets the code point value based on a table map.
precedence table—Sets the code point value based on a table map.
qos-group table—Sets the CoS value from QoS group based on a table map.
wlan user-priority table—Sets the CoS value from the WLAN user priority based on a table map.

Step 5

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

Example:


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

(Optional) Sets the DSCP value.

In addition to setting specific DSCP values, you can also set the following using the set dscp command:

default—Matches packets with default DSCP value (000000).
dscp table—Sets the packet DSCP value from DSCP based on a table map.
ef—Matches packets with EF DSCP value (101110).
precedence table—Sets the packet DSCP value from precedence based on a table map.
qos-group table—Sets the packet DSCP value from a QoS group based upon a table map.
wlan user-priority table—Sets the packet DSCP value based upon a WLAN user-priority based upon a table map.

Step 6

set ip {dscp | precedence}

Example:


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

(Optional) Sets IP specific values. These values are either IP DSCP or IP precedence values.

You can set the following values using the set ip dscp command:

dscp value—Sets a specific DSCP value.
default—Matches packets with default DSCP value (000000).
dscp table—Sets the packet DSCP value from DSCP based on a table map.
ef—Matches packets with EF DSCP value (101110).
precedence table—Sets the packet DSCP value from precedence based on a table map.
qos-group table—Sets the packet DSCP value from a QoS group based upon a table map.
wlan user-priority table—Sets the packet DSCP value based upon a WLAN user-priority based upon a table map.

You can set the following values using the set ip precedence command:

precedence value—Sets the precedence value (from 0 to 7) .
cos table—Sets the packet precedence value from Layer 2 CoS based on a table map.
dscp table—Sets the packet precedence from DSCP value based on a table map.
precedence table—Sets the precedence value from precedence based on a table map
qos-group table—Sets the precedence value from a QoS group based upon a table map.

Step 7

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

Example:


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

(Optional) Sets precedence values in IPv4 and IPv6 packets.

You can set the following values using the set precedence command:

precedence value—Sets the precedence value (from 0 to 7) .
cos table—Sets the packet precedence value from Layer 2 CoS on a table map.
dscp table—Sets the packet precedence from DSCP value on a table map.
precedence table—Sets the precedence value from precedence based on a table map.
qos-group table—Sets the precedence value from a QoS group based upon a table map.

Step 8

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

Example:


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

(Optional) Sets QoS group values. You can set the following values using this command:

qos-group value—A number from 1 to 31.
dscp table—Sets the code point value from DSCP based on a table map.
precedence table—Sets the code point value from precedence based on a table map.

Step 9

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

Example:


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

(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:


Device(config-pmap)# end
Device#

Saves configuration changes.

Step 11

show policy-map

Example:


Device# 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:

Procedure

	Command or Action	Purpose
Step 1	class-map `class-map-name` Example: `Device(config)# class-map voice`	Creates a class map.
Step 2	match dscp `dscp-value-for-voice` Example: `Device(config-cmap)# match dscp 46`	Matches the DSCP value in the IPv4 and IPv6 packets. Set this value to 46.
Step 3	class-map `class-map-name` Example: `Device(config)# class-map video`	Configures a class map.
Step 4	match dscp `dscp-value-for-video` Example: `Device(config-cmap)# match dscp 34`	Matches the DSCP value in the IPv4 and IPv6 packets. Set this value to 34.

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.

Procedure

	Command or Action	Purpose
Step 1	configure terminal Example: `Device# configure terminal`	Enters global configuration mode.
Step 2	interface `type` Example: `Device(config)# interface GigabitEthernet1/0/1 Device(config-if)#`	Enters interface configuration mode and configures an interface. Command parameters for the interface configuration include: Auto Template— Auto-template interface Capwap—CAPWAP tunnel interface GigabitEthernet—Gigabit Ethernet IEEE 802 GroupVI—Group virtual interface Internal Interface— Internal interface Loopback—Loopback interface Null—Null interface Port-channel—Ethernet Channel of interface TenGigabitEthernet—10-Gigabit Ethernet Tunnel—Tunnel interface Vlan—Catalyst VLANs Range—Interface range
Step 3	service-policy {input `policy-map` \| output `policy-map` } Example: `Device(config-if)# service-policy output policy_map_01 Device(config-if)#`	Attaches a policy map to an input or output interface. This policy map is then used as the service policy for that interface. In this example, the traffic policy evaluates all traffic leaving that interface.
Step 4	end Example: `Device(config-if)# end Device#`	Saves configuration changes.
Step 5	show policy map Example: `Device# show policy map`	(Optional) Displays statistics for the policy on the specified interface.

What to do next

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

Applying an SSID or Client Policy on a WLAN (CLI)

Before you begin

You must have a service-policy map configured before applying it on an SSID.

Procedure

	Command or Action	Purpose
Step 1	configure terminal Example: `Device# configure terminal`	Enters global configuration mode.
Step 2	wlan `profile-name` Example: `Device# wlan test4`	Enters WLAN configuration submode. The `profile-name` is the profile name of the configured WLAN.
Step 3	service-policy [ input \| output ] `policy-name` Example: `Device(config-wlan)# service-policy input policy-map-ssid`	Applies the policy. The following options are available: input — Assigns the policy map to WLAN ingress traffic. output — Assigns the policy map to WLAN egress traffic.
Step 4	service-policy client [ input \| output ] `policy-name` Example: `Device(config-wlan)# service-policy client input policy-map-client`	Applies the policy. The following options are available: input — Assigns the client policy for ingress direction on the WLAN. output — Assigns the client policy for egress direction on the WLAN.
Step 5	end Example: `Device(config)# end`	Returns to privileged EXEC mode. Alternatively, you can also press Ctrl-Z to exit global configuration mode.

Classifying, Policing, and Marking Traffic on Physical Ports by Using Policy Maps (CLI)

You can configure a nonhierarchical policy map on a physical port that specifies which traffic class to act on. Actions supported are remarking and policing.

Before you begin

You should have already decided upon the classification, policing, and marking of your network traffic by policy maps prior to beginning this procedure.

Procedure

	Command or Action	Purpose
Step 1	configure terminal Example: `Device# configure terminal`	Enters global configuration mode.
Step 2	class-map `{` `class-map name` `\|` match-any `}` Example: `Device(config)# class-map ipclass1 Device(config-cmap)# exit Device(config)#`	Enters class map configuration mode. Creates a class map to be used for matching packets to the class whose name you specify. If you specify match-any, one of the match criteria must be met for traffic entering the traffic class to be classified as part of the traffic class. This is the default.
Step 3	match access-group { `access list index` \| `access list name` } Example: `Device(config-cmap)# match access-group 1000 Device(config-cmap)# exit Device(config)#`	Specifies the classification criteria to match to the class map. You can match on the following criteria: access-group—Matches to access group. class-map—Matches to another class map. cos—Matches to a CoS value. dscp—Matches to a DSCP value. ip—Matches to a specific IP value. non-client-nrt—Matches non-client NRT. precedence—Matches precedence in IPv4 and IPv6 packets. qos-group—Matches to a QoS group. vlan—Matches to a VLAN.
Step 4	policy-map `policy-map-name` Example: `Device(config)# policy-map flowit Device(config-pmap)#`	Creates a policy map by entering the policy map name, and enters policy-map configuration mode. By default, no policy maps are defined.
Step 5	class {`class-map-name` \| class-default} Example: `Device(config-pmap)# class ipclass1 Device(config-pmap-c)#`	Defines a traffic classification, and enter policy-map class configuration mode. By default, no policy map class-maps are defined. 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 .
Step 6	set `{` cos `\|` dscp `\|` ip `\|` precedence `\|` qos-group `\|` wlan user-priority`}` Example: `Device(config-pmap-c)# set dscp 45 Device(config-pmap-c)#`	(Optional) Sets the QoS values. Possible QoS configuration values include: cos—Sets the IEEE 802.1Q/ISL class of service/user priority. dscp—Sets DSCP in IP(v4) and IPv6 packets. ip—Sets IP specific values. precedence—Sets precedence in IP(v4) and IPv6 packet. qos-group—Sets QoS group. wlan user-priority—Sets WLAN user priority. In this example, the set dscp command classifies the IP traffic by setting a new DSCP value in the packet.
Step 7	police `{` `target_bit_rate` `\|`cir `\|` rate `}` Example: `Device(config-pmap-c)# police 100000 conform-action transmit exceed-action drop Device(config-pmap-c)#`	(Optional) Configures the policer: target_bit_rate—Specifies the bit rate per second, enter a value between 8000 and 10000000000. cir—Committed Information Rate. rate—Specifies the police rate, PCR for hierarchical policies, or SCR for single-level ATM 4.0 policer policies. In this example, the police command adds a policer to the class where any traffic beyond the 100000 set target bit rate is dropped.
Step 8	exit Example: `Device(config-pmap-c)# exit`	Returns to policy map configuration mode.
Step 9	exit Example: `Device(config-pmap)# exit`	Returns to global configuration mode.
Step 10	interface `interface-id` Example: `Device(config)# interface gigabitethernet 2/0/1`	Specifies the port to attach to the policy map, and enters interface configuration mode. Valid interfaces include physical ports.
Step 11	service-policy input `policy-map-name` Example: `Device(config-if)# service-policy input flowit`	Specifies the policy-map name, and applies it to an ingress port. Only one policy map per ingress port is supported.
Step 12

Results

Chapter: Configuring QoS

Configuring QoS

Finding Feature Information

Prerequisites for Auto-QoS

Restrictions for Auto-QoS

Auto-QoS Overview

Auto-QoS Compact Overview

Auto-QoS Global Configuration Templates

Auto-QoS Policy and Class Maps

Effects of Auto-QoS on Running Configuration

Effects of Auto-Qos Compact on Running Configuration

Configuring Auto-QoS (CLI)

Procedure

Example:

Example:

Example:

Example:

Example:

Upgrading Auto-QoS (CLI)

Before you begin

Procedure

Example:

Example:

Example:

Example:

Example:

Example:

Example:

What to do next

Enabling Auto-Qos Compact

Procedure

Example:

Example:

What to do next

Monitoring Auto-QoS

Troubleshooting Auto-QoS

Example: auto qos trust cos

Example: auto qos trust dscp

Example: auto qos video cts

Example: auto qos video ip-camera

Example: auto qos video media-player

Example: auto qos voip trust

Example: auto qos voip cisco-phone

Example: auto qos voip cisco-softphone

auto qos classify police

auto qos global compact

Where to Go Next for Auto-QoS

Additional References for Auto-QoS

Related Documents

Error Message Decoder

Standards and RFCs

MIBs

Technical Assistance

Feature History and Information for Auto-QoS

Finding Feature Information

Prerequisites for Quality of Service

QoS Components

QoS Terminology

QoS Overview

Modular QoS Command-Line Interface

Wireless QoS Overview

QoS and IPv6 for Wireless

Wired and Wireless Access Supported Features

Supported QoS Features on Wireless Targets

Port Policies

Port Policy Format

Radio Policies

SSID Policies

Client Policies

Policy Chaining

Hierarchical QoS

Hierarchical Wireless QoS

Wireless Packet Format

Hierarchical AFD

QoS Implementation

Layer 2 Frame Prioritization Bits

Layer 3 Packet Prioritization Bits

End-to-End QoS Solution Using Classification