Per Tunnel QoS: NHRP-3-QOS_POLICY_APPLY_FAILED

Question

Hello,
another day another problem :-)
Since I got DMVPN Netzwork up and running for a few month now, the customer wishes to implement voice-over-ip, therefore I tryied to configure Per-Tunnel-QoS  in the DMVPN Network.
The Policy Map on the Hub-Site is as followed:
class-map match-all BULK-DATA match ip dscp af11  af12
class-map match-all INTERACTIVE-VIDEO
match ip dscp af41  af42
class-map match-all VOICE
match ip dscp ef
class-map match-all SCAVENGER
match ip dscp cs1
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6
match access-group name IKEclass-map match-any CALL-SIGNALING
match ip dscp cs3
match ip dscp af31
class-map match-all TRANSACTIONAL-DATA match ip dscp af21  af22
policy-map voice
class VOICE
    priority percent 18
class INTERACTIVE-VIDEO
    priority percent 15
class CALL-SIGNALING
    bandwidth percent 5
class INTERNETWORK-CONTROL
    bandwidth percent 5
class TRANSACTIONAL-DATA    bandwidth percent 27
    queue-limit 18 packets class BULK-DATA
    bandwidth percent 4
    queue-limit 3 packets class SCAVENGER
    bandwidth percent 1
    queue-limit 1 packets
class class-default
    bandwidth percent 25
    queue-limit 16 packets
The Hub and the Spokes are configured with the proper NHRP Group, but when checking the QoS State, the Spokes appair to be in the right NHRP Group but the QoS service policy is not applied.
Hub#sh dmvpn detailLegend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface Tunnel1 is up/up, Addr. is 192.168.205.1, VRF ""
   Tunnel Src./Dest. addr: 2.2.2.1/MGRE, Tunnel VRF ""   Protocol/Transport: "multi-GRE/IP", Protect "Schmidt-Group"
   Interface State Control: Disabled
Type:Hub, Total NBMA Peers (v4/v6): 1
# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target  Network----- --------------- --------------- ----- -------- -----  -----------------
    1        1.1.1.1   192.168.205.2    UP 00:40:52    D   192.168.205.2/32NHRP group: voice
Output QoS service-policy applied: none
Crypto Session Details:--------------------------------------------------------------------------------
Interface: Tunnel1Session: [0x8693F664]
  IKE SA: local 2.2.2.1/500 remote 1.1.1.1/500 Active
          Capabilities:D connid:2001 lifetime:23:19:07
  Crypto Session Status: UP-ACTIVE  fvrf: (none), Phase1_id: 1.1.1.1
  IPSEC FLOW: permit 47 host 2.2.2.1 host 1.1.1.1
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 574 drop 0 life (KB/Sec) 4487723/1147        Outbound: #pkts enc'ed 560 drop 0 life (KB/Sec) 4487725/1147   Outbound SPI : 0xABF33617, transform : esp-256-aes esp-sha-hmac
    Socket State: Open
Pending DMVPN Sessions:
A debugging on QoS events results with the message:
Oct 18 08:20:51.883: %NHRP-3-QOS_POLICY_APPLY_FAILED: Failed to apply QoS  policy voice mapped to NHRP
group voice on interface Tunnel1, to tunnel 1.1.1.1  due to policy installation failure
I'm greatfull for any suggestions or hints!
Kind regards
Thomas

Answer 1

I have the same problem. I found this info, it might be related to your problem. For me, I only have one spoke on my QoS/DMVPN Hub tunnel. However, I am running MPLS-VPN, multiple Hub tunnels connecting to multiple spokes so the policy could be see all spokes connected to my router, not just the hub tunnel.
https://cisco-images.test.edgekey.net/en/US/docs/ios/ios_xe/3/release/notes/asr1k_rn_3s_rel_notes_book_pdf.pdf
CSCts62082
Symptoms: Router generates the following message:%NHRP-3-QOS_POLICY_APPLY_FAILED: Failed to apply QoS policy 10M-shape mapped
to NHRP group xx on interface Tunnelxx, to tunnel x.x.x.x due to policy
installation failureConditions: This symptom is observed when “per-tunnel” QoS is applied and there are more than
nine DMVPN spokes. (Up to eight spokes, with QoS applied is fine.)
Workaround: There is no workaround.