Hi guys! here again with questions.
Is there a way to prioritize traffic from one SSID over another SSID? I thought it was possible, we assigned one SSID to the Gold profile and the other one to the Bronze one.. and then we tested:
If a client in the Bronze SSID initiated traffic (using Bricks), clients in the GOLD SSID suffered from timeouts (voice conversation droped, pings timed out, etc).
So as we saw it.. everyone in the WLAN could take all the BW, no matter what SSID it is associated. Do you know what is going on guys?
thanks in advance
Have you tried Infrastructure QoS Configuration (http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/vowlan/41dg/vowlan_ch10.html#wp1046141)?
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.
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.
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:
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.
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.
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.
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.
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.
I just performed a trace of my infrastructure, and my SSID has the Platinum QoS applied. My trace verified that the packets were being marked EF for Expedited Forwarding. This makes sense to me since the Platinum QoS marks the traffic with a DSCP of 6, which is EF.
Oh you mean the tagging? Ours is doing it too, from AP to Controller, LWAPP packet are tagged according to the QoS profile. That part does work. But I dont know how to prove that over the air QoS is working, that one SSID gets more privileges than the other at the time of transmitting to the AP.
I realize this was months ago, but I just came across this while doing some studying:
Q. What is meant by Over the Air QoS on a controller?
A. In a Cisco Unified Wireless Networking environment, users on a wireless LAN can be
categorized and assigned to any of these QoS profiles:
On the GUI, you can access these profiles from the Wireless > QoS Profiles page. For each
of these profiles, Cisco has the configurable Over the Air QoS parameter, which is found
under the edit page of each QoS profile. This Over the Air QoS specifies two different
settings for the particular class of user (QoS profile):
Maximum radio frequency (RF) usage (per access point [AP])This is a maximum
percentage of air bandwidth given to a user class. For example, if you have a network where the guest QoS profile has the maximum bandwidth limitation for bronze set to
10%, even if a single bronze user uses the AP, it can never receive more than 10% of
the total available bandwidth.
Queue DepthThis is the depth of the queue for the particular class. It causes
packets greater than the value to be dropped at the AP.
Note: Only the 1000 Series supports the maximum RF usage setting.
This comes from the following URL:
Did you catch the note that only the 1000 series supports RF bandwidth percentage?
I think that would explain :P. We were using Mesh APs. (1500 series).
Anyway, we never got to replicate the problem (a user in a bronze SSID taking all the bandwidth). It only happened once :S.
PS: Wireless is the darnest thing to troubleshoot ha ha.
Thanks for the info!