Showing results for 
Search instead for 
Did you mean: 
Piotr Pawlowski

QoS for Skype

Dear Experts,


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

  Service-policy output: skype-policy-map

    queue stats for all priority classes:
      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.



Aaron Ratcliffe

Hi As Skype is an internet based service we can't control further then your egress router interface . You are on the right path above just monitor drops and hits and tweak accordingly
Joseph W. Doherty
Hall of Fame Expert


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.

Liability Disclaimer

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.  wink)


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:


policy-map Sample

class class-default



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.


policy-map ParentSample

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:


policy-map Sample

class skype

bandwidth percent 99


class class-default

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?