10-18-2011 01:49 AM
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 cs6match access-group name IKE
class-map match-any CALL-SIGNALING match ip dscp cs3 match ip dscp af31class-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 5class TRANSACTIONAL-DATA
bandwidth percent 27queue-limit 18 packets
class BULK-DATA bandwidth percent 4queue-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 detail
Legend: 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: noneCrypto Session Details:
--------------------------------------------------------------------------------Interface: Tunnel1
Session: [0x8693F664] IKE SA: local 2.2.2.1/500 remote 1.1.1.1/500 Active Capabilities:D connid:2001 lifetime:23:19:07Crypto 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: OpenPending 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
06-06-2012 07:54 PM
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.
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 failure
Conditions: 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.
06-27-2019 09:13 AM
I had this same problem because I was using a port channel as my source interface on my ASR. Had to follow the caveat here:
I basically deleted my interface, made the platform change and recreated my interface and associated configs.
05-18-2022 07:07 AM
We ran into this same issue with port-channel interface configured and seeing these log messages
%NHRP-3-QOS_POLICY_APPLY_FAILED
This document described config needed.
platform qos port-channel-aggregate port-channel-interface-number xxxxxx
But this needs to be done before the port-channel is configured or it needs to be removed, Command added then port-channel config re-configured
05-18-2022 07:57 AM
The other thing you have to watch out for is routing. I ran in to an issue the other day where someone on my team added new static routes pointing to our LAN interface that superceded some of the Internet facing DMVPN routes. When this happens QoS fails the RPF check and per tunnel QoS doesn't apply either with a similar message.
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