QoS setting for Voice

[Bab L]

HI.

We would like to configure QoS on our router for voice traffic. The link is 10MB and the voice tech asked for 60% traffic for voice. 

Can you please someone advise if the below config is correct:

class-map match-any Voice
 match protocol sip

policy-map QoS
 class Voice
  priority percent 60
 class class-default
  fair-queue
policy-map 10M_Shaping
 class class-default
  shape average percent 40
  service-policy QoS

interface GigabitEthernet0/0/0
 description Connection to ********
 ip address ****.*****
 media-type sfp
 service-policy output 10M_Shaping

Thank you

[Mark Malone · Accepted solution]

Hey this should work for you it will match any traffic with a DSCP 46 EF for voice , all Cisco phones will mark there packets with this and most others as well as its the standard, its limited to 6mb and the other 4mb goes to everything else , use bandwidth instead of priority as it allows classes to exceed settings when there's not full congestion, priority restricts it flat to the amount set

ip access-list extended VOICE_ACL
 permit ip any any dscp ef

policy-map VOICE10Mb
 class VOICE_CLASS
    bandwidth 6000
 class class-default
    fair-queue

class-map match-any VOICE_CLASS
 match access-group name VOICE_ACL

interface GigabitEthernet0/0/0
 service-policy output VOICE10Mb

[Joseph W. Doherty]

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

". . . use bandwidth instead of priority as it allows classes to exceed settings when there's not full congestion, priority restricts it flat to the amount set"

BTW, on many (most?) platforms, LLQ's implicit policer only triggers when there is congestion  (NB: Peter Paluch confirmed this with some lab testing - there's a thread that documents what he found.)

Even if it worked as you posit, with VoIP, LLQ helps minimize queuing latency (especially important for minimizing jitter) vs. using a "routine" bandwidth class.

Lastly, pre-HQF CBWFQ, FQ in class-default (somewhat) negates "ordinary" bandwidth guarantees in other classes.  LLQ, though, still gets its priority.

I would recommend against using a non-LLQ class for VoIP bearer traffic, although it's often a suitable choice for VoIP signalling traffic.

[Mark Malone]

That's good to know thanks

[Bab L]

Thanks Joseph/Mark for your feedback. I'll leave it as is. Does this need to be applied on both interfaces?

The reason I'm asking, is because this router is sitting in the middle between two outside connections in the network. So we have: Vendor-> QoS Router-> 3850 BGP enabled switch. The switch is connected to DC servers, to cloud services and to internal company WAN.

Outside interface of router is connected to external vendor router and inside interface connected to the 3850 BGP switch.

Thank again

[Joseph W. Doherty]

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

The "book" answer would be, you should have QoS on every interface. But where you really want QoS is on interfaces subject to congestion.  Assuming your ingress is also 10 Mbps, and also assuming your internal link from your router to 3850 is 10 Mbps or better, that link cannot congest (well except your WAN is being shaped, so ingress is actually gig,  so unless link to 3850 is also gig, you can congest, but it shouldn't be an issue).

[Bab L]

That makes sense. Thanks Joseph.

One last question, do I need to shape the interfaces to 10MB or whatever the link speed is  or that would be done from the vendors router? 

The reason I'm asking, because currently with the 60-40 percent we have configured for QoS thats on an interface which is 1GB.

Thank you

[Joseph W. Doherty]

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

You should shape when you know there's a downstream bottleneck that you cannot apply QoS at that point.

[Joseph W. Doherty · Accepted solution]

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

Yea, that's basically what you want.

Ideally, it would be better if you could run the interface at 10 Mbps, to preclude needing a shaper, but I appears it's gig fiber.

Cisco recommends LLQ not exceed 1/3 of available bandwidth.  This to insure you have sufficient bandwidth for other purposes, but once you go pass about 50%, your also start to risk not having enough bandwidth for VoIP to avoid self-queuing.  This is more of an issue if you use compressed codecs, whose bandwidth demand can vary.

You'll need to confirm NBAR's SIP matches your VoIP traffic.  Mark is correct, often VoIP (bearer) traffic is marked with DSCP EF.  You can match against both, if you want.

e.g.

class-map match-any Voice

 match dscp ef
 match protocol sip

Also be aware, with VoIP, you generally want to "protect" it's signalling traffic, but don't need LLQ for that.

When a shaper is working with VoIP, you often need to insure the shaper is using a small Tc.  (Newer IOS versions' Tc is good, older versions might not be.)