First of all I must say that I am noob in QoS so excuse for stupid questions.
I have a 2911 router behaving as a edge one for my LAN. For some time users in LAN are facing issues with communication via Skype - both voice and video, including call terminations.
I wanted to implement QoS for Skype, However, I have a feeling, that it is not working as it should. Below is what I have:
class-map match-all skype
match protocol skype
priority percent 80
# WAN interface
service-policy output skype-policy-map
There is no other configuration regarding QoS. As far as I understood there will be up to 80% of bandwidth used by Skype if there will be such need. Other 20% will be used by other protocols. Is that correct?
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Is what you've posted a good approach? Probably not. (There, your question has been [also probably] correctly answered. Please mark my response so. )
Oh, you're looking for "any help" too? Can I get bonus points? (I hope you don't my joking responses, so seriously . . .)
Something that might be an issue, I see you're using a gigE interface for your WAN hand-off. QoS only "triggers" when there's congestion. If your WAN has a logical bandwidth cap you'll want to shape for that value. This allows your QoS policy to "trigger" when there would be congestion against that bandwidth limit.
When using a shaper, most I believe, don't account for L2 overhead, but provider bandwidth caps usually do. So, whatever the bandwidth cap is, to more accurately shape for it, you'll want to set the shaper about 15% lower. This is especially needed for time sensitive traffic.
Whether a shaper or interface causes congestion, you then define a policy how to manage that congestion. Real-time traffic, often does use LLQ, as you're doing with your Skype traffic, but Cisco recommends LLQ never use more than about 1/3 of your bandwidth. Cisco recommends this, so that the prioritized traffic isn't real adverse to non-LLQ traffic, but if you really need more than 1/3 of bandwidth for LLQ, you probably don't have enough overall bandwidth.
By default, faster interfaces use FIFO queuing, which allows bandwidth hogs to be adverse to light bandwidth using flows. Often using fair-queuing for every flow is sufficient, but if some traffic needs even higher preference, you can break it out.
So, if your interface is the actual bandwidth limit, something as simple as:
Might be sufficient.
If you need a shaper, you have a parent policy and child (the parent is what is applied to interface), e.g.
shape average <bandwidth limit - 15%>
service-policy Sample !from above
If you find you do need to break out Skype, you can try something like:
bandwidth percent 99
bandwidth percent 1
You can experiment with the bandwidth percentages, but the above will give skype LLQ like priority, not limit it with an implicit policer, FQ any congestion between Skype flows.
I was interested to know if we can match on Skype and then differentiate between voice and video within NBAR? I was reading that NBAR can see voice and video in an RTP stream; is anybody doing this right now that has an example?
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...