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.
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?
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.)
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?
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :