QoS - guarantee for sip trafffic to internet

[jacob6000]

Hello,

I'm still trying to figure out this QoS thing. We have T-1 going between both sites  providing ipsec vpn (small offices) and voip traffic going outbound to the Internet to our provider.   I need to make sure that half of the bandwidth is always available for the few phones (voip connections) that need them. If they don't need the bandwidth at the time then I'm fine with the extra bandwidth going to the vpn, etc.

If someone could provide a sample config and some guidance that would be great.

Thank you,              

[paul driver]

Hello

Below is an LLQ example that uses a percentage of the BW for your voice traffic via defining an acl for  the voip ports or by a ip range.

access-list 100 permit udp any any range 16384 32000 ( udp ports of voice)
access-list 100 permit tcp any any eq 1720 (h.323 signaling)

or

access-list 100 permit ip 100 x.x.x.x y.y.y.y  x.x.x.x y.y.y.y

class-map match-all VOIPcm

match access-group 100

policy-map VOIPpm

class VOIPcm
priority percent xx
class class-default

fair-queue

int x/x ( wan interface)

service-policy output VOIPpm

Please don't forget to rate any posts that have been helpful.

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

As pdriver's post shows, you can use QoS to guarantee bandwidth for certain traffic outbound.  However, generally you need to guarantee bandwidth inbound too.

Normally, the far side's egress QoS is how you also control near side's ingress.  As you note your SIP traffic is going directly to the Internet, you likely don't have an option to control far side egress (unless it too is using the logical tunnel).

You might police inbound traffic to restrict bandwidth usage of some traffic.  Unfortunately, since this is after the inbound traffic hits your ingress interface, there can be congestion before you can manage/police the traffic.

If possible, what might be your best solution would be a dedicated Internet connection for just the SIP traffic (unless your ISP is willing to implement QoS on their side of your link - most won't).

[jacob6000]

This is great. I will give it a try asap. My only question/suggestion is that maybe I should use the "bandwidth percent" command instead so as to allow more bandwidth to be used if needed and it is available. Right?

[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

Yes and no.  Bandwidth percent often does allow extra bandwidth to be used (actually so does priority percent if there's no interface congestion), but priority percent uses LLQ which helps insure low latency and low jitter (important for VoIP); both not true with bandwidth percent.

VoIP signally, though, generally doesn't require LLQ treatment.

For LLQ (priority percent), Cisco recommends not more than 1/3 allocation, to leave adequate bandwidth for other traffic, but if that's not a concern, you should be safe using up to about 2/3 of the bandwidth for LLQ.  BTW, bandwidth not actually (actively) used by LLQ is available for other traffic too.

[jacob6000]

I am trying to test this policy out by performing multiple file transfers outbound to our remote site which uses the same interface (vpn).  You can see by the txload stats below that it should have been high enough to make the voip policy kick in bit it didn't. There were about six phones connected but not being used. They are just doing keepalives for regisration, etc to the main server, which is indicated in the access list below. Any ideas? Thank you,

Serial0/1/0 is up, line protocol is up
  Hardware is GT96K with integrated T1 CSU/DSU
  Internet address is x.x.x.x/30
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 218/255, rxload 19/255

router#sh policy-map interface serial 0/1/0
Serial0/1/0

  Service-policy output: VOIPpm

    queue stats for all priority classes:

      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0

    Class-map: VOIPcm (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 156
      Priority: 33% (509 kbps), burst bytes 12700, b/w exceed drops: 0

    Class-map: class-default (match-any)
      898811 packets, 199817314 bytes
      5 minute offered rate 23000 bps, drop rate 3000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops/flowdrops) 0/81175/0/81175
      (pkts output/bytes output) 824273/184794616
      Fair-queue: per-flow queue limit 16
router#

CONFIG:

access-list 156 permit ip any host 66.x.x.x.x

class-map match-all VOIPcm
match access-group 156

policy-map VOIPpm
class VOIPcm
    priority percent 33
class class-default
    fair-queue

interface Serial0/1/0
ip address x.x.x.x 255.255.255.252
ip access-group 101 in
ip flow ingress
ip flow egress
ip nat outside
ip inspect ISP2-cbac out
ip virtual-reassembly
encapsulation ppp
crypto map vpnmap
service-policy output VOIPpm
end

[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

Any ideas?

Yes, likely the NAT or encryption is precluding matching on your ACL.

Off the top-of-my-head, I don't recall all the requirement when using NAT and/or encryption with QoS matching, but if your VoIP packets have DSCP markings try matching against those.  (If they don't have DSCP markings, you can use an inbound policy on the inside, with your ACL, to mark the packets.)

Also because of your encryption, your class default is likely only seeing one flow.  Do you have a tunnel interface defined?  If so, use the pre-classify command on it.  (For just encryption, pre-classify should allow your matching to original destination IP, but again, don't recall what you need to do with NAT.)

[jacob6000]

That is my suspicion too but I don't see anything wrong with my ACLs. I will post another message since this more like  a "Part II".

Thank you,

[paul driver]

Hello

Can you ty this:

Policy-map voice_child

class voice

priority xxx

class class-default

Policy-map voice_parent

class class-default

fair queue

service-policy voice_child

interface Serial0/1/0

service-policy output voice_parent

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.