DMVPN Per-Tunnel QoS

Hello Ajimal

Take a look at this post, you should find your answer there:

I hope this has been helpful!

Laz

Hello Rene,
thanks for the explanation, it was more than enough for understand the how QOS over dmvpn works,
I just have a question about QOS ,and i did a continues research to solve my problem but with no luck, so my question is that:
I have more than 120 branches distributed over my country and I have two hubs in the data center, All these branches connected to the Data Center Core Routers using DMVPN tunnel.
Each Branch has 3 Vlans;one for users and one for Voice and the last one for Cameras.
here is my problem with Cameras Vlan :pensive:
I’m trying to control all traffic that goes from Hub to Spoke just for Cameras Vlan all over the branches but with no luck
is there any solution to solve this problem since i have 120 Cameras vlan ?
how can i control the traffic from the hub toward the branches using QOS i just want 1Mb for Cameras vlan fro each branch ?

I have applied QOS on each spoke to control cameras traffic from spoke-to-hub and its working correctly.

I hope hear a solution from you :slightly_smiling_face:

Hello Amjad

You need to be able to distinguish between VoIP, data, and camera traffic on the hub router. You can do this by using the appropriate class maps and policy maps. Now in the lesson, VoIP traffic is identified using the RTP protocol, so this can easily be distinguished from other types of traffic. You can however take care to mark your camera traffic with a specific DSCP, and then have the class/policy maps you create, match that particular DSCP value, and treat it accordingly.

To mark DSCP values of traffic, take a look at the following lesson:

Note that you will have to mark such traffic either at the source of the traffic (the NVR?) or somewhere within your network, possibly at the switch/router interface that connects to your NVR.

Once the traffic is marked, you can use the same principle as that used for VoIP traffic in the lesson, but instead of matching for the RTP protocol, you can match for the particular DSCP value. Make sure to use a DSCP value that is not used by other types of traffic.

Try it out and let us know your results!

I hope this has been helpful!

Laz

Hi,
i am trying to include Policy-map whith CBWFW, LLQ and a Shaper, but getting an error:
Here is my config:

class-map match-all CM_QOS_GROUP_0
 match qos-group 0

class-map match-all CM_QOS_GROUP_1
 match qos-group 1

class-map match-all CM_QOS_GROUP_2
 match qos-group 2

class-map match-all CM_QOS_GROUP_3
 match qos-group 3

class-map match-all CM_QOS_GROUP_4
 match qos-group 4

class-map match-all CM_QOS_GROUP_5
 match qos-group 5
policy-map PM_QUEUE_BY_CLASS_AND_SHAPE_10M
 class CM_QOS_GROUP_0
  bandwidth percent 15
  set dscp tunnel default

 class CM_QOS_GROUP_1
  bandwidth percent 34
  set dscp tunnel cs1

 class CM_QOS_GROUP_2
  bandwidth percent 15
  set dscp tunnel cs2

 class CM_QOS_GROUP_3
  bandwidth percent 1
  set dscp tunnel cs3

 class CM_QOS_GROUP_4
  bandwidth percent 30
  set dscp tunnel cs4

 class CM_QOS_GROUP_5
  priority percent 5
  set dscp tunnel cs5
policy-map SHAPER-10M
 class class-default
  shape average 10000000
  service-policy PM_QUEUE_BY_CLASS_AND_SHAPE_10M
interface Tunnel100
nhrp map group SPOKES_10MB service-policy output PM_QUEUE_BY_CLASS_AND_SHAPE_10M

Once i configure it, i am receiving following errors:

.Mar 27 2025 15:36:50: %NHRP-3-QOS_POLICY_APPLY_FAILED: Failed to apply QoS policy PM_QUEUE_BY_CLASS_AND_SHAPE_10M mapped to NHRP group SPOKES_10MB on interface Tunnel100, to tunnel 10.x.x.65 due to policy installation failureWeighted Fair Queueing feature is not supported in user defined class of parent level policy

Do you have an idea ? I thought, i am using CBWFW and not weighted fair queuing ?

Kind Regards,
Oliver

Hello Oliver

Based on what you have shared, I can give you some information about the possible reasons behind the behavior you are seeing. Hopefully, they’ll give you some direction on how to troubleshoot further and resolve the issue.

There are two particular things you can look into:

The application of the child policy. It seems that you have applied the PM_QUEUE_BY_CLASS_AND_SHAPE_10M child policy directly to the NHRP group. However, for a hierarchical QoS implementation for DMVPN per tunnel QoS, the parent policy, which includes the shaper, must be applied to the NHRP group, not the child policy. You should thus apply the SHAPER-10M to the NHRP group rather than the PM_QUEUE_BY_CLASS_AND_SHAPE_10M.

Secondly, why are you getting the error you’re getting concerning WFQ? Well there may be several reasons, but they all stem from the same problem.

It may be because of your use of bandwidth percent instead of bandwidth remaining percent in the child policy. The bandwidth percent option is not recommended with hierarchical policies that include a shaper. This Cisco Documentation states that "The bandwidth command is part of the parent policy. In this instance, the bandwidth command not only sets the minimum bandwidth for the class but also resets the reference point for the bandwidth percent statements in the child policy.

It may also be because, in some platforms and IOS versions, the mechanism defaults to WFQ in a shaped parent class if no child is attached. Since you applied the child and not the parent, this may be a result.

I hope that the above will help you in your troubleshooting! Let us know how you get along!

I hope this has been helpful!

Laz

Hello Laz,
thanks a lot for spotting and pointing my mistake. Of course i have to bind the parent policy (including shaper) to the to the NHRP group.
It works after changing it to:

nhrp map group SPOKES_10MB service-policy output SHAPER-10M

I didn’t get any further errors regarding WFQ.
Do you think i still should move to bandwidth remaining percent instead of bandwidth percent ? The 8500 router (C8500-12X4QC) took it also with “bandwidth percent” which seems to be easier to understand and calculate.

Many thanks again for pointing me to the correct direction.
Kind Regards,
Oliver

Hello Oliver

Glad to hear that all worked out well! As for the bandwidth percent vs bandwidth remaining percent, you won’t get any errors as your configuration stands. But you will find that the reference used as the bandwidth for each case will differ.

If you use bandwidth percent, then the shaping rate of the parent will be used as the reference value to calculate the percents, which is 10Mbps.

If you use bandwidth remaining percent, then the reference bandwidth used is that of the configured shaper minus the LLQ priority percent you applied (which in your case is 5%). So the reference bandwidth is now 9.5Mbps.

For your setup, the difference is minimal, and it is unlikely that you will encounter any problems. But if your LLQ priority was set to, say, 30%, then your bandwidth percent command would still use the 10 Mbps as the reference, but there is only 7 Mbps remaining, so there is a danger of oversubscription.

For this reason, Cisco recommends that child policies use bandwidth remaining percent to ensure that only the actual available bandwidth is used in calculations to avoid oversubscription. Does that make sense?

I hope this has been helpful!

Laz