12-08-2010 09:59 AM - edited 03-04-2019 10:43 AM
As per the subject, we are receiving this error in the log buffer on a 3845 router running 12.4(24)T4. Our setup is that we're running DMVPN, and have configured per-tunnel QoS for DMVPN, exactly as per the Cisco documentation (http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_per_tunnel_qos.html) and the issue we're finding is that on the hub end (the 3845), the following full error is being received:
Dec 8 10:04:11: %NHRP-3-QOS_POLICY_APPLY_FAILED: Failed to apply QoS policy qos_setoutbound_lb-sh_pm mapped to NHRP group LB_tunnel0 on interface Tunnel0, to tunnel 192.168.175.11 due to policy installation failure
There is not much info on this error... I've looked it up, and all I can find is this fairly useless document: http://www.cisco.com/en/US/docs/ios/system/messages/guide/sm_cn07.html#wp652530
Has anyone seen this sort of issue before when configuring per-tunnel QoS for DMVPN? Any assistance would be much appreciated. I'll try and include some show command outputs when I can.
12-08-2010 07:13 PM
Could you share your QoS configuration on the hub router? One restriction with per-tunnel QoS for DMVPN is that, you cannot have an user-defined class under the parent policy-map with queuing actions. The only class allowed is "class-default" with action "shaping", and all user-defined classes with queuing actions would have to be applied to the child policy under the shaper. This would be one reason you'd see the NHRP-3-QOS_POLICY_APPLY_FAILED error you observed.
Hope this helps,
12-09-2010 01:45 AM
Interesting, thanks for that Wen. Our QoS is primarily aimed at ensuring bandwidth for certain applications, but we do use the priority command to ensure voice traffic is queued faster so that will be our problem, I think; in essence our QoS is configured as follows:
The policy maps are as follows:
shape average 18000000
The command on the tunnel interface is: ip nhrp map group LB_tunnel0 service-policy output qos_setoutbound_lb-sh_pm
I think that the policy map that sets the priority and bandwidth statements would be the problem then, as that affects the queuing? I'd be interested in what you think a solution might be - maybe we mark traffic on the ingress to the hub router (from the LAN) and then let the QoS engine queue based on that?
Frustrating that this restriction isn't listed in the Cisco document, which has a "restrictions" section....