DMVPN Per-Tunnel QoS

(Rene Molenaar) #1

This topic is to discuss the following lesson:

(Andrew P) #2

Thanks for the great article–very timely since I recently finished my DMVPN studies, and I am reviewing QoS! Also, I like your new feature towards the bottom that allows you to click on a device and see its config–cool stuff.

One limitation of this solution seems to be that it works only in DMVPN phase 1, which is now obsolete. As soon as there is spoke-to-spoke traffic, your QoS settings will be lost. Maybe one day there will be a “phase 4” where the spokes will pull down, and apply locally, any group settings from the Hub.

--Andrew

(Rene Molenaar) #3

Hi Andrew,

Glad to hear you like it!

Per-tunnel QoS is a “hub to spoke” solution. It seems there is a spoke-to-spoke solution though, I just found this on the Cisco website:

Per-Tunnel QoS for Spoke to Spoke Connections
The QoS: Spoke to Spoke per tunnel QoS for DMVPN feature enables a DMVPN client to establish a direct crypto tunnel with another DMVPN client leveraging the per-tunnel QoS policy, using Next Hop Resolution Protocol (NHRP) to build spoke-to-spoke connections.

This feature enhances the Adaptive QoS over DMVPN feature, which ensures effective bandwidth management using dynamic shapers based on available bandwidth.

A spoke-to-spoke connection is established when a group identity information, configured on the spokes using the nhrp attribute group command, is exchanged between the spokes through the NHRP Vendor Private Extension (VPE). The NHRP Vendor Private Extensions, encapsulated in NHRP control packets—NHRP resolution request and reply packets.

Assume a network with two spokes—Spoke A and Spoke B, connected to hub. If Spoke A is configured with the nhrp attribute group command and traffic exists between the Spoke A and Spoke B, a resolution request from the Spoke A carries the group identity information as part of Vendor Private Extension (VPE). On receiving the resolution request, Spoke B extracts the VPE header and checks the extension types received as part of the resolution request packet. If the VPE extension has group type, the NHRP VPE parser extracts the group information and checka if a matching map is present. If a matching map is present, QoS applies the policy on the target interface.

Another option is FlexVPN, it does support spoke-to-spoke QoS. FlexVPN is (unofficially) often called DMVPN phase 4.

Rene

(shaun y) #4

hi rene i’m about to start my ccnp switch having just passed my ccnp route exam and i’d like to know if your ccnp switch section covers everything that is going to be thrown at me when I take the exam as I’ve already got the official cisco exam book and it doesn’t cover all the topics for it’s own exam it was the same with there ccnp route book which I find out the hard way when I failed my ccnp route exam the first time after see questions about stuff that the official book covered with just 2 or 3 lines and no configuration examples please help as I just want to know that I have all the information that I need so I can sit down and really get to know it all thanks

(Andrew P) #5

Of course, I will defer to what Rene says, but I believe it is unrealistic to expect any one source to be comprehensive for a CCNP level exam. I think your best bet is to use a variety of sources: videos, books, Cisco’s site, and labs that are available.

One of the best books I picked up for the entire CCNP process was Cisco CCNP Switch Simplified. The book is massive, and the form factor is hilariously large (given “Simplified” in the title). What really makes this title shine are the many, many high quality labs–so with one resource you get both reference material and labs. You will get a lot out of it. Also, I would highly recommend you get this in physical form and not Kindle.

Note: This book was written for the prior SWITCH exam, so you will need to make sure you brush up the topics that were introduced to SWITCH starting in 2015.

--Andrew

(Rene Molenaar) #6

Hi Shaun,

I agree with wat Andrew says here. I’d say the content here is 99% complete. There’s a few minor topics that I still want to add (POE, RPR, SSO).

Rene

(Mathana R) #7

Rene, Great Explanation. I have a question on the QOS part. It seems the QOS service policy is applied on the HUB DMVPN router egress only not on the spoke routers so there is a pretty much chance to over utilize the HUB internet BW by the spokes towards ingress as there is no service policy applied on the Spoke routers egress.
Now a days we are getting high BW internet for low price hence we would require to apply shaping/policing in both the HUBs and SPOKEs otherwise the HUB side (Ingress) internet BW might be over utilized. So do you advise to apply shaping in the SPOKE routers Egress as well by configuring the class-maps/policy-maps manually in them?
Please advise if my view is wrong and provide your explanation.

(Rene Molenaar) #8

Hi Mathana,

This is something to think about yes. When all spoke routers are transmitting data then it’s possible that you could overburden the hub router with traffic. I guess it depends on the connections of your spoke routers. You want to prevent a situation where only a few spoke routers are able to overburden the hub router.

If you have spoke routers that are connected to high bandwidth internet connections then it might be wise to police/shape their traffic towards the hub.

Rene

(Andrew P) #9

Mathana,
In addition to what Rene said, I would also like to point out the importance of having DMVPN running in Phase 3. As you probably know, one of the most important advantages of Phase 3 is that the Hub is used in the control plane, but hardly at all in the data plane (unless the traffic destination is behind the hub). Once you implement “ip nhrp redirect” on the Hub and “ip nhrp shortcut” on the Spokes, almost all spoke-to-spoke traffic will completely bypass the Hub.

Being in Phase 3 should go a long way in combating the problem you talk about where high spoke bandwidth could overwhelm the Hub.

--Andrew

(Mathana R) #10

Rene/Andrew, thanks for the comments. Agreed that spoke to spoke communication will reduce the HUB bandwidth but in most cases the HUB’s are located in the Data Centers and most of the data communication for a spoke is between the Data Center (HUB) and Remote site (a SPOKE), so when number of Spokes are getting increased, we might need to add more HUBS.
It would be great if we have traffic load sharing topics in this section.

(Rene Molenaar) #11

Hi Mathana,

DMVPN is scalable so if needed you can add one or more extra hubs.

If you haven’t seen my dual DMVPN examples before, I think you will like them:

DMVPN Dual hub single cloud

DMVPN Dual hub dual cloud

In these examples I tried to configured routing so that we have a primary and backup hub but load balancing is also no problem.

Rene

(Chris N) #13

It might be worth just explaining the QoS Pre-classify command (also under the tunnel interface) as that is required for CCIE. I believe you can apply the Service Policy to the physical interface first

(Rene Molenaar) #14

Hi Chris,

That might be useful yes. I do have an example for pre-classify here for those that are interested:

Rene

(William K. Y) #15

Hey Rene,
Thank you for going through the NHRP group attribute. Cool stuff. If I may ask the dumb question: since this is a “Hub to Spoke” QoS setting I was wondering what one would do if you needed the spokes to shape at a different rate then the Hub. An example would be an asynchronous circuit provided by the local ISP (ie 10MB down and 2MB up). Would you include the NHRP group in the spoke tunnel config so that the Hub knows what to shape and then attach a regular QoS policy-map to the spoke’s tunnel interface to accomplish this?

(Rene Molenaar) #16

Hi William,

That sounds right. I would configure the hub like I did in my lesson (add the NHRP group on the spoke) so you shape up to the downstream rate of your spoke router (10 Mb).

For the upstream traffic of your spoke router, create a similar policy-map but shape up to the upstream rate (2 Mb).

Rene

(Fabrice M) #17

HI rene
I think to use NBAR we have to enable it on interface ?
So in a real production environment we should have this command :
ip nbar protocol-discovery ?

(Rene Molenaar) #19

Hi @f.mbomda,

You needip nbar protocol-discovery only when you want to use NBAR to discover all protocols that NBAR recognizes on an interface. If you use NBAR in a class-map, you don’t need to use this command.

Rene

(Fahad F) #20

very good Rene,
I have 3 spokes witht 1MB connection to Hub for each , in every spoke Camera monitoring some thing there, daily we are in HQ upload the video from the spoke to the Server with connected to the Hub, how can I apply QOS spoke to hub?

(Rene Molenaar) #21

Hello Fahad,

This example is to apply policies on the hub towards the spoke routers.

If you want QoS for your spoke routers, you can create a regular policy-map, apply it to the physical interface and use QoS Pre-Classify. Something like this:

interface GigabitEthernet0/1
 service-policy output MY_SPOKE_POLICY

Interface Tunnel0
 qos pre-classify

In your policy-map, you can add a priority queue for your video traffic if that’s what you want.

Hope this helps!

Rene