Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

DMVPN: HUB Redundancy

I am new to DMVPN and is in the process planning for a small (50 spoke) trial setup.

We plan to have two hub routers in two different cities.  At this point, my focus is the redundancy instead of load sharing among them.

My understanding is I can achieve redundancy by:

(option-A) Single DMVPN network with two HUB in it, and do NHRP

(option-B) Two DMVPN networks each with one HUB, and use EIGRP (matrix) so traffic route to backup HUB when primary HUB is gone.

Am I thinking right?  If so, what are the decision factors I should consider between these two options?


New Member

Re: DMVPN: HUB Redundancy

With a single cloud you only need one mGRE tunnel interface on the spoke with dual hubs you need to allocate an additional netspace for your second tunnel interface on your spoke and your routing may become more complex to setup. You must prevent route leaking on the spoke then.

So for simple hub redundancy I would recommend to use single cloud dual hub with single mGRE tunnel interface on the spoke first.

I summary it all depends how much redundancy you need to build and if you like to utilize mutliple internet facing interfaces as example.

Hope this helps,


New Member

Re: DMVPN: HUB Redundancy

quote "You must prevent route leaking on the spoke then"

Thanks for the info.

May I ask what is 'route leaking' and how this applies in dual DMVPN clouds setup?

quote "it all depends how much redundancy you need to build"

Under the single cloud two HUB routers with NHRP, what kind of disadvantages/weakness I would have comparing to dual DMVPN setup?


New Member

Re: DMVPN: HUB Redundancy

I read in the design document that dual hub single cloud is not recommended:

A dual hub-single DMVPN topology is generally not recommended because it relies on mechanisms outside of the tunnel to determine the appropriate hub for failover.


Although this is a valid topology option, Cisco does not recommend this topology and it is not discussed in detail in this document. For spoke-to-spoke deployment model requirements, Cisco recommends a dual DMVPN cloud topology.

I just can't see why Cisco discourages the use of a dual hub single cloud topology.

I thought of using this in a large deployment with BGP. Each spoke should have a primary and secondary hub, and there can be more than two hubs. I do however have MPLS clouds to tie together the hubs.

My idea was to use a /16 subnet for the DMVPN cloud with x numbers of hubs different places in the world and use BGP Confederations between each hub and the spoke routers.

Any thoughts of this idea and perhaps a reason why you shouldn't use a single cloud?

Thank you.


Cisco Employee

Re: DMVPN: HUB Redundancy


There's no real 'weakness' of dual hub-single dmvpn vs dual-hub dual dmvpn.  The only real issue with dual hub-single dmvpn is that it makes it harder to have the spoke differentiate which hub to send the traffic to, ie:

If hub1 and hub2 are reachable over the same interface, and are advertising the same route - you can't use the link or interface differences to differentiate which traffic goes to which hub.  With 2 tunnel interfaces in a dual dmvpn-dual hub scenario, it's easy to use something on the spoke ('delay' is popular when using EIGRP - simply set the delay on one tunnel to be lower then the other to have routes learned over that interface preffered.)

You may want to take a look at this document;

It goes over some of those considerations.

New Member

Re: DMVPN: HUB Redundancy

Thank you for the answer...

Say I implement dual hub dual dmvpn... How to I ensure that a spoke will keep routing spoke-to-spoke if the primary tunnel interface does down on the spoke? I've read that you can use a nhs on the hubs to register the nhrp mappings on each other, but with two seperate subnets I can't see how that's possible?



CreatePlease to create content