CartWe conclude this multi-part techtorial with Part 3, QoS for Dynamic Multipoint VPN.
DMVPN provides the ability for large scale VPN’s, in a Hub and Spoke topology, while using a simplified Dynamic deployment model for the spokes. This is due to the reduced configuration required on the Hub device.
DMVPN combines the use of four key technologies; IPSec, Generic Routing Encapsulation (GRE) Tunnels, Next Hop Resolution Protocol (NHRP) and a Dynamic Routing Protocol (OSPF, EIGRP etc.). In DMVPN we need to look to the NHRP protocol to provide us with a method of implementing Per Tunnel QoS; this feature is called NHRP Groups.
We should start to see a pattern emerging here; Tunnel Groups on the ASA; QoS Groups for IOS VPN; and now NHRP Groups for DMVPN! All of which, we use as classifiers for our QoS policies.
NHRP groups are configured on the Spokes GRE tunnel interfaces, and acts to identify each tunnel to the Hub device. The NHRP group is passed to the Hub during the NHRP registration process, which is sent from Spoke to Hub. Static mappings are applied to each spoke so they can identify where to initiaite their registration to. This is the key to the operation of DMVPN as a whole, as its responsible for dynamically updating the Hubs NHRP tables with the registering spokes information. This spoke info allows the establishment of the IPSec SA’s in both directions.
Assuming that the DMVPN configuration is already in place, several requirements/restrictions exist for NHRP groups:
• CEF must be enabled to use NHRP Groups
• You can only use 1 NHRP Group Per DMVPN Tunnel Interface
• If multiple tunnel interfaces exist on the spoke then seperate groups names can be used on each interface.
The slight difference we have over the previous examples for VPN QoS, is although the groups are defined on the spoke router, the policy is defined and applied on the Hub.
The Spoke side configuration is pretty simple, all we need to do is enter tunnel interface config mode and apply the group to the GRE Interface, so for example set an NHRP group of SpokeGrp1 to the interface for Tunnel1:
interface Tunnel 1 ip nhrp group SpokeGrp1
Simple huh! The bulk of the configuration is actually done on the Hub router, so all were doing here is tagging the tunnel with an ID. Now for the Hub.
In comparison to our previous examples the NHRP group is not matched within the Class Map, instead we use an NHRP Map command to associate the group to a defined QoS policy. This leaves us the flexibility to match on specific traffic in our class maps.
For example on the Hub GRE interface map the group to a policy:
Interface Tunnel 1 ip nhrp map group SpokeGrp1 service-policy output SpokeGrp1_QoS
Ok lets move on to an example scenario.
Above we have a simple Hub and two spoke DMVPN setup. The tunnel for R4 Spoke 1 will be tagged with the NHRP Group of WEST, and R5 Spoke 2 will be tagged as EAST.
QoS policies will be defined on the Hub router using the following:
• R4’s WEST group requires to be shaped to 1Mb
• R5’s EAST group requires a nested policy for the following:
• Prioritise critical application traffic marked as DSCP AF43 to 512k
• Shape all traffic to 1mb
Configuration:
So starting with the Spokes we need to assign the NHRP groups:
R4:
Interface Tunnel 1 ip nhrp group WEST
R5:
Interface Tunnel 1 ip nhrp group EAST
Then we move to the Hub router to define the QoS policies and associate them to each group:
R2:
class-map match-all PRIORITY match ip dscp af43 ! policy-map PRIORITY_QOS class PRIORITY priority 512 ! policy-map WEST_QOS class class-default shape average 1000000 ! policy-map EAST_QOS class class-default shape average 1000000 service-policy PRIORITY_QOS ! interface Tunnel1 ip nhrp map group EAST service-policy output EAST_QOS ip nhrp map group WEST service-policy output WEST_QOS
There you have it, the configuration for the above requirements. Class defaults are used to match on any traffic flow. The small addition here is the inclusion of the hierarchical nested policy. This is made up of two separate policies, a Child policy (PRIORITY_QOS) that is in turn applied to the Parent policy (EAST_QOS). The Parent / Child relationship allows a more granular approach, by providing the ability to assign different actions to both Parent and Child, based on the traffic flows defined with their respective classes.
A nice plus point to this method is that the QoS is applied on the arrival of the next packet without the need to restart the IPSec SA’s.
Verification:
Now we have the config in place next step is to verify it. Verification should be done on the Hub Router. Show DMVPN Detail is a good place to start. Here we can see the peer information, the group mapping and the applied service policies.
R2_Hub#show 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 =================================================================== Intferface Tunnel1 is up/up, Addr. is 10.1.245.2, VRF "" Tunnel Src./Dest. addr: 192.1.2.2/MGRE, Tunnel VRF "" Protocol/Transport: "multi-GRE/IP", Protect "DMP" Type:Hub, Total NBMA Peers (v4/v6): 2 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network ----- --------------- --------------- ----- -------- ----- ----------------- 1 192.1.2.4 10.1.245.4 UP 01:15:20 D 10.1.245.4/32 NHRP group: WEST Output QoS service-policy applied: WEST_QOS 1 192.1.2.5 10.1.245.5 UP 01:15:31 D 10.1.245.5/32 NHRP group: EAST Output QoS service-policy applied: EAST_QOS
Or alternatively, show ip nhrp group-map provides the more specific information:
R2_Hub#show ip nhrp group-map Interface: Tunnel1 NHRP group: EAST QoS policy: EAST_QOS Tunnels using the QoS policy: Tunnel destination overlay/transport address 10.1.245.5/192.1.2.5 NHRP group: WEST QoS policy: WEST_QOS Tunnels using the QoS policy: Tunnel destination overlay/transport address 10.1.245.4/192.1.2.4
Final piece of verification is to check that the policy is in effect.
Use the show policy-map multipoint to confirm this:
R2_Hub#show policy-map multipoint Interface Tunnel1 <--> 192.1.2.4 Service-policy output: WEST_QOS Class-map: class-default (match-any) 4630 packets, 5171238 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Queueing queue limit 250 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 shape (average) cir 1000000, bc 4000, be 4000 target shape rate 1000000 Interface Tunnel1 <--> 192.1.2.5 Service-policy output: EAST_QOS Class-map: class-default (match-any) 4979 packets, 1989296 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Queueing queue limit 250 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 shape (average) cir 1000000, bc 4000, be 4000 target shape rate 1000000 Service-policy : PRIORITY_QOS queue stats for all priority classes: queue limit 128 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 Class-map: PRIORITY (match-all) 1000 packets, 124000 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp af43 (38) Priority: 512 kbps, burst bytes 12800, b/w exceed drops: 0 Class-map: class-default (match-any) 255 packets, 22278 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any queue limit 122 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 R2_Hub#
For reference, Ive included the core configs for each router below.
R2_Hub# ! hostname R2_Hub ! crypto isakmp policy 10 encr aes authentication pre-share group 5 crypto isakmp key cisco address 0.0.0.0 0.0.0.0 ! ! crypto ipsec transform-set TS esp-aes esp-sha-hmac ! crypto ipsec profile DMP set transform-set TS ! class-map match-all PRIORITY match ip dscp af43 ! policy-map PRIORITY_QOS class PRIORITY priority 512 class class-default policy-map WEST_QOS class class-default shape average 1000000 policy-map EAST_QOS class class-default shape average 1000000 service-policy PRIORITY_QOS ! interface Tunnel1 ip address 10.1.245.2 255.255.255.0 no ip redirects ip mtu 1400 no ip next-hop-self eigrp 1 ip nhrp authentication cisco ip nhrp map multicast dynamic ip nhrp map group EAST service-policy output EAST_QOS ip nhrp map group WEST service-policy output WEST_QOS ip nhrp network-id 245 ip nhrp holdtime 300 ip tcp adjust-mss 1360 no ip split-horizon eigrp 1 tunnel source FastEthernet1/1 tunnel mode gre multipoint tunnel protection ipsec profile DMP ! interface FastEthernet1/0 no switchport ip address 10.1.2.2 255.255.255.0 ! interface FastEthernet1/1 no switchport ip address 192.1.2.2 255.255.255.0 ! router eigrp 1 network 10.1.2.0 0.0.0.255 network 10.1.245.0 0.0.0.255 no auto-summary !
R4_Spoke1# ! crypto isakmp policy 10 encr aes authentication pre-share group 5 crypto isakmp key cisco address 0.0.0.0 0.0.0.0 ! crypto ipsec transform-set TS esp-aes esp-sha-hmac ! crypto ipsec profile DMP set transform-set TS ! interface Tunnel1 bandwidth 1000 ip address 10.1.245.4 255.255.255.0 no ip redirects ip mtu 1400 ip nhrp authentication cisco ip nhrp group WEST ip nhrp map multicast 192.1.2.2 ip nhrp map 10.1.245.2 192.1.2.2 ip nhrp network-id 245 ip nhrp holdtime 300 ip nhrp nhs 10.1.245.2 ip tcp adjust-mss 1360 tunnel source FastEthernet0/1 tunnel mode gre multipoint tunnel protection ipsec profile DMP ! interface FastEthernet0/0 ip address 10.1.4.4 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.1.2.4 255.255.255.0 duplex auto speed auto ! router eigrp 1 network 10.1.4.0 0.0.0.255 network 10.1.245.0 0.0.0.255 no auto-summary !
R5_spoke2# ! crypto isakmp policy 10 encr aes authentication pre-share group 5 crypto isakmp key cisco address 0.0.0.0 0.0.0.0 ! ! crypto ipsec transform-set TS esp-aes esp-sha-hmac ! crypto ipsec profile DMP set transform-set TS ! interface Tunnel1 bandwidth 1000 ip address 10.1.245.5 255.255.255.0 no ip redirects ip mtu 1400 ip nhrp authentication cisco ip nhrp group EAST ip nhrp map multicast 192.1.2.2 ip nhrp map 10.1.245.2 192.1.2.2 ip nhrp network-id 245 ip nhrp holdtime 300 ip nhrp nhs 10.1.245.2 ip tcp adjust-mss 1360 tunnel source FastEthernet0/1 tunnel mode gre multipoint tunnel protection ipsec profile DMP ! interface FastEthernet0/0 ip address 10.1.5.5 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.1.2.5 255.255.255.0 duplex auto speed auto ! router eigrp 1 network 10.1.5.0 0.0.0.255 network 10.1.245.0 0.0.0.255 no auto-summary ! end
Hopefully these three Techtorials have provided some insight into the ways we can incorporate common Quality of Service methods into our VPN deployments, and ultimately bolster the knowledge required for success in your future lab attempts. See ya soon with some more posts :-)
Stu…
Regards,
Stuart Hare
CCIE #25616 (Security), CCSP, Microsoft MCP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com
Hi Erik,
I cant comment on WAAS as I am unfamiliar with the technology, although I expect that using such compression technologies would have a negative effect on the IPSec traffic, thus causing the vpn to fail.
Im not quite understanding your design, are you saying that your DMVPN is running across the internet?
As explained the policies are not applied at the branch but at the hub site.
A possible solution would be to use a policy at the branch end to mark the mentioned traffic, using ip precedence or dscp value in order to give them a hierarchical preference.
At the hub you could then match on these dscp or precedence values, to apply a priority queue for citrix for instance, dedicate bandwidth percentage for Sharepoint etc.
All depends on the overall network design and what exactly your trying to acheive.
Stu
Sorry Smeegs,
I have never had a call for manipulating the output in such a way, so never looked into it.
Stu
Hi Paulo,
The policy is only defined on the Hub device, and is mapped to the group on the hubs tunnel interface.
There is no pushing of policies to the spokes.
Stu
Very helpful post. Thank you.
But, I am in doubt … no policy was created on the spoke side, right? So it means that the policy will be someway pushed to the spoke or the policy will only be applied to the hub-to-spoke traffic?
Paulo Roque
Hi Stuart, could you elaborate a little more on QoS at the branch considering when branches have a local internet breakout.
And to make it a litte more complicated, what if the branch uses WAAS (WAE modules) that explode traffic once “decapsulated”.
Example: branch with 4mbps internet and dual-hub DMVPN topology (2 tunnels), priority for citrix above https(sharepoint) above email, webbrowsing. Thanks, Erik
Hey Stuart,
We’ve been making use of DMVPN groups for a couple months now and I haven’t yet found a way to graph the QoS statistics. We had a CBWFQ template in Cacti which works fine, until we moved to groups. I’ve searched high and low for a new MIB and trawled through the output of a walk and can’t find anything. You wouldn’t happen to be aware of a way to get the kind of output provided by ‘sh policy-map multi’ over SNMP?
Thanks