QoS on a DMVPN

[David Sharp]

Hi All,

I am wondering if anyone has any practical experience with setting up QoS on a dynamic spoke-to-spoke DMVPN.

We have a "standard" QoS script that we apply to the 2800 and 2900 series routers throughout our enterprise. We recently deployed a DMVPN environment for some future sites (mainly to enable dynamic routing over lower-grade WAN services that are routed statically). In particular, some of these sites will be deploying VoIP and we need to classify and prioritise the traffic accordingly (via DSCP 46 / EF). We make the classifications on a child policy, and then apply shaping on a parent policy, and it seems the DMVPN won't support this.

Ideally, we'd also like the ToS / DSCP marking to be preserved during the encapsulation process. For example, for a voice packet marked as EF prior to DMVPN / GRE encapsulation, the GRE Encapsulated packet should also be marked as EF when it crosses the WAN.

I have opened a TAC Case with Cisco on this topic, they advised that ToS / DSCP markings are preserved automatically with GRE encapsulation but this doesn't sound right to me - other forums have mentioned you need to use the "qos pre-classify" command to do this (I have also tried getting this to work, without results). TAC are telling me to try something called Per Tunnel QoS. Has anyone ever used this? Any feedback on this at all?

I know QoS is a very broad-ranging topic but it's not really one of my strengths, I appreciate any feedback that people might have.

Cheers 

[Vasilii Mikhailovskii]

Hello, David.

First of all, Cisco TAC is correct about "qos pre-classify" command: on the spokes you need the command under tunnel configuration, but service policy should be applied on physical interface that originates tunnel.

They also correct about automatic marking of encapsulating packet (it inherits original dscp value).

(if you think it doesn't work, please share your configuration here).

For Hub QoS you would better implement nhrp group based QoS:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-2mt/sec-conn-dmvpn-per-tunnel-qos.html

---

For spoke-to-spoke traffic the primary challenge is to manage inbound congestion on the spoke! And actually you have nothing to do with it (but ask your ISP for QoS). Surely there is no QoS over Internet links, so it's impossible to solve the problem for spoke-to-spoke traffic.

To be fair, we need to understand that QoS on DMVPN can do only one thing - manage outbound queue, but not inbound!

If you implement QoS on Hub based on nhrp group - this could help you to manage traffic that is sent from Hub to spoke and you almost solved inbound congestion problem, but only if Hub is the only peer that is sending traffic (it means no spoke-to-spoke traffic). Surely this scenario won't help you if anybody starts sending traffic to you spoke (a lot of UDP/ESP/multicast by mistake, on purpose for DoS).

PS: I had a couple of networks with DMVPN (and QoS) and I figured out that if you want to manage inbound congestion, then build it as star without spoke-to-spoke connections or just have as much bandwidth as you can . If you want true QoS, then MPLS based solution is the only way.

[cedar_lee]

Hi Mikhail,

I open the url you posted but cannot find anything mentioned QoS Pre-classify command.

For Hub QoS you would better implement nhrp group based QoS:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-2mt/sec-conn-dmvpn-per-tunnel-qos.html

May I know if this command is still needed by per-tunnel QoS configuration on both Hub and Spokes?

Thanks,

Cedar

[Vasilii Mikhailovskii]

Hello.

Per-tunnel QoS is about QoS configuration on Hub only.

On spokes you still need to apply service-policy to the physical interface and you need the command "qos-preclassify" under tunnel (on spoke only).

[cedar_lee]

Thanks Mikhail.

If I understand what you said correctly, Per-tunnel QoS on Hub configuration does not need the command "qos pre-classify" on either physical or tunnel interface.

Is that right?

Thanks

Cedar

[Amjad Hamayel]

Hi Vasilii,

 on spoke just you need to configure under the tunnel this command:

ip nhrp group QOS-2M  ,  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

If you're going to allow multi-point communication, i.e. spoke to spoke, forget QoS unless you're underlying transport (e.g. MPLS) will honor your QoS markings as you desire.  Why?  Well as soon as more than one site sends to another, the transport cloud egress device may congest and you'll need QoS there.  With hub and spoke, and assuming hub has more bandwidth than individual spokes, hub can know (and shape for) available bandwidth to spokes, spokes "know" their own bandwidth and you can control oversubscription of aggregate of spokes to hub.

On later DMVPN IOS versions (e.g. in the 12.4T train), you have different perdefined policies, usually one for each different desired shape rate, and spoke tells hub which to use on tunnel to it.  (Yes, I've used it.)

Original packet's ToS markings should be copied to GRE ToS.

Pre-classify is used by egress to look at a shadow copy of original packets IP header.  This so you can still clasify egress tunnel traffic on more than GRE copies ToS.  Also useful if using flow base queuing, otherwise egress sees tunnels packets as just one flow.

[David Sharp]

Thanks everyone for your feedback.

In line with what TAC is suggesting, I will lab up a Per Tunnel QoS based solution. We already have about 100 sites on the DMVPN (that don't need the QoS yet) but if I make the required changes to the hub (i.e. implementing an NHRP group) will this affect the connectivity of any spokes? (Not talking about QoS here, I just want to know if implementing this / creating NHRP groups will bring down the existing tunnels). Once we apply the Per Tunnel Qos at the hub, even if spoke-to-spoke communication occurs, the hub will apply the QoS policy to the spokes, is that right?

It sounds like QoS Pre-Classify might be a handy command to add into the tunnel interfaces regardless.

Regarding the underlying transport, our provider does honour these markings, hence the questions about the preserving of the original ToS / DSCP marking after encapsulation. Marking DSCP onto packets prior to WAN transportation is part of the service policy. We are not running the DMVPN over the internet.

Below is an extract from the QoS Script I want to apply. We've tried implementing this as-is on the DMVPN spokes however it gets rejected because of the parent / child policy.

____________________________________________

!

class-map match-any MULTIMEDIA

description ## cfy-nbar-MUL-v01 ##

match ip dscp ef

class-map match-any LOW-PRIORITY-INTERACTIVE

match protocol

match protocol

class-map match-any DATA-TRANSFER
description ## cfy-nbar-DAT-v03 ##

match access-group name cfy-COMMVLT-v01

class-map match-any INTERACTIVE

description ## cfy-nbar-INT-v02 ##

match protocol

match protocol

match protocol

match access-group

class-map match-any MISSION-CRITICAL-DATA

description ## cfy-nbar-MCD-v02 ##

match class-map

match class-map

match protocol

match protocol

class-map match-any JOURNAL

match access-group

match access-group

!

!

policy-map cbq-PRIMARY-WAN-ETH-CHILD-v01

description CHILD QOS POLICY BASED ON PRIMARY WAN LINK

class MULTIMEDIA

    priority percent 10

  set ip dscp ef

class MISSION-CRITICAL-DATA

    bandwidth percent 35

     random-detect dscp-based

  set ip dscp cs4

class INTERACTIVE

    bandwidth percent 25

     random-detect dscp-based

  set ip dscp cs3

class LOW-PRIORITY-INTERACTIVE

    bandwidth percent 15

     random-detect dscp-based

  set ip dscp cs2

class DATA-TRANSFER

    bandwidth percent 1

     random-detect dscp-based

  set ip dscp af13

class JOURNAL

    bandwidth percent 4

     random-detect dscp-based

  set ip dscp af11

class class-default

    bandwidth percent 10

     random-detect dscp-based

  set ip dscp default

!

policy-map cbq-PRIMARY-WAN-ETH-PARENT-v01

description Parent QOS POLICY BASED ON PRIMARY WAN LINK

class class-default

    shape average 7680000

  service-policy cbq-PRIMARY-WAN-ETH-CHILD-v01

!

!

_______________________________________________________