cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4390
Views
5
Helpful
12
Replies
Highlighted
Beginner

QoS - LYNC

Hi

In a deployment with QoS configured on switches, we are going to do QoS on wireless as well (for LYNC optimization)

Right now we use flexConnect on ver. 7.4.. Looking on the new AVC feature, it already have a profile for LYNC (when doing central switching).

Can someone clarify the following:

- If going to use Central switching instead of flexConnect, to implement a AVC LYNC-profile, then we will have to config QoS on switches to prioritize CAPWAP ?

- Would it be better to keep flex connect and do some "old" QoS on WLC (Does QoS on WLC always require central switching) ?

- Anyone have done QoS for LYNC on WLC ?

Regards

Kasper

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Enthusiast

Hi

QoS in Lync is a tricky one. Normally you would have a Generic QoS profile on the Lync Server. However, to better optimize QoS for the client, you would have to configure Policy based QoS on the laptops. This can be done through the local computer group policy. Normally, the DSCP value for voice is 46, while that for video is 34.

The big question is how you can do this on all laptops in your domain. If you can find a way to push it through the domain group policy, then that would ease your pain. I would also recommend that you configure your AP switch port to trust dscp.

A noteworthy point is that QoS becomes ineffective in a poor wireless environment. Hence you would have to make sure that your wireless LAN set up was properly done. Prioritizing CAPWAP will no major effect for LYNC.

View solution in original post

12 REPLIES 12
Highlighted
Enthusiast

Hi

QoS in Lync is a tricky one. Normally you would have a Generic QoS profile on the Lync Server. However, to better optimize QoS for the client, you would have to configure Policy based QoS on the laptops. This can be done through the local computer group policy. Normally, the DSCP value for voice is 46, while that for video is 34.

The big question is how you can do this on all laptops in your domain. If you can find a way to push it through the domain group policy, then that would ease your pain. I would also recommend that you configure your AP switch port to trust dscp.

A noteworthy point is that QoS becomes ineffective in a poor wireless environment. Hence you would have to make sure that your wireless LAN set up was properly done. Prioritizing CAPWAP will no major effect for LYNC.

View solution in original post

Highlighted

Osita (VIP Endorse +5) Great response

One thing to always rememeber traffic headed upstream leaving the client destined for the access point must be marked by the client.

__________________________________________________________________________________________
"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
__________________________________________________________________________________________
‎"I'm in a serious relationship with my Wi-Fi. You could say we have a connection."

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________
Highlighted

Thanks a lot George.

Highlighted

yes, not all wireless client drivers are smart enough to mark its uplink voice packets, so it'll be best effort from AP to WLC direction. On WLC using avc profile can mark lync's uplink traffic WLC to wired infrastructure and downlink WLC to AP lync traffic.

Highlighted

It seems that this is "unfortunately" the fact. If the client does not support 802.11e / WMM, or you do not want to trust the QoS values set by the client, there is no way to classify / mark the paket, or to be more precise - the DSCP field of the CAPWAP header, from AP to Controller.

I have no solution either for this, except going to flexconnect or converged access with the new Cat3850

Highlighted

Now a days almost all client drivers support WMM. In my campus enviroment we have configured WMM-Required (not allowing non-wmm client to join) & not many complaints from users.

I agree that we cannot classify/marking wireless traffic that we like to do this as wired. But still WMM-UP value map to outer CAPWAP DSCP (capped to a QoS profile 802.1p value configured) & you have some sort of control how to classify it at the AP. Refer below post as it describe this in more detail

https://supportforums.cisco.com/thread/2235429?tstart=0

Converged Access makes it more simpler & I am also pro towards that.

HTH

Rasika

Highlighted

You are right but this requires you to trust the markings on the client, which is in many cases not what you want :-)

Do you know an "easy and fast" way how to find out if a client supports 802.11e / WMM?

Thanks

Roger

Highlighted

Yes, in this model we will trust WMM-UP value set by client driver.

Other than looking at client driver technical spec I do not know any other easy way to see whether it support WMM or not

HTH

Rasika

Highlighted

O.k., I see...means a lot of spec-research if you have a huge enterprise with a looot of different clients.

Another way, even tough not so much faster, seems to be making a client debug and check on code 35:

http://www.my80211.com/cisco-wlc-cli-commands/2013/5/20/cisco-client-debug-80211-association-status-code.html

and here the client debug manual on WLC

http://www.cisco.com/en/US/products/hw/wireless/ps430/products_tech_note09186a008091b08b.shtml

regards

Roger

Highlighted

There is another way if you have wireless sniffers. If you see wireless frames comes with QoS control information that mean it support WMM

http://mrncciew.com/2013/07/30/wmm-qos-profile/

HTH

Rasika

Highlighted

Thanks, good article. That page is anyway an amazing ressource, I knew it before...has some really good topics!

Highlighted

Roger,

Thanks, I did all of these on my way to CCIE wireless lab.. eventhough I have completed my journey, still keep that blog updating with what I am doing in wireless

Rasika

Content for Community-Ad