mls qos trust what?

I'm working through the IPexperts Lab2 for the CCIE Wireless - trying to reverse engineer the solutions to the questions and understand the subjects where I'm lacking.  Namely QoS.


I was digging around trying to find the reason why the solution for section 2.8 bullet point number two was to use the command 'mls qos trust ip-precedence' for all the connections between the core switches. The bullet point asks you to ensure that the layer 3 QoS markings are trusted between the switches, and that you trust the 3 most significant bits of the DiffServ field in the IP packet.


I found this explanation for the difference between 'mls qos trust dscp' and 'mls qos trust ip-precedence'.  DSCP is the most significant 6 bits of 8-bit service-type field, where IP-Precedence refers to the most significant 3 bits of 8-bit service-type field.


This picture shows this breakdown in a little better detail.

New YouTube Videos by Jerome - Wireless QoS

You may already know this, but Jerome has posted three new videos covering wireless QoS.. (thanks to @the_wifi_guy for cluing me in!)

srr-queue bandwidth shape/share

I found a good NetPro discussion regarding whether to shape or share with the srr-queue bandwidth command.  The last post in the discussion links to the 3750 configuration guide - the configuring QoS section where the default settings are shown, and more information about which queue is for what is clearly presented.


Excerpt from the Catalyst 3750 Switch Software Configuration Guide, 12.2(50)SE:

SRR Shaping and Sharing

Both the ingress and egress queues are serviced by SRR, which controls the rate at which packets are sent. On the ingress queues, SRR sends packets to the stack ring. On the egress queues, SRR sends packets to the egress port.

You can configure SRR on egress queues for sharing or for shaping. However, for ingress queues, sharing is the default mode, and it is the only mode supported.

In shaped mode, the egress queues are guaranteed a percentage of the bandwidth, and they are rate-limited to that amount. Shaped traffic does not use more than the allocated bandwidth even if the link is idle. Shaping provides a more even flow of traffic over time and reduces the peaks and valleys of bursty traffic. With shaping, the absolute value of each weight is used to compute the bandwidth available for the queues.

In shared mode, the queues share the bandwidth among them according to the configured weights. The bandwidth is guaranteed at this level but not limited to it. For example, if a queue is empty and no longer requires a share of the link, the remaining queues can expand into the unused bandwidth and share it among them. With sharing, the ratio of the weights controls the frequency of dequeuing; the absolute values are meaningless. Shaping and sharing is configured per interface. Each interface can be uniquely configured.

Shaped or Shared Mode

SRR services each queue-set in shared or shaped mode. You assign shared or shaped weights to the port by using the srr-queue bandwidth share weight1 weight2 weight3 weight4 or the srr-queue bandwidth shape weight1 weight2 weight3 weight4interface configuration commands. For an explanation of the differences between shaping and sharing, see the "SRR Shaping and Sharing" section.

---

Note You cannot assign shaped weights on 10-Gigabit interfaces.

---

The buffer allocation together with the SRR weight ratios control how much data can be buffered and sent before packets are dropped. The weight ratio is the ratio of the frequency in which the SRR scheduler sends packets from each queue.

All four queues participate in the SRR unless the expedite queue is enabled, in which case the first bandwidth weight is ignored and is not used in the ratio calculation. The expedite queue is a priority queue, and it is serviced until empty before the other queues are serviced. You enable the expedite queue by using the priority-queue out interface configuration command.

You can combine the commands described in this section to prioritize traffic by placing packets with particular DSCPs or CoSs into certain queues, by allocating a large queue size or by servicing the queue more frequently, and by adjusting queue thresholds so that packets with lower priorities are dropped. For configuration information, see the "Configuring Egress Queue Characteristics" section.

---

Note The egress queue default settings are suitable for most situations. You should change them only when you have a thorough understanding of the egress queues and if these settings do not meet your QoS solution. 

Wireless Quality of Service Deployment Guide [©2003]

Cisco's "Wireless Quality-of-Service Deployment Guide" ©2003 [I've never seen this doc before!]


I stumbled across this crazy old document from 2003 outlining using QoS on VxWorks APs! I don't think much has changed in the way of WLAN QoS - at least not the fundamentals.  I'm hoping this will help make the QoS grooves in my brain deeper and more permanent.

QoS Policies on Autonomous APs

So after some digging, I think I might have this figured out.

The AP config guide has a section on giving priority to Voice traffic, but it doesn't show the CLI alternative to the GUI configuration section in the guide:
Cisco IOS Software Configuration Guide for Cisco Aironet Access Points, 12.2(13)JA
Giving Priority to Voice Traffic
The 7921 Deployment guide only gives you the CLI commands "best practices" for the 7921, but doesn't say which to which interface(s) the service-policy should be applied:

Cisco Unified Wireless IP Phone 7921G Deployment Guide
Configuring QoS Policies for the Network (page 19)

class-map match-all RTP
 match ip dscp ef
class-map match-all SCCP
 match ip dscp cs3
policy-map Voice
 class RTP
 set cos 6
class SCCP
 set cos 3
interface X
 service-policy input Voice
 service-policy output voice

Putting both config guides together results in this:

class-map match-all RTP
 match ip dscp ef

class-map match-all SCCP

 match ip dscp cs3

policy-map Voice

 class RTP

 set cos 6

class SCCP

 set cos 3
!
interface Dot11Radio1.150 <-this is the radio sub-interface for the Voice SSID/VLAN

 encapsulation dot1Q 150
 service-policy input Voice

 service-policy output Voice
 no ip route-cache
 bridge-group 150
 bridge-group 150 spanning-disabled
!
interface FastEthernet0.150 <-this is the ethernet sub-interface for the Voice SSID/VLAN
 encapsulation dot1Q 150
 service-policy input Voice
 no ip route-cache
 bridge-group 150
 bridge-group 150 spanning-disabled
------------------------

QoS Policy on switch/router with AP needing Voice prioritzation connected:
ip access e SCCP
  p t any eq 2000 any
  p t any any eq 2000
ip access e RTP
  p u ay range 16384 32767 any
  p u any any range 16384 32767
class-map match-all SCCP
  match acc name SCCP
class-map match-all RTP
  match acc name RTP
policy-map voice
  class RTP
   set dscp ef
  class SCCP
   set dscp cs3
int <-interface with IOS AP (no LWAPP traffic)
service-policy input voice
---------------------------------------
dot11 ssid voice
vlan 150
auth op eap eap_methods
auth ne eap_methods
auth ke wpa
admit-traffic <-shown in 7921 guide "Call Admission Control Settings"

QoS Example LAN Switch Configuration (from Enterprise Mobility 4.1 Design Guide)

QoS Example LAN Switch Configuration

AP Switch Configuration

The QoS configuration of the AP switch is relatively trivial because the switch must trust the DSCP of the LWAPP packets that are passed to it from the AP. There is no CoS marking on the LWAPP frames coming from the AP. The following is an example of this configuration. Note that this configuration addresses only the classification, and that queueing commands may be added, depending on local QoS policy.

interface GigabitEthernet1/0/1

switchport access vlan 100

switchport mode access

mls qos trust dscp

spanning-tree portfast

end

In trusting the AP DSCP values, the access switch is simply trusting the policy set for that AP by the WLC. The maximum DSCP value assigned to client traffic is based on the QoS policy applied to the WLANs on that AP.

WLC Switch Configuration

The QoS classification decision at the WLC-connected switch is a bit more complicated than at the AP-connected switch, because the choice can be to either trust the DSCP or the CoS of traffic coming from the WLC. In this decision there are a number of points to consider:

•Traffic leaving the WLC can be either upstream (to the WLC or network) or downstream (the AP and WLAN client). The downstream traffic is LWAPP encapsulated, and the upstream traffic is from AP and WLAN clients, either LWAPP encapsulated or decapsulated WLAN client traffic, leaving the WLC.

•DSCP values of LWAPP packets are controlled by the QoS policies on the WLC; the DSCP values set on the WLAN client traffic encapsulated by the LWAPP tunnel header has not been altered from those set by the WLAN client.

•CoS values of frames leaving the WLC are set by the WLC QoS policies, regardless of whether they are upstream, downstream, encapsulated, or decapsulated.

The following example chooses to trust the CoS of settings of the WLC, because this allows a central location for the management of WLAN QoS, rather than having to manage the WLC configuration and an additional policy at the WLC switch connection. Other customers wishing to have a more precise degree of control may wish to implement QoS classification policies on the WLAN-client VLANs.

interface GigabitEthernet1/0/13

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 11-13,60,61

switchport mode trunk

mls qos trust cos

end

 

Voice over Wireless LAN 4.1 Design Guide - auto-qos notes

Infrastructure QoS Configuration

"This section shows sample QoS configurations for switch interfaces used in the campus network. More configuration details for all the switches and routers used in this design guide is available in theAppendix , "Voice over WLAN Campus Test Architecture," testing section of this guide.

Table 10-2 shows interface commands on a Cisco 3750G access-layer switch used to connect an IP Phone. The Auto-QoS configuration statement is shown in red and the statements generated by Auto-QoS follow it."

From ccie(w)

Table 10-3 shows interface commands on a Cisco 4503 access-layer switch used to connect an AP. The Auto-QoS configuration statement is shown in red and the statements generated by Auto-QoS follow it.

From ccie(w)

Table 10-4 shows interface commands on a Cisco 4503 access-layer switch used as an uplink port to a distribution-layer switch. The Auto-QoS configuration statement is shown in red and the statements generated by Auto QoS follow it.

From ccie(w)

QoS commands from the 7921 deployment guide

QoS Commands for Autonomous Access Points

class-map match-all RTP
 match ip dscp ef
class-map match-all SCCP
 match ip dscp cs3

policy-map Voice
 class RTP
 set cos 6
class SCCP
 set cos 3

interface X
 service-policy input Voice
 service-policy output voice

IOS Router inerface to map RTP and SCCP correctly

ip access-list extended SCCP
 permit tcp any eq 2000 any
 permit tcp any any eq 2000

ip access-list extended RTP
 permit udp any range 16384 32767 any
 permit udp any any range 16384 32767

class-map match-all SCCP
 match access-group name SCCP
class-map match-all RTP
 match access-group name RTP

policy-map Voice
 class RTP
 set dscp ef

 class SCCP
 set dscp cs3

interface X
 service-policy input Voice
 service-policy output Voice

Color coded QoS chart from the Voice over Wireless LAN 4.1 Design Guide

I like the QoS  charts that are in this chapter of the design guide, but the chart runs of the page and isn't color coded like the nice QoS charts from Cisco Live BRKRST-2500 Campus QoS Design.




The LWAPP AP and WLC perform QoS baseline conversion, so that WMM values as shown below are mapped to the appropriate QoS baseline DSCP values, rather than the IEEE values.

From ccie(w)

In cases where the AP is translating CoS values, autonomous APs for example, the translation shown is below:

From ccie(w)

WMM uses the 802.1p classification scheme developed by the IEEE (which is now a part of the 802.1Q-2005 specification).  This classification scheme has eight priorities, which WMM maps to four access categories: AC_BK, AC_BE, AC_VI, and AC_VO. These access categories map to the four queues required by a WMM device.
 

From ccie(w)

... It is generally recommended that the Per-User Bandwidth Contracts settings be left at their default values, and that the IEEE 802.11 WMM features be used to provide differentiated services. For WLANs using a given profile, the IEEE 802.1P classification in that profile controls two important behaviors:

• Determines what class of service (CoS) value is used for packets initiated from the WLC.  The CoS value set in the profile is used to mark the CoS of all LWAPP packets for WLAN using that profile. So a WLAN with a platinum QoS profile, and the IEEE 802.1P mark of 6, will have its LWAPP packets from the ap-manager interface of the controller marked with CoS of 5. The controller adjusts the CoS to be compliant with Cisco QoS baseline recommendations. The reason why it is important to maintain the IEEE CoS marking in the configuration is covered in the next point. If the network is set to trust CoS rather a DSCP at the network connection to the WLC, the CoS value determines the DSCP of the LWAPP packets received by the AP, and eventually the WMM classification and queuing for WLAN traffic, because the WLAN WMM classification of a frame is derived from the DSCP value of the LWAPP packet carrying that frame.

• Determines the maximum CoS value that can be used by clients connected to that WLAN.
  The IEEE 802.1P classification sets the maximum CoS value that is admitted on a WLAN with that profile. WMM voice traffic arrives with a CoS of 6 at the AP, and the AP automatically performs a CoS-to-DSCP mapping for this traffic based on a CoS of 6. If the CoS value in the WLC configuration is set to a value less than 6, this changed value is used by the WLAN QoS profile at the AP to set the maximum CoS marking used and therefore which WMM AC to use. The key point is that with the Unified Wireless Network, you should always think in terms of IEEE 802.11e classifications, and allow the Unified Wireless Network Solution to take responsibility for converting between IEEE classification and the Cisco QoS baseline.

This is the chart from the QoS class at Cisco Live 2009 [QoS on Cisco switches]:

From ccie(w)

There was also a nice colorized chart explaining the packet tagging translation that occurs to and from the client device at the controller.  This image is from BRKAGG-2013 Design and Deployment of Voice over Wireless LAN.

From ccie(w)

Configuring Access Layer QoS for Voice on Cisco Catalyst 6500 with Cisco IOS SW

mls qos
! -- turns QOS on for the whole switch
mls qos map cos-dscp 0 8 16 24 32 46 48 54
! -- maps COS to DSCP using the new standards of CS3 for signaling.
interface fastethernet 5/1
! -- the interface of course
switchport mode access
! -- disable trunking
switchport voice vlan 111
! -- enable trunking when CDP detects a phone. This is called DTP or Dynamic Trunking Protocol.
switchport access vlan 11
! -- set the VLAN for the phones built in switch for the PC on the other side of the phone or for the PC when no phone is detected.
spanning-tree portfast
! -- disable the slow detection of loops with spanning tree. This is a single endpoint and should never have a switch connected to it.
mls qos trust cos
! -- trust the COS of the traffic from the phone
mls qos trust extend cos 0
! -- mark all traffic from the PC to COS 0 no matter what the PC says it should be.

------------------------------

In depth configuration of a "full trust" policy for phones connected to a 6500:

Excerpt below taken from: Configuring Access Layer QoS for Voice on Cisco Catalyst 6500 with Cisco IOS SW

CONFIGURATION OVERVIEW

This sample configuration implements one of several methods to provide QoS at the access layer of an IP Communications deployment. Specifically this configuration is limited to a "full trust" policy on the switch interface. The "full trust" policy assumes a Cisco IP Phone (from Table 3) will be connected to the port to which this policy is applied, as the IP phone is responsible for remarking the PC traffic to CoS = 0. If a PC is instead directly connected to an interface with "full trust" policy, and its traffic is untagged, the switch marks the traffic CoS = 0. However, if the directly connected PC is marking its traffic with a CoS value, the switch accepts it because the port is configured to trust any received CoS. A "conditional trust" policy may be used as an alternative to reduce this possible risk. Though supported on several other Cisco Catalyst switch platforms, Cisco IOS Software for the Cisco Catalyst 6500 does not currently support the mls qos trust device cisco-phone command, which is the simplest method to implement a "conditional-trust" policy. Please see other Cisco documentation for more information regarding "conditional trust" policy configuration.

For the Cisco Catalyst 6500 to act as an access switch for a Cisco 7940/7960/7970 IP phone + PC, using a "full trust" policy, the following is required:

1. Enable switchwide QoS.

2. Configure interfaces used for IP phones:

• Enable trust so the switch accepts the phone class-of-service (CoS) markings.

• Extend the trust boundary to the access port on the IP phone and mark PC traffic as CoS = 0.

• Enable input queue scheduling.

• Configure CoS-to-queue mapping.

• Configure output scheduling.

• Configure CoS-to-differentiated services code point (DSCP) mapping.

• Optionally configure a policy for additional application traffic marking or policing (not covered).

3. Configure the uplink interfaces to the distribution switch:

• Enable trust to accept markings from the distribution switch. This can be either CoS or DSCP trust.

• Enable input queue scheduling.

• Configure CoS-to-queue mapping.

• Configure output scheduling.

• Verify and configure CoS-to-DSCP mapping.

• Optionally configure a policy for additional application traffic marking or policing (not covered).

ENABLING QoS ON THE SWITCH

To enable QoS on the access layer Cisco Catalyst 6500, do the following:

Enable switchwide QoS:

6509-Access(config)#mls qos

CONFIGURING AN INTERFACE FOR IP PHONE + PC

As stated previously, the access port configuration depends on the module in use. All of the 10/100 Ethernet series modules in Tables 1 and 2 have 1Q4T receive and 2Q2T transmit queue architectures. For modules in Table 1 the port is configured to trust the IP phone and not to trust the PC attached to the phone. For modules in Table 2 a workaround is used because these modules are unable to "trust" the CoS of incoming traffic. The workaround consists of using an access-control-list (ACL) policy to retain the CoS of the traffic. An access port also is configured to use output scheduling through multiple transmit queues.

To configure the interface for a module in Table 1,do the following:

Step 1. Select a port to configure.

6509-Access(config)#interface fastethernet 5/1

Step 2. Configure the port as a Layer 2 port in the access mode.

6509-Access(config-if)#switchport

6509-Access(config-if)#switchport mode access

Step 3. Define the voice VLAN.

6509-Access(config-if)#switchport voice vlan 111

Step 4. Define the data VLAN.

6509-Access(config-if)#switchport access vlan 11

Step 5. Configure the port as a host port.

6509-Access(config-if)#spanning-tree portfast

Step 6. Enable inline power.

6509-Access(config-if)#power inline auto

Step 7. Accept the incoming Layer 2 CoS. This lets the switch accept the phone marking of voice traffic at CoS = 5 and voice control traffic at CoS = 3 and enables input scheduling.

6509-Access(config-if)#mls qos trust cos

Step 8. Instruct the IP phone to rewrite the PC traffic to CoS = 0.

6509-Access(config-if)#mls qos trust extend cos 0

Step 9. Place CoS = 1 in queue 1 threshold 1.

6509-Access(config-if)#wrr-queue cos-map 1 1 1

Step 10. Place CoS = 0 in queue 1 threshold 2.

6509-Access(config-if)#wrr-queue cos-map 1 2 0

Step 11. Place CoS = 2, 3, 4, 6, and 7 in queue 2 threshold 1.

6509-Access(config-if)#wrr-queue cos-map 2 1 2 3 4 6 7

Step 12. Place CoS = 5 in queue 2 threshold 2.

6509-Access(config-if)#wrr-queue cos-map 2 2 5

Step 13. Modify the CoS-to-DSCP mapping. The recommended settings are DSCP = CS3 (24) for voice-over-IP (VoIP) control and DSCP = EF (46) for VoIP media traffic. To map the Layer 2 CoS correctly to these DSCP values, you must modify the switch default CoS-to-DSCP mappings. All CoS are shown though only 0, 3, and 5 are directly related to IPT.

6509-Access(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 54

Note: CoS 3 and 5 are the 4th and 6th values, respectively.

To configure an interface on the modules listed in Table 2 do Steps 1 through 13 plus configure the following additional commands:

Step 1. Create an access list to match all traffic.

6509-Access(config)#access-list 100 permit ip any any

Step 2. Create a class for this traffic.

6509-Access(config)#class-map TRUST_COS_CLASS

6509-Access(config-cmap)#match access-group 100

6509-Access(config-cmap)#exit

Step 3. Create a policy to trust the CoS for the traffic in the class.

6509-Access(config)#policy-map TRUST_COS_POLICY

6509-Access(config-pmap)#class TRUST_COS_CLASS

6509-Access(config-pmap-c)#trust cos

6509-Access(config-pmap-c)#exit

Step 4. Apply the policy to the interface.

6509-Access(config)#int fa5/1

6509-Access(config-if)#service-policy input TRUST_COS_POLICY

CONFIGURING THE UPLINK TO THE DISTRIBUTION SWITCH

After you configure the access port queuing, you must also configure the uplink interfaces to the distribution, or core, switch. This involves enabling trust for Ethernet frames coming into the trunk port, enabling output scheduling, and manipulating the CoS-to-queue mapping entrance criteria, mapping the CoS values to the appropriate DSCP value.

This section includes information for two of the six types of queue structures: 1P2Q2T and 2Q2T.

Configuring an Uplink Port

Step 1. Accept incoming DSCP markings if incoming traffic is known to be properly marked at Layer 3. This is the preferred method.

6509-Access(config-if)#mls qos trust dscp

Alternate Step 1. Accept incoming CoS markings if incoming traffic is known to be properly marked at Layer 2 only.

6509-Access(config-if)#mls qos trust cos

Optional Step 2 (required when trusting CoS) Verify CoS-to-DSCP mapping. This should have been set in Step 10 in the interface configuration. Map CoS = 5 to DSCP = EF (46) and CoS = 3 to DSCP = CS3 (24).

6509-Access(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 54

Configuring Transmit Queues

All CoS = 5 traffic (VoIP media) is placed into the egress interface priority queue on 1P2Q2T interfaces and queue 2 threshold 2 on 2Q2T interfaces by default upon enabling switchwide QoS. To follow QoS best practices, additional configuration of the CoS queue admission rules is needed to ensure that all other CoS traffic, and most importantly CoS = 3 (VoIP control), is placed into the correct queue. Separate configurations follow for 1P2Q2T and 2Q2T interfaces. For configuration of different interface queue structures, refer to other Cisco Catalyst 6500 QoS documentation.