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.
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:
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.
I open the url you posted but cannot find anything mentioned QoS Pre-classify command.
May I know if this command is still needed by per-tunnel QoS configuration on both Hub and Spokes?
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).
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?
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.
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.
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.
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
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 ##
class-map match-any MISSION-CRITICAL-DATA
description ## cfy-nbar-MCD-v02 ##
class-map match-any JOURNAL
description CHILD QOS POLICY BASED ON PRIMARY WAN LINK
priority percent 10
set ip dscp ef
bandwidth percent 35
set ip dscp cs4
bandwidth percent 25
set ip dscp cs3
bandwidth percent 15
set ip dscp cs2
bandwidth percent 1
set ip dscp af13
bandwidth percent 4
set ip dscp af11
bandwidth percent 10
set ip dscp default
description Parent QOS POLICY BASED ON PRIMARY WAN LINK
shape average 7680000