02-24-2014 03:39 PM - edited 03-04-2019 10:25 PM
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
02-25-2014 10:19 AM
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:
---
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.
02-26-2014 08:40 AM
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:
May I know if this command is still needed by per-tunnel QoS configuration on both Hub and Spokes?
Thanks,
Cedar
02-26-2014 10:21 AM
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).
02-26-2014 03:27 PM
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
11-18-2016 12:04 PM
Hi Vasilii,
on spoke just you need to configure under the tunnel this command:
ip nhrp group QOS-2M , right ?
02-26-2014 01:09 PM
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.
02-26-2014 02:49 PM
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
!
!
_______________________________________________________
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide