Wireless Access

In our QoS testing, we discovered that both the client and AP are using an incorrect WMM AC to transmit voice packets. 

 

We use Jabber, and we adhere to the recommended Cisco values for DSCP:

Voice: 46 (0x2E, EF)

Video: 34 (0x22, AF41)

 

So, on our SSID profile, we set the DSCP mapping for WMM Voice as 46 and Video as 34.

 

However, a decrypted wireless packet capture on our PSK SSID revealed that both the client and AP are marking the 802.11 layer 2 header as priority 5 (Video) when we expected it to set it as 6 or 7 (Voice). In the IP header we see that the DSCP value was indeed 46.

 

My colleague found this page from the user guide ( http://goo.gl/wpOcPF ), which talks about using an ACL to set the dot1p priority so that the AP will use the Voice AC, so that would work fine from the AP to the client. But what about client transmission settings? Does anyone out there know how to influence clients such as Windows and Mac to mark the layer 2 header according to Cisco's preferred DSCP values? Our Jabber guy seems to indicate that that is not configurable on his end. It sounds to me like it's an OS or driver thing.

 

We use AD group policy and JAMF, if that helps.

In our deployment, our windows team had to create GPO to apply QoS for Jabber, otherwise Windows was not tagging properly.

 

 

 

UPDATE: The solution below did not actually work; I must have been looking at the wrong packet or something. I tried the same method today on the same computer today and there was no way to get the layer 2 marking to go to 6 or 7. Instead, I found that if I bumped the Jabber Audio Policy (a subfolder under QoS in the Group Policy editor path below) to 48, then Windows would assign the value of 6 and get queued as Voice, but this causes other problems that need to be dealt with as I explain in my post below this one. Currently I am trying to find a way to change the way Windows maps DSCP to Layer 2.

 

Original Post:

===============

 

Our Jabber is tagging Layer 3 (DSCP) just fine (this was already set up). What was not working was Layer 2 tagging to set the correct WMM Access Category (AC).

 

After several hours of research, trial and error, testing, and verification, I think I found a Windows fix.

 

1. Open gpedit.msc
2. Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > Network > QoS Packet Scheduler > Layer-2 priority value
3. Open Guaranteed Service Type
4. Click Enabled
5. Set the Priority value to 6.

 

Now that I've figured it out for my test machine I need to work with the endpoint team to get that change pushed to our Windows boxes via GPO. Just be aware that this changes the ToS value for the Ethernet adapter as well (but who uses that anymore?).

 

My Mac packet captures showed that the correct WMM ACs for voice (6), video (5), and signaling (4), but YMMV. UPDATE: Further testing revealed different results on different Macs; one used 6 (on Jabber version 11.8.0) and one used 5 (on 11.7.1) for a voice call.

 

Here are the links the helped me get to the right place; neither of them told me exactly what to do but I sorta just put it together on my own:

• http://www.revolutionwifi.net/revolutionwifi/2011/09/microsoft-lync-qos.html
• https://technet.microsoft.com/en-us/library/bb964018(v=office.12).aspx
• https://technet.microsoft.com/en-us/library/cc728211(v=ws.10).aspx#w2k3tr_qos_how_bdgn

We have a Validated Reference Design guide for Microsoft Lync that details what needs to be done to configure QOS correctly both on the controller and Windows clients here:. http://community.arubanetworks.com/t5/Validated-Reference-Design/Lync-Over-Aruba-Wi-Fi-Validated-Reference-Design/ta-p/255993

It does not speak about Jabber specifically, but every issue you have raised from controller to client side is detailed there.

So I see in the VRD that there is a workaround by setting the DSCP value of the application to 56. That solves the problem on the wireless side as the WMM to DSCP mapping changes the value heading upstream.

 

I changed the value of the Jabber voice call to 48, and presto, they are now being queued as WMM AC VO with a QoS Control value of 6 in the packet capture.

 

However, doing this would give birth to a new problem. Since the OS will now tag the packets with DSCP 48/CS6 (or another arbitrarily high value such as 56 as suggested in the VRD), any call placed while connected to the WIRED network now gets tagged as CS6 and is not queued correctly while traversing the network. CS6 is used in our network for certain control traffic due to the default Cisco AutoQoS policy that is in place. Changing this network-wide would be a near-impossible undertaking and certainly would not make it past our Change Authorization Board anyway.

 

I also had a bit of a lightbulb moment. Referencing https://www.tucny.com/Home/dscp-tos , I see that DSCP 48 results in a TOS value of 6. When I look at my packet capture, I see I am getting a value of 6 in the QoS Control field as I've already mentioned. Perhaps Windows is simply taking the TOS value from the IP header and mapping that directly to the QoS Control field, and queueing it accordingly. Am I crazy, or am I onto something here?