11-10-2010 05:57 PM - edited 02-21-2020 04:58 PM
Hi to all,
I'm Eugene from the Philippines and just want to ask how we can apply a service-policy (QoS) on a tunnel interface of the DMVPN on a Cisco 1941 ISR2. Previously, client's routers were Cisco 1841 ISR. But as we know 1841ISR is on its way EoL/EoS so clients purchased 1941 ISR2 instead for the new sites and well replace the old ones. On a Cisco 1841 we can apply "service-policy output <policy-map name>" on the tunnel interface for DMVPN for the QoS. But when we migrated the configuration to the 1941 ISR2, there were no option to place service-policy under the tunnel interface. How can we apply our QoS on the tunnel interface?
Hope we can have as you support asap as our client already starting to migrated from 1841 to 1941.
Many Thanks and Regards,
Eugene
11-11-2010 09:43 AM
Hi,
The behavior that you are seeing is expected. We blocked the service-policy CLI in 12.4(22)T and later on multipoint GRE tunnel interfaces because we don't support Generic Traffic Shaping (which is required for a QoS configuration on a virtual interface) on such an interfaces. It's not a platform limitation, and my guess is that your 1841 is running an IOS version before 12.4(22)T while the 1941 is running something newer. With 12.4(22)T and later, you have 2 ways to configure QoS for DMVPN:
1. Apply service-policy on the egress physical interface. You will need to use QoS pre-classify on the tunnel if you are classifying traffic based on the pre-encapsulation L3/L4 headers.
2. Use the per-tunnel QoS feature on the DMVPN hub:
Hope this helps,
Thanks,
Wen
11-15-2010 07:36 PM
Hi Wen,
Thanks for the reply.
So you mean we could have this set-up:
HUB (Cisco3845) - run per-tunnel QoS using NHRP groups as hub
SPOKE (Cisco1841) - run QoS pre-classify and service-policy on the DMVPN tunnel interface
SPOKE (Cisco 1941 ISR2) - run per-tunnel QoS using NHRP group as spoke
How about if the DMVPN is a Spoke-to-Spoke set-up will this still be the configuration we can use?
Regards,
Eugene
11-16-2010 07:10 AM
Hi,
Yes, you should run per-tunnel QoS on the hub. For the spokes, it doesn't matter if it's an 1841 or 1941, you should only apply service policy on the physical interface instead of the tunnel, since traffic shaping will not work on a mGRE tunnel interface. As far as how you should classify traffic, I would recommend you use inbound marking and egress classification using DSCP or precedence instead of doing qos pre-classify. This helps removes feature dependencies and will give you more flexibility for end-to-end QoS. When running per-tunnel QoS on the spoke, all it does it to help the hub to provision QoS configuration for traffic going towards that spoke, it doesn't actually do any QoS on the spoke it self. With dynamic spoke to spoke tunnels, you can still apply QoS on the spoke's physical interface, although it would only take effect on the aggregate traffic, and you won't be able to achieve per-spoke QoS granularity.
Thanks,
Wen
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