I am working on setting up a “Dual DMVPN Cloud Topology—Spoke-to-Spoke Deployment Model”. Using the references below.
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPNbk.pdf Page 26
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_white_paper09186a008018983e.shtml#dualhubs
Dual Hub - Dual DMVPN Layout
The dual hub with dual DMVPN layout is slightly more difficult to set up, but it does give you better control of the routing across the DMVPN. The idea is to have a two separate DMVPN "clouds". Each hub (two in this case) is connected to one DMVPN subnet ("cloud") and the spokes are connected to both DMVPN subnets ("clouds"). Since the spoke routers are routing neighbors with both hub routers over the two GRE tunnel interfaces, you can use interface configuration differences (such as bandwidth, cost and delay) to modify the dynamic routing protocol metrics to prefer one hub over the other hub when they are both up.
Note: The above issue is usually only relevant if the hub routers are co-located. When they are not co-located, normal dynamic routing will likely end up preferring the correct hub router, even if the destination network can be reached via either hub router.
See my topology diagram below, I am running ospf and my hubs are not co-located:
The problem I have is hub 1 depends on a spoke in order to communicate with hub 2. A possible solution to the problem would be to modify the DMVPN as shown below. I could make hub 2 another spoke on tunnel1. This would allow the hubs to communicate directly without having to depend on a spoke. If the ospf cost on tunnel 2 is increased on both Hub2 and the spokes, then tunnel 2 would only be used as backup in the event that hub1 is down. See diagram below.
I am not sure if this is the best way to do it as did not find any specific Cisco design recommendations for dual cloud dual non-co-located hubs. As I understand things, it seems Cisco recommends the dual cloud design for co-located dual hubs. In this scenario it seems that having a single DMVPN cloud with the spokes having nhrp statements pointing to both hubs makes more sense. Any thoughts?
A similar question with no answer is posted here. https://supportforums.cisco.com/message/1002120#1002120
Thats a good question. I am not sure what dual cloud solves in this scenario with non-co-located hubs. I want to have redundancy such that if one spoke fails, all other spokes can continue to communicate. The main reason I was going with dual cloud is that it is Cisco recommended.
If I did a p2p GRE tunnel between the hubs instead of making hub 2 another spoke on tunnel 1 it would look like this.
The one downside is additional configuration with a another tunnel at each site, but with this I wouldn't need to adjust the cost on tunnel 1 and each spoke would use the the hubs respective tunnel to communicate with it, (tunnel 1 for hub1 and tunnel2 for hub 2) without the dynamic tunnels forming between the spokes and hub2 as in my second diagram above.
FlexVPN looks cool, but not all of our routers are 2nd generation ISRs.
Thats a good question. I am not sure what dual cloud solves in this scenario with non-co-located hubs. I want to have redundancy such that if one spoke fails, all other spokes can continue to communicate. The main reason I was going with dual cloud is that it is Cisco recommended.
If I did a p2p GRE tunnel between the hubs instead of making hub 2 another spoke
FlexVPN looks cool, but not all of our routers are 2nd generation ISRs.Thats a good question. I am not sure what dual cloud solves in this scenario with non-co-located hubs. I want to have redundancy such that if one spoke fails, all other spokes can continue to communicate. The main reason I was going with dual cloud is that it is Cisco recommended.
If I did a p2p GRE tunnel between the hubs instead of making hub 2 another spoke
FlexVPN looks cool, but not all of our routers are 2nd generation ISRs.
