QOS on DMVPN using GRE

Unanswered Question

Hi all,

I have a need to apply QOS for Voip in my SOHO network. the spokes are 871's with DMVPN set up to 3845 NHS's.

we have GRE tunnels between each site and need to provide some sort of QOS to support the VOIP traffic. Most of the documentation out there discusses Pre-shared IPSec with GRE but not DMVPN.

I found this link

http://www.cisco.com/en/US/customer/products/ps6558/prod_bulletin0900aecd803f93d6.html

and the contact e-mail bounced back as undeliverable. :)

I would love to use auto qos voip trust but its not supported on GRE tunnels.

I have also looked at qos pre-classify but found the following...

In addition to the usual considerations for QoS over VoIP, these additional considerations need to be made:

1.Ensure that the packet marking for the IP packets is being copied to the GRE tunnel header.

The recommended way of configuring this is to issue the qos pre-classify command to the tunnel interface, and add the service policy to the physical interface.

2. Ensure that the public carrier is capable of providing QoS based on the packet marking you provide.

Why would the Carries need to provide QOS if the packets are encrypted and wrapped in GRE?

I am confused as to how exactly this will work.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Paolo Bevilacqua Wed, 05/02/2007 - 12:09

Hi,

the thing is that you can configure all the QoS you want inside the DMVPN / GRE, but it will have no effect unless the ISP is proving QoS too. That is, your original packet DSCP value is copied in the outer header, to allow the transport network to apply QoS.

Hope this helps, please rate post if it does!

micah.r.stanley Fri, 05/04/2007 - 07:07

Hi Todd,

I work on a pretty complex DMVPN meshed network with extensive VoIP that requires QoS.

Here is a copy of our QoS statements and one of the tunnel configs.

class-map match-all SIPRVoIP

match dscp ef

match access-group name SIPRVoIP

!

class-map match-all TransitVoIP

match dscp ef

match access-group name TransitData

!

class-map match-all NIPRVoIP

match dscp ef

match access-group name NIPRVoIP

!

class-map match-all VoiceSig

match dscp AF12

!

class-map match-any NetworkControl

match access-group name IKE

match dscp AF11

!

class-map match-any TimeSensitive

match dscp af21 af22 af23

!

class-map match-all TransitData

match dscp af41

!

class-map match-any Collaboration

match dscp af31 af32 af33

!

class-map match-all NIPRData

match dscp af42

!

class-map match-all ALL_TRAFFIC

match any

!

class-map match-all TransitData-Remark

match access-group name TransitData

match not dscp ef

!

class-map match-any NetCtrl_2_LW

match dscp cs6

match access-group name IKE

!

class-map match-all CallSig_2_LW

match dscp cs3

!

class-map match-all NetCtrl_2_RTR

match dscp AF11

!

class-map match-all CallSig_2_RTR

match dscp AF12

!

policy-map TransitData-Remark

class TransitData-Remark

set dscp af41

!Apply service policy input interface to tunnel package!

!

policy-map RTR_2_LW

class NetCtrl_2_LW

set dscp AF11

class CallSig_2_LW

set dscp AF12

!Apply service policy input FA0/0 and FA0/1!

!

policy-map LW_2_RTR

class NetCtrl_2_RTR

set dscp CS6

class CallSig_2_RTR

set dscp CS3

!Apply service policy output FA0/0 and FA0/1!

!

policy-map Aggregate

class SIPRVoIP

priority percent 35

class TransitVoIP

priority percent 6

class NIPRVoIP

priority percent 5

class VoiceSig

bandwidth percent 3

class NetworkControl

bandwidth percent 5

class TimeSensitive

bandwidth percent 20

random-detect dscp-based

class TransitData

bandwidth percent 7

Class Collaboration

bandwidth percent 10

random-detect dscp-based

class NIPRData

bandwidth percent 5

class class-default

fair-queue

!Nested in policy-map Linkway!

!

policy-map Linkway

class ALL_TRAFFIC

shape average 3077000

service-policy Aggregate

!Apply service policy output interface to LW!

!

crypto isakmp policy 10

encr aes 256

authentication pre-share

crypto isakmp key CR6700ik address 0.0.0.0 0.0.0.0

crypto isakmp invalid-spi-recovery

!

crypto ipsec transform-set aes_set esp-aes 256 esp-md5-hmac

mode transport

!

crypto ipsec profile XXX

!

interface Tunnel6773

description DMVPN Multipoint Hub to Spokes

ip address x.x.x.x x.x.x.x

no ip redirects

ip mtu 1420

ip pim sparse-mode

ip pim nbma-mode

ip nhrp authentication -------

ip nhrp map multicast dynamic

ip nhrp map multicast x.x.x.x

ip nhrp map x.x.x.x x.x.x.x

ip nhrp network-id 6773

ip nhrp holdtime 600

ip nhrp nhs x.x.x.x

ip nhrp map multicast

ip nhrp map x.x.x.x x.x.x.x

ip nhrp nhs x.x.x.x

ip nhrp map multicast

ip nhrp map x.x.x.x x.x.x.x

ip nhrp nhs x.x.x.x

ip ospf network broadcast

bandwidth 3072

ip ospf priority 4

ip ospf cost 1050

qos pre-classify

tunnel source FastEthernet2/0

tunnel mode gre multipoint

tunnel key XXXX

tunnel protection ipsec profile ---

ip tcp adjust-mss 1332

no ip mask-reply

no ip proxy-arp

ip route-cache flow

no shutdown

set transform-set aes_set

!

Hope that helps you some.

Paolo Bevilacqua Fri, 05/04/2007 - 10:55

Hello,

I see that you apply service policy on fastethernet, my comment would be that since it is unlikely the fastethernet provides backpressure (is never congested), no application of QoS will occur. You can verify this with show interface and service-policy.

The only effective place to configure QoS is where there is congestion, or where bandwitdh is artificially reduced.

micah.r.stanley Mon, 05/07/2007 - 09:59

Due to the architecture of the Network (it is a DoD network... ) The FA interface is the primary interface for traffic destined for the DoD portion of the network (180 nodes in a TDMA mesh each location having 10 - 50 VoIP phones running G711uLaw; the government did not want to spring for DSP farms at all of the CME locations though we are slowly getting to where we can use G729r8 between the locations) and the transit interface for DoD traffic destined for the commercial networks. Therefore, port utilization is high resulting in congestion which did require the use of QoS to improve call quality.

I did not include the rest of the configs that we use as they were not pertinent to this particular discussion, but had you seen them, you would see why it is aplied there.

Paolo Bevilacqua Mon, 05/07/2007 - 12:53

Thank you for explaining the details of traffic amount in this network and good luck with the project!

Actions

This Discussion