Understanding in practice: DMVPN and Per-Tunnel QoS

On the eve of the start of the course “Network Engineer” prepared for you a translation of interesting material


There is one great thing about DMVPN that I ran into a while ago: DMVPN Per-Tunnel QoS… Obviously, I’m not the only one (like a lab rat) who think this is cool. Every time I show this to people, I see their eyes light up – a consequence of the fact that small bulbs start to glow in their heads, indicating the emergence of ideas where they can use it.

Time to unleash your geek!

Let’s pretend that Branch_1 and Branch_2 are in the same DMVPN tunnel with a DMVPN hub “Foxtrot14”… We would like to apply a Hub to Spock QoS policy for Branch_2but not for Branch_1… Since they are in the same mGRE tunnel, how do we do this?

Essentially what we have to do is:

  • On the DMVPN hub:
    1. In the global configuration section, configure various QoS policies that you want the hub to “offer” as QoS policies for spooks
    2. We apply all the policies that you are going to “offer” spooks in the DMVPN tunnel interface using the command ip nhrp map group
  • On the DMVPN Spock, configure a DMVPN interface with the name of the mapped group that you would like to apply to it.

On the DMVPN hub

Let’s deal with this:

“1) In the global configuration section, we configure various QoS policies that you want the hub to” offer “as QoS policies for spokes”

So, in general, what you can see above is that we are configuring our DMVPN hub for 5 different QoS offerings in spokes.

  1. 1.5Mbps
  2. 2Mbps
  3. 5Mbps
  4. 10Mbps
  5. No limit

“2) We apply all the policies that you are going to” offer “spoks in the DMVPN tunnel interface using the ip nhrp map group command”

On DMVPN Spock

“On the DMVPN Spock, configure a DMVPN interface with the name of the mapped group that you would like to apply to it.”

So I just go to Echo3 (Branch_2) and put the command “ip nhrp group spoke-2Mbps” into the Spock tunnel interface.

What will happen now? Echo3 just puts the name “spoke-2Mbps” in the NHRP registration request. Voila! It’s really that simple. Neat, right? If you need a little brush up on NHRP registration, read Fun in the Lab: Sniffer Tracing a DMVPN Tunnel Startup… There you will find the basics of the NHRP registration request.

Let’s see how it looks on the network and on the DMVPN hub.

You can get the actual file pcapwhich we will consider together

dmvpn_tunnel_startup_per_tunnel_QoS.pcap <- it's in my public Dropbox and I plan to keep it there for a few years.Ready?We are going to review Frame 18 and Frame 21 for the following networks and IP addresses. Place this closer to the sniffer trace so you can better match IP addresses.

So, the first is frame 18. NHRP registration request from Echo3 (Branch_2) looks perfectly fine until we get to the NHRP Vendor Private Extension.

Want to pamper the geek within you?
www.branah.com/ascii-converter

What happens after Frame 18 hits the DMVPN hub Foxtrot14? Because Echo3 (Branch_2) wants to have “spoke-2Mbps” applied to it doesn’t mean it’s a configured option on the hub. So you will see frame 21 again as a response to a registration request confirming “spoke-2Mbps” in the vendor section.

Now what?

Let’s go to Foxtrot14 and see what he thinks about this situation.

Wonderful! In the same mGRE tunnel, we have QoS applied to the hub to spok traffic to branch_2but not to branch_1

* NOTE: This post was originally published on this site in 2015. It was last updated and formatted on February 15, 2020.


Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *