Qos for VoIP on branch Router with DMVPN

[Heinz Schwarzfeuer]

Hi,

we have a 2921 router with a direct connection to the internet (512 KBit) installed in a branch office.

Normal internet traffic (browsing, downloads etc.) is going out / coming in directly through NAT, traffic to/from our Headquarters flows through a GRE tunnel interface (DMVPN with IPSec).

The problem is that VoIP-calls to the HQ (via the DMVPN) are nearly impossible when the internet line is saturated, which happens very often.

My first approach was marking the VoIP-traffic on the LAN-Interface and applying two policy maps on the WAN-interface (one input, one output), but this is not working because the traffic from/to the HQ flows through the DMVPN.

class-map match-any VoIP
 match dscp ef
 match protocol sip
 match protocol skype
 match protocol rtp audio
 match protocol rtp video

policy-map Mark_VoIP_LAN
 class VoIP
 set dscp ef

policy-map QoS-Input
 class VoIP
  set dscp ef
 class class-default
  police cir 400000
  conform-action transmit
  exceed-action drop
  violate-action drop

policy-map QoS-Output
 class VoIP
  priority 100
 class class-default
  fair-queue
  random-detect dscp-based

interface GigabitEthernet0/0
  service-policy input Mark_VoIP_LAN

interface Dialer0
  service-policy input QoS-Input
  service-policy output QoS-Output

How can i ensure that VoIP calls going through the tunnel interface are always getting sufficient bandwidth? Any hints for that scenario?

Many thanks!

Heinz

[Philip D'Ath]

I need more information.  Can you post the config relating to Dialer0.  Is it dsl (atm), vdsl, or something else?

Are you actually using Skype, or is it something else?

[Heinz Schwarzfeuer]

After doing some more research I came to the conclusion that there is not solution for it. The general problem is, that you can´t control what´s coming in from the internet. Downloads, incoming emails, browsing - all this happens concurrently, and this traffic is reaching the router at the full speed of the WAN bandwidth... 

[Philip D'Ath]

This is indeed a big problem.  What you have to do is create an access-list that does not match the traffic you care about.  Then you police this traffic heading towards the lan to the size of your Internet circuit less the amount of traffic you want to reserve for VoIP.

It's not perfect but quite workable.

[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 wha2tsoever (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

Unfortunately, policing Internet ingress often isn't an ideal solution.  The reason being, some traffic doesn't adapt (slow) its transmission rate to loss packets.  Traffic that does (which is more often the case), might still burst congest the ingress before it detects the packet loss and slows its transmission rate.

I've found it you police much, much slower than you really want, you often can get transmission rate adaptive traffic early in its rate control cycle, and avoid ingress link saturation.  Unfortunately, this precludes using your ingress bandwidth, when it's otherwise available.

An alternative to policing, for ingress traffic using TCP, is to "shape" return ACKs.  This works, and I understand it can work pretty well with 3rd party traffic shaping appliances, but on Cisco routers, you cannot achieve the precision you really want.

An effective solution, would be for the ISP to implement QoS on their side of your Internet link, but generally they won't although they will gladly sell you more bandwidth.

Actually, obtaining more ISP bandwidth is often the easiest solution, but not more bandwidth on the same link, but, instead, obtaining two Internet links, one just for your VPN traffic and one for general Internet traffic.

PS:

BTW, another issue with DMVPN, is hubs having more bandwidth than a spoke.  Later DMVPN implementations now support, per (dynamic) tunnel QoS.

[Heinz Schwarzfeuer]

Thanks for your answers, both are worth a try!

[Philip D'Ath]

Also you really need to do a config for the head office as well with a matching QoS policy.