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 policy-map skype-policy-map class skype priority percent 80 # WAN interface int g0/2 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?
Additionally , here is verification output :
Gdansk#sh policy-map interface g0/2 GigabitEthernet0/2 Service-policy output: skype-policy-map queue stats for all priority classes: Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 2024/230537 Class-map: skype (match-all) 81993214 packets, 32171033459 bytes 5 minute offered rate 42000 bps, drop rate 0000 bps Match: protocol skype Priority: 80% (80000 kbps), burst bytes 2000000, b/w exceed drops: 0 Class-map: class-default (match-any) 1252417839 packets, 306966688702 bytes 5 minute offered rate 2504000 bps, drop rate 0000 bps Match: any queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 43065/6538271
Is above configuration a good approach?
Thank you in advance for any help.
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?