Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

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

 

Piotr

Everyone's tags (1)
3 REPLIES
New Member

Hi

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
Super Bronze

DisclaimerThe Author of this

Disclaimer

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.

Posting

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

fair-queue

 

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

fair-queue

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.

New Member

Re: DisclaimerThe Author of this

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?

 

Thanks,

 

Alex

3046
Views
5
Helpful
3
Replies
CreatePlease to create content