QoS - what if there is no VOIP on the line?

[kunal-united]

I have a 10Mbps internet line.

I want to guarantee 2.5Mbps for VOIP during congestion.

Below is the configuration.

class-map match-any VoIP-signalling

  match ip dscp af31

  match ip dscp cs3

  match ip dscp cs5

class-map match-any VoIP-audio

  match ip dscp ef

policy-map Internet-QoS

  class VoIP-audio

   priority 2000

  class VoIP-signalling

   bandwidth 256

  class class-default <<<<data traffic

  fair-queue

Question - Since the pipe is 10Mbps. If no VOIP runs on this pipe ...Can I utilize the whole 10Mbps according the above configuration.

Please provide reference.

Question - is it sufficient to classify the traffic based on dscp values? or do I still need to match protocol RTP?

[Thotsaphon Lueangwattanaphong · Accepted solution]

Hi,

   What type of interface are you using? Congestion management is activated when the interface gets congested. So you will be fine using the whole bandwitdh up to 10Mbps. You may think of using policing to restict bandwidth. However it depends on your design.

HTH,

Toshi

[nkarpysh · Accepted solution]

Agree with Toshi,

You can check that by the following link explainign the work of priority and bandwidth commands:

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080103eae.shtml

Regarding your question:

"Question - is it sufficient to classify the traffic based on dscp values? or do I still need to match protocol RTP?" It really depends on if your end stations do correct marking on it's own. If you doubt that then matching RTP protocol or mathcing particular ip addresses with ACL would be worth trying.

Nik

[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

kunal-united wrote:
I have a 10Mbps internet line.
I want to guarantee 2.5Mbps for VOIP during congestion.
Below is the configuration.
class-map match-any VoIP-signalling
  match ip dscp af31
  match ip dscp cs3
  match ip dscp cs5
 class-map match-any VoIP-audio
  match ip dscp ef
policy-map Internet-QoS
  class VoIP-audio
   priority 2000
  class VoIP-signalling
   bandwidth 256
  class class-default <<<
  fair-queue
Question - Since the pipe is 10Mbps. If no VOIP runs on this pipe ...Can I utilize the whole 10Mbps according the above configuration.
Please provide reference.
Question - is it sufficient to classify the traffic based on dscp values? or do I still need to match protocol RTP?

Hopefully, the other posts have answered your questions (which, to recap, should be: yes, maybe, maybe), but wanted to expand on a couple of points.

First, you note you want 2.5 Mbps of bandwidth for VoIP (bearer?), but your LLQ is only configured for 2 Mbps.  Additionally, if you expect to push up to 2.5 Mbps, not knowing the exact Tc or Bc the implicit policer uses, it might be advisable to use about 3 Mbps for the priority setting.

You note your pipe is 10 Mbps, but if this is logical rather than physical, you'll probably also want to have a shaper.

You've set aside 256 Kbps, and a separate class, for VoIP signaling.  Be aware that CBWFQ, on most software based routers before HQF, FQ in class-default can distort bandwidth reservations for other non-LLQ classes.  I doubt it will be a problem.  You can also consider, with FQ in class-default, allowing signaling to go there or allow it in the LLQ class.  For the former, FQ usually works well enough signalling will obtain the bandwidth it needs, for the latter, its bandwidth demand is so light it usually doesn't disturb the VoIP bearer traffic.  Either approach simplifies the CBWFQ policy.

Depending on your IOS version, you might find NBAR might match the VoIP traffic too.

[kunal-united]

Thanks  Joseph,

Please provide shaping parameters that I should use for this following configuration.

Thanks

[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

If your interface is running at 10 Mbps, you don't need a shaper.

If your interace is running at a higher bandwidth, e.g. 100 or gig Ethernet, the you'll likely want a shaper.

Something like:

policy-map shape10Mbps

class class-default

shape average 9000000

service-policy Internet-QoS

In the above, you might be wondering why I've shaped for 9 Mbps rather than 10 Mbps.  This because I believe most shapers don't account for L2 overhead but providers often do.  Setting the rate about 10% slower allows for L2 overhead, but it isn't exact as the percentage varies per packet.

In the above I also allowed the shaper to compute it's own Bc, which determines Tc.  The older IOS versions, I recall use to default for 25 ms, and the newer IOS versions, I recall, now use 4 ms.  25 ms can be a little excessive for VoIP, and 4 ms might shape needlessly.  This value, too, might be adjusted.  I've found 10 ms often a good value.  (For 10 ms, I believe all you need to do in multiple the rate by .01 for the Bc setting.)

Lastly, again when working with VoIP, you may need to tune down the interface's tx-ring-limit.  On older IOSs you needed to do this manually, the newer IOSs are supposed to automatically tune down, I believe.

[kunal-united]

The link that I have is a fastethernet 100Mbps ...but bandwidth bought from the provider is 10Mbps. Do I still need a shaper?

Thanks

[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

If you're running your FastEthernet interface at 100 Mbps, yes, you should use a shaper.

If you're running your FastEthernet interface at 10 Mbps, no, you do not need a shaper.

If you're running your FastEthernet interface at 100 Mbps, you could ask your provider if you can run at 10 Mbps, as I've found physical interface congestion appears to work a little better than shaper congestion.  If you're running "auto", this could be a trival change on you part.  If your speed is hard coded, you'll need to coordinate with your provider to change actual link speed.

If you do change the physical port speed, and want to later upgrade to something between 10 Mbps and 100 Mbps, you'll want to shape for that logical rate.  (Changing physical port speed, later, to support a higher bandwidth might again require coordination with your provider.)

PS:

BTW, so far we've only looked at one egress interface, but for workable VoIP, WAN topology and remote side interface can be important too, as also can be this interface's ingress bandwidth.