cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2379
Views
0
Helpful
3
Replies

DMVPN - Dual Cloud, Dual non-co-located Hub Design Advice

Andrew Bailey
Level 1
Level 1

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:Drawing2.gif

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.

Drawing1.gif

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

3 Replies 3

Marcin Latosiewicz
Cisco Employee
Cisco Employee

Andrew,

First of all you need to ask yourself what sort of problem am I trying to solve by using dual cloud.

Separating routing/NHRP domains? Some specific fallback scenario?

Truth be told you can simulate co-location by using a simple p2p GRE tunnel (with IPsec protection if needed) it does not have to be, nor does it make sense in some scenarios to be, a mGRE tunnel.

I, personally, find dual cloud design a bit cleaner (and allows more possibility to grow/change/adapt) but harder to deploy (managing more routing and address spaces).

M.

P.S.

look into FlexVPN, it's using same family of technologies as DMVPN, but is more flexible.

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.

Andy,

I'm not sure what you have there for the moment, but we typically recommend BGP for routing, you could do pretty cool stuff with it, the obvious drawback is that BGP is not so plug and play and have a bit longer timers than, say, EIGRP.

OSPF in DMVPN, there are a lot of pitfalls, and only recently we managed to introduce defaults which address some of common misconfigurations (e.g. we no longer "route" NHRP registration)

M.