Hi,

thats right, the QoS-configuration should expand to the underlying infrastructure, too.

But just attaching the SSIDs to the corresponding Profile on the Controller isn't enough on the WLAN-side.

Here is the QoS-Chapter of the Cisco VoWLAN Design Guide. We sticked to this guide and our 7921s are just working fine.

https://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/vowlan/41dg/vowlan_ch2.html

Greets,

Sebastian

Hi guys... we haven't configured QoS on the wired side of the LAN. But then again.. shouldn't the Controller and the AP limit the client RF utilization according to which profile is configured in the SSID? If not, then I don't see the point of having QoS on the wired side if one client in the Bronze SSID can load the AP and affect the Gold SSID.

I've got my 7921G connected using Platinum QoS set while everyone else is using Silver (default) QoS on the WLC.

By default, all AP's can service up to 12 clients per AP. So this won't overwhelm the bandwidth.

Im telling you because that's what happened, one client in one SSID used all the available RF/bandwitdh and interrupted communications in the other SSIDs.

Hi Omarmontes,

Something doesn't sound or smell right. How are you determining you have a client bandwidth issue.

I have deployed my share of WLANs and most are all VoIP grade including Vocera, Cisco and Ascom. I have done some load testing with no QoS with 20 phones on a single AP and had no issues.

Normally, the jitter, cracking and popping is sometimes related to QoS on the wired not being properly implemented.

Now, thats not to say you arent having issues wireless wise. But can you take a moment and share how you came to that conclusion.

Its not my final conclusion :P. But why i think its a RF problem? Because, as i said in the first post, we are using two SSIDs, one Gold and one Silver. To test, we get 2 clients in the Silver SSID and one in the Gold SSID. If we send traffic between the 2 clients in the Silver SSID, the client in the Gold SSID cannot communicate with the rest of the network (the Gold client was making a call... and when the traffic started, it droped), it cannot even ping its gateway.

I know we are supposed to configure QoS in the LAN, BUT.. the issue here i think, is to fully understand what a WLC can do about QoS. I thought it could give priority to one SSID over other SSID in the Air (and in this segment, Client-AP, it doest matter what we configure in our switchs, right? its all about the SSID, their profiles, the AP and the Client) but it doesnt seems to work.

In the other hand, using sniffers and monitoring the WLC port, we can see that traffic between AP and WLC is indeed tagged with DSCP values according to the SSID profile. BUT, as this traffic comes out of the WLC to the LAN, its lose the TAG. As I see it.. the WLC is remmoving the things it added and leaves the original packet intact. (the sending client didn't original tagged the packet). But is this assumption correct? or something is wrong and it should leave the tag?

In other news :P : we are also having issues sniffing the traffic. When using a WLC 2006, I can see the traffic getting out and in from the controller. But when using a 2106, running 5.2 Software, I can only see traffic getting inside the Controller. We are using Wireshark and SPAN session in the switch. Same configurtation for both scenarios, and for some weird reason, i can't sniff the 2106 traffic.

I know we are supposed to configure QoS in the LAN...

You've already indicated that you know this to be required. The Cisco Controller architecture is not self-sustaining without a wired infrastructure. While the controller will utilize your configuration for SSID QoS profiles, without configuring a CoS map at L2 on the switch, your QoS is not 'end-to-end'. As I understand it, your DSCP markings put in place by the SSID QoS profile are removed in the de-encapsulation process at the controller. The links to the switch from the controller are layer 2 trunks. Without a CoS map, how do you expect to carry that DSCP prioritization to your queues to properly move your traffic?

That's the thing, with the current topology and configurations I know the QoS won't be end to end. What I am trying to test is the client-AP part, because from documentation y cant get a clearly explanation about how the QoS is handled in the AIR. Does an SSID gets more "sending time" than the others? and if it does.. what else do i need to configure because right now is not working for us. And, because we are only testing the Client-AP over the air traffic, what difference makes that we do or dont configure QoS on the LAN. I'm well aware that returning traffic wont be prioritized either, at least not from the LAN side, but it comes to the same thing i've been saying from post 1: how come 1 client in a Bronze SSID eats all the bandwidht/RF/permission to send, etc, over the other SSID with more privileges?

Check here for Over-the-AIR QoS:

Wireless->QoS->Profiles->Platinum

You will have a section called "Over the Air QoS" you can manipulate. By default, all of the profiles are set to 'Use 100% of available RF Bandwidth'. Its the queue depth that is specific to the profile. You can also manipulate 'Voice' parameters globally for CAC under the 802.11b/g/n section of the 'Wireless' tab.

Regards,

Scott

Thanks Scott, we tried with that, I mean, manipulation the RF % of bandwidth. But got the same results :(

We even used 10% vs 90% so a difference would be more noticeable.. but the testing gave the same results.

Omar -

The following text is verbatim from the guide entitled 'QoS on Wireless LAN Controllers and Lightweigh APs Configuration Example':

"Once again, QoS on the WLC ensures that packets receive the proper QoS handling from end to end. The controller does not perform its own QoS behavior. The support is there for the controller to follow suit if QoS already exists and priority needs to be applied to wireless packets. You cannot have QoS only exist on the controller."

This tells me that the tests you are performing are irrelevant. If you have not properly configured your LAN infrastructure to respond to the tags being placed on your packets, then making changes to only the settings on the controller are not being acted upon by your transport architecture.

Regards,

Scott

I understand, but I don't know why is the test irrelevant. If the traffic is comming from a Wireless laptop to the AP, what difference does it make if I'm making QoS in the LAN if my Gold Client can't even get its traffic to the LAN, because some Bronze Client is getting all the air.

Omar -

You've got a point there. It is obvious there is still some part of the equation neither one of us understands. Perhaps some packet tracing in the early part of enabling the WLAN will tell you if all clients have equal chance of using the airspace, and then by some combination of the configuration the Bronze client is able to consume the airspace. Packet tracing will allow you to see if the WLAN QoS policies are even being applied appropriately to each of your clients on their respective SSIDs.

Regards,

Scott