Playing in the Lab: DMVPN and Per-Tunnel QoS

Playing in the Lab: DMVPN and Per-Tunnel QoS

There is this really cool thing about DMVPN that I came across a number of months ago.  Per-Tunnel QoS. Apparently it isn’t just me (as a lab rat) that thinks this is cool.  Every time I show this to people I see eyes light up and little light bulbs turn on in their brains of where they can use this.

Let’s go play in the lab!

pertunnel

 

 

 

 

 

 

 

 

 

Let’s say that Branch_1 and Branch_2 are on the same DMVPN tunnel with DMVPN Hub “Foxtrot14“. We’d like to apply a QoS policy from Hub to Spoke for Branch_2 but not for Branch_1.  Since they are on the same mGRE tunnel how would we do that?

tunnel2_fox14

 

 

 

 

 

 

 

 

Basically what we do is

  • On the DMVPN Hub
    1. configure in the global config section the varying QoS policies you’d like the hub to “offer” as QoS policies for the spokes
    2. apply all the policies you are going to “offer” the spokes on the DMVPN tunnel interface via ip nhrp map group command
  • On the DMVPN spoke configure the DMVPN interface with the mapped group name you’d like to have applied to it.

 

On The DMVPN Hub

Let’s break this down.

“1) configure in the global config section the varying QoS policies you’d like the hub to “offer” as QoS policies for the spokes”

fox_policy

 

 

 

 

 

 

 

 

 

 

 

 

 

So basically what you can see above is that we are configuring our DMVPN hub to have 5 different QoS offerings to the spokes.

  1. 1.5Mbps
  2. 2Mbps
  3. 5Mbps
  4. 10Mbps
  5. Unrestricted

 

“2) apply all the policies you are going to “offer” the spokes on the DMVPN tunnel interface via ip nhrp map group command”

tunnel2_fox14_qos

 

 

 

 

 

On The DMVPN Spoke

“On the DMVPN spoke configure the DMVPN interface with the mapped group name you’d like to have applied to it”

So I simply go to Echo3 (Branch_2) and put the command “ip nhrp group spoke-2Mbps” on the spoke’s tunnel interface.

echo2_tunnel_qos

 

 

 

 

 

 

 

 

 

 

Now what happens?  Echo3 simply puts the name “spoke-2Mbps” into the NHRP registration request. Yup! Really just that simple.  Neat eh?  If you need a little refresher on NHRP registration please go to Fun in the Lab: Sniffer Tracing a DMVPN Tunnel Startup. This will show you the basics of the NHRP registration request.

Let’s see how this looks on the wire and at the DMVPN hub.

You may want to grab the actual pcap file we are going to be looking at together

dmvpn_tunnel_startup_per_tunnel_QoS.pcap        <– it is on my public dropbox and I plan to keep it there for a few years.  🙂

Ready?

We are going to be looking at Frame 18 & Frame 21 in relation to the following network and IP addresses. Tossing this in here closer to the sniffer trace so you can match up IP addresses better.  🙂

prior_to_first_sniffer

 

 

 

 

 

 

 

 

 

 

 

 

 

So first — frame 18. Perfectly normal looking NHRP Registration Request from Echo3 (Branch_2) until we get to the NHRP Vendor Private Extension.

 

branch2_registration_with_qos

 

 

 

 

 

 

 

 

 

 

 

Wanna get your “geek on”?

https://www.branah.com/ascii-converter

ascii_hex

 

 

 

 

 

 

What happens after Frame 18 gets to the DMVPN Hub Foxtrot14?  Well just cause Echo3 (Branch_2) wants “spoke-2Mbps” to be applied to it doesn’t mean it is configured as an option on the hub.  So you will see frame 21 as the registration reply to the request acknowledging ‘spoke-2Mbps” in the vendor specific section again.

Now what?

Let’s go to Foxtrot14 and see what it thinks is the situation.

foxtrot14_dmvpn_det

 

 

 

 

 

 

 

Coolness!  On the same mGRE tunnel we have QoS applied to the hub to spoke traffic to branch_2 but not to branch_1.

 

  • gadam1

    Cool! Thank you! 🙂 Could you please test this feature
    for spoke2spoke connections (in case of phase3) with “nhrp attribute group”?

    • Added to the list. Going to be doing a bunch of IWAN stuff next. Will get back around to this after that.

      • felix khang

        Your session rocked!! I had a similar question as gadam1. How do we setup spoke2spoke qos where spokeA has 2Mbps bw and spokeB has 4Mbps bw? Would we be able to push a policy where the qos shaping is set to the lower bandwidth?

        • I have heard that Cisco is looking into what addl things to add here. My understanding is that, today, we don’t do anything like this. Adaptive QoS is available with DMVPN. Haven’t played with it yet.

  • blueberrymaiden

    Thanks! Great timing, I’m doing a lot of CCNP Sec study.
    (I’d rather go for 2nd CCIE, but I gotta give my employer what they want. 😀 Sometimes.)

    • I have thought actually about going for some CCNP stuff later this year. Right now lots to focus on with IWAN – DMVPN, PfRv3, DIA, etc etc etc.

  • Pingback: Fun in the Lab: Troubleshooting DMVPN Per-Tunnel QoS()

  • Yap Chin Hoong

    Hi Fish, thanks for this.
    Confirm with you again, for the policy map for the 5Mbps, I presume we need the starred line of configuration as similar to the others. Thanks. 🙂

    policy-map spoke-5Mbps-parent
    class class-default
    shape average 5000000
    service-policy child-remaining-policy ***

  • Pingback: Fun in the Lab: DMVPN: Per-Tunnel QoS and High Availability()

  • Markus Forrer

    How can we handle spoke site which have for example 2Mpbs download and only 1Mbps upload?
    For a DMVPN/Pfr (IWAN) setup in the cvd there is the bandwidth defined several time
    – Policy-map with a cir
    – Tunnel interface
    – physical WAN interface
    – nhrp group
    ?