04-05-2013 07:02 AM - edited 04-05-2013 08:07 AM
I have packets coming out of the Lync system tagged with a DSCP value of either 46, 26, and 34 on several different ports. For example:
Policy Name DSCP
Lync Conferencing Audio 46 Protocol: TCP and UDP
Lync Conferencing SIP 26
I would appreciate any assistance in how I would go about setting up QoS for this. From the reading I have done I think that I need to setup several Advanced ACL's but I need some guidance on the setup. Here is the link to the ACL setup page that I am working with.
From there I think I need to setup classifiers. From the setup page I would assume that I need one classifier for every ACL rule.
Once the classifiers are setup then I think I need to setup up behaviors. Again this looks like a one to one, behavior to classifier.
From there I think I would create the QoS policies bringing together the classifier and behavior for the policy. This seems like it would be too many, though. The other thought I had was to setup 3 ACL's, 1 for audio, 1 for video, and 1 for SIP since I only have the 3 DSCP values to worry about but I'm having trouble setting up a port range for the ACL. Bottom line is that I'm confused and could use any suggestions.
04-09-2013 06:46 PM
Hello, You'll want to make sure trust the DSCP markings that your Lync system is sending where appropriate, so that the specific ports will honor the markings. Since your traffic is already being marked, you don't really have to specify an access list, but rather "if-match dscp" based on your DSCP values above. From there you can assign those a behavior and tie together with a service policy. Also, you don't necessarily need multiple classifiers for multiple ACLs as traffic classifiers use and/or logic. So, if using AND, you will need to match everything in your classifier, if OR, you can match on anything in your classifier. Depending on your requirement, you would not need multiple QoS service policies either. HTH
04-13-2013 12:59 PM
If you do not expect rogue QOS devices then you can configure the switches to simply honor the incoming values.
This can be done with the qos dscp trust command, sample:
qos trust dscp
Make sure to enable this trust on any other inter switch links as well, so the other switches will also honor the dscp value.
If you install the R1807 release on the 58xx devices, you can verify the correct queuing with
dis qos queue-statistics int g1/0/2
Please note that this applies for the outgoing interface, so it does not make sense to run this on the interface of the lync server.
Hope this helps,
05-27-2014 01:25 PM
Thank you for your response and sorry for the delay in responding. I am picking this up more than a year later because the consultant that came in to set this up never got it to work so we have been running with no QoS to this point (luckily with no problems). I have a couple of questions regarding your advice.
The consultant setup one classifier with 3 rules:
There is also one behavior:
User Defined Behavior Information:
Committed Access Rate:
CIR 8192 (kbps), CBS 512000 (byte), EBS 512 (byte), PIR 12288 (kbps)
Green Action: pass
Red Action: discard
Yellow Action: pass
When this policy was applied it basically caused all network traffic to cease. Considering the DSCP tagging that is happening with the Lync traffic, I'm thinking that this "solution" is overly complicated and that your suggestion of enabling the interface to trust dscp is the better option. I see that I would need to enable this on every interface and then I am assuming that it just uses the interal tables for traffic prioritization. Is that correct?
Also based on what you said, would I then need to enable a similar setting on all of the other switches in my environment (HP2910's) or just on the core switch (HP5820)?
Thank you again for all of your help.