Wireless QoS - DSCP to 802.11e translation

PETER MOOREY · ‎01-08-2013

Hi,

Would appreciate some advice, I am using a 5508 controller, I have an SSID that has WMM enabled and platinum QoS profile applied, with default settings. I have 802.11p set to none as we are not doing layer 2 QoS on the switches.

I found that when pinging a wireless client with DSCP set to EF the packets (all packets in fact) are being sent from the AP to the client with 802.11e set to zero. I verified this via AirPCAP.

Can someone confirm why the AP is not taking the DSCP marking from the outer LWAPP IP header and translating it to an 802.11e value?

My best guess is that I need to enable 802.11p on the QoS profile in order for the AP to start translating DSCP to 802.11e. The thing is that I don't particularly want to mark 802.11p as we will not be enabling QoS on the switches, and my understanding is that it's not really required in order for DSCP to be translated from the outer LWAPP IP header to the 802.11e field.

I've reviewed the Cisco documentation on wireless QoS, including the diagram showing the packet flow and copying of QoS markings at each step....

Thanks in advance,

Pete

Rasika Nayanajith · ‎01-11-2013

Hi Pete

What do you mean by "we are not doing layer 2 QoS on switches" ? Have you enable QoS on your switches where wired client, WLC & AP connected ?. If not that may be the reason for this behaviour.

Traffic flow would be, Wired client -> WLC -> AP -> Wireless client, where WLC->AP is the part where CAPWAP comes into play. Before go into that, You need to verify when the traffic enter WLC it has correct DSCP (EF in this case), what is the trust status of your wired client connected switch port ? If no QoS trust (cos or dscp) then switch will re-write DSCP to 0 when that wired client traffic go out of any switch port. So WLC will get DSCP 0 packet.

If you have correct QoS trust in wired client connected switchport, then you should get DSCP EF packet into WLC. then next step is to verify outer CAPWAP DSCP when WLC send traffic to AP & ensure it is DSCP EF. Wireshark capture would do this at WLC connected switch port.

Next to look at WLC to AP path, when traffic enters switch from WLC connected switch port, by default (if there is no QoS trust) it will untrust DSCP of the CAPWAP header & rewrite into DSCP value 0 prior to send it out AP connected switch port. So when the packet received by AP it has DSCP 0 in outer CAPWAP & convert it into UP 0 in wireless frame to client. If you capture wireshark at AP connected switch port you can verify this.If you see DSCP EF goes to AP that ensure up to that point is ok.

If your AP get DSCP EF in outer CAPWAP & wireless frame still having UP zero, that means your WLAN is not correctly configure for DSCP to 802.11e mapping."802.1p" setting under QoS profile in WLC is control this. You said you set it to "none" & that is the reason why you will see 802.11e frame not get marked with correct UP. Since you configure platinum profile this should be 802.1p value 6. That should fix your issue.

Have a look at below my blog post & related posts that explain wireless QoS in detail.

http://mrncciew.com/2012/11/30/understanding-wireless-qos-part-2/

HTH

Rasika

PETER MOOREY · ‎01-17-2013

Hi,

On the switches, they are configured with no MLS qos. We don't do any marking/queuing etc. When MLS QoS is disabled there should be no requirement to trust ports, etc. I know that the switch is not re-writing the DSCP markings as I have verified at the point below:

I have verified that the original IP DSCP marking (EF in my test) is maintained from the wired client to the wireless client. I verfied this by doing a capture on the wireless client and checking the IP DSCP marking of the received wireless packet.

Regarding the capture of the WLC switch port to check the outer CAPWAP DSCP marking, unfortunately I have not been able to do this yet...

I suspect that the problem is that the WLC is not copying the inner DSCP to the outer CAPWAP DSCP, and when the packet is received by the AP the UP value is set zero.

I will turn on 802.11p to see if this causes the WLC to start copying the inner DSCP to the outer CAPWAP DSCP.

On a slightly different note, we have a SSID that is used for multiple purposes, including email, internet, and voice client on mobile devices. The SSID has QoS profile silver applied, when silver profile is applied, does it mean that any packets marked EF will be translated to best effort 3? My understanding is that prioritisation of all packets is capped at the the maxiumum for each profile, i.e. bronze is capped to background, silver capped to best effort, etc. etc.

Thanks for your help!

Pete.

Rasika Nayanajith · ‎01-18-2013

Hi Pete,

If you are not enable QoS & disable re-write of DSCP on your switches, pretty much you will get the incoming packet DSCP when it leaves any switchport. Therefore WLC should get DSCP EF packets & outer CAPWAP should have DSCP EF. I have done a quick test to simulate your issue. WLAN configured for platinum QoS profile with 802.1p set to none. Wired PC - RTP traffic mark to EF in my case (as windows 7 does not correctly classify traffic).

1. Wired PC (IPCommunicator) ->Switch with no QoS -> AP -> Wireless client (7921 phone)

2. Wired PC (IPCommunicator) ->Switch with no QoS -> AP -> Wireless client (Laptop with IPC)

When I capture traffic for Cisco wireless phone I can see wireless frame is having UP value of "6-Voice". But when I do the testing for wirless laptop client I observed wireless frame are having UP of "0 - Best Effort" (as you observed as well). I would expected in both cases wireless frame UP to be zero. Not sure why behaviour differnt for Cisco 7921 phone.

Then I enabled QoS on the switch & trust DSCP on AP & wired PC connected port & CoS on WLC connected switch port. But left QoS profile 802.1p tag as " None". This time in both scenarios I have observed WMM_UP value "0-Best Effort" in wireless frames even though the AP received outer CAPWAP as EF. This is normal behaviour as QoS profile set to 802.1p to none & therefore outer CAPWAP will not translate to UP=6 as it is. It will cap to max of 802.1p configured (presumed none mean 0)

Finally when I set 802.1p tag to 6 on QoS profile & conduct the same test. I expected in both scenarios UP=6 for EF marked traffic to wireless client (cisco phone or wireless laptop). As expected Cisco phone received wireless frame had UP=6 Voice, but wireless laptop received frame had UP=0 best effort.

I am geussing this due to some kind of WMM incompatibility of different devices (not sure though). I will try to do this with some other clients ( jabber in iPhone & Galaxy SIII) & see any common behaviour.

As per the VoWLAN 4.1 design guide (page 2-18,19) 802.1p classification in QoS profile controll two behaviours

1. Determine what class of service (CoS) value is used for packets initiated from the WLC.

2. Determine the maximum CoS value that can be used by clients connected to that WLAN.

Regarding the QoS profile & traffic mapping, If you set your QoS profile to "Silver with 802.1p Tag of 3" & your wilreless clients' EF marked traffic (ie WMM_UP of 6) will translate into outer CAPWAP DSCP value of AF21 by AP. Same applicable to any video traffic from wireless clients (as it comes with WMM_UP of 4 or 5). But original packet's inner DSCP value remain as it is because of CAPWAP encapsulation from AP -> WLC. Due to this within wired network (at least from AP to WLC) you cannot differentiate Voice , Video packets as all having same DSCP value (AF21). Anyway in your case this won't matter as you do not do any prioratization of your traffic within your switch network.

Just for curiosity why do not you use qos on your switches ? is there any reason ? How do you prioratize your voice traffic over any other type of traffic in your network ?

I am running WLC 4402 with code 7.0.116. What is the software version you are running on your WLC ?

When it comes to software version 7.4 code, cisco introduced "Application Visibilty & Control" feature where you can classify traffic at the WLC as you normally do in wired switches. This will allow reclassify, markdown, drop traffic according to traffic categories.

HTH

Rasika

PETER MOOREY · ‎01-19-2013

Thanks for the detailed reply. Yesterday I confirmed that the wlc is copying the inner DSCP to the outer, by examining packets as they arrive at the AP switch port. I saw some bugs on the Cisco website regarding translation to UP values not working, the tests I was doing used icmp marked as EF. I also tested using TCP traffic marked as EF with the same result. I've opened a TAC case.

Sent from Cisco Technical Support iPhone App

PETER MOOREY · ‎01-19-2013

With regards to LAN QoS we don't really run into issues with LAN congestion, I believe the complexity of the configuration and additional troubleshooting overhead make it hard to justify in our network. We monitor network performance very closely and use qos on the wan to a very high level...

Sent from Cisco Technical Support iPhone App

PETER MOOREY · ‎01-19-2013

The WLC is running the same version as yours, or possibly 7.0.98. The application that we are concerned about is a non cisco mobile voice application for android/iPhone. I've checked it's prioritising correctly from client to wireless LAN. Sorry for the fragmented replies.

Sent from Cisco Technical Support iPhone App

Rasika Nayanajith · ‎01-19-2013

Hi Pete,

Yes, most probably it may be due to a bug as we could not see anticipated behaviour consistently. Let us know what is the outcome of the TAC case you logged for this.

I have checked my packet captures done for testing BYOD with QoS "http://mrncciew.com/2013/01/08/byod-with-qos/" on WLC 7.4 code. I can confirm in all test cases done with Cisco Jabber clients, EF traffic from wired phone get converted to UP=6 when it receive by wireless client (phones, tablets,laptops).This is under Platinum QoS profile with 802.1p tag set to 6.

Regards

Rasika