Most of the DMVPN-related questions I get are a variant of the “how many tunnels/hubs/interfaces/areas do I need for a redundant DMVPN design?” As always, the right answer is “it depends” (and I can always help you with your design if you’d like to get a second opinion), but here’s what I’ve learned so far.
Single router/single uplink on spoke site
This blog post focuses on the simplest possible design – each spoke site has a single router and a single uplink. There’s no redundancy at the spokes, which might be an acceptable tradeoff (or you could use 3G connection as a backup for DMVPN).
You’d probably want to have two hub routers (preferably with independent uplinks), which brings us to the fundamental question: “do we need one or two DMVPN clouds?”
Design#1 – one hub per DMVPN tunnel
In this design, each hub router controls its own DMVPN subnet, and spoke routers have multiple tunnel interfaces (one per hub). Each hub router is the NHRP server for the subnet it controls, and propagates routing information between spokes.
This design is by far the simplest, cleanest, and easiest to understand/troubleshoot – it has no intricate dependencies between routing protocols and NHRP. You can also easily deploy primary/backup hub router scenarios by increasing the interface cost of one tunnel interface, or you could load-share the traffic between both hub routers.
And now for the drawbacks:
- Multiple IPsec sessions could be established between a pair of spoke routers in DMVPN Phase 2 deployments (one over each tunnel interface);
- GRE keys are mandatory in Phase 2 deployments (otherwise the spokes cannot decipher which tunnel the other spoke router was using), causing performance degradation if the hub routers don’t support GRE keys in hardware (Catalyst 6500 doesn’t)
- This design does not work with large-scale Phase 3 DMVPNs where you want each spoke to connect to a subset of hubs (you cannot establish Phase 2/3 shortcuts across DMVPN tunnels, only within a tunnel).
Design#2 – multiple hubs in a single DMVPN tunnel
In this design, you connect all hub routers to the same DMVPN tunnel. All hub routers act as NHRP servers, and propagate routing information between the spokes (if you use OSPF, one of the hub routers would become a DR, another one a BDR).
Phase 1 DMVPN using multiple hub routers per tunnel is pretty easy to design/deploy – NHRP is used solely to register spokes with all the hubs, and the convergence is controlled by the routing protocols. Implementing primary/backup hub routers is a tricky task; you have to use routing protocol tricks like per-neighbor cost in OSPF or per-interface offset lists with EIGRP.
Phase 2/3 DMVPN designs with multiple hub routers per tunnel could experience severe convergence issues – detecting failure of a hub router could take as long as three minutes. On the benefits side, this design does not require GRE keys (which is good news if your hub router is a Catalyst 6500) or multiple IPsec sessions between spoke routers.
- One hub router per DMVPN subnet is the ideal design for Phase 2 DMVPN deployments ... unless you have Catalyst 6500 as your hub router, in which case you must use one DMVPN subnet due to lack of hardware GRE key support.
- You could use both designs with Phase 1 DMVPN; one hub router per subnet is a better alternative if you have primary/backup hub router requirements.
- One DMVPN subnet is probably the best design for Phase 3 DMVPN and it’s mandatory if you have partial spoke-to-hub NHRP connectivity.
I need to run a few more convergence tests before fully embracing one DMVPN subnet design as the best one in all Phase 3 DMVPN scenarios.
Coming next: spoke routers with multiple uplinks and spoke sites with redundant routers.
Start with the DMVPN – from basics to scalable networks webinar; it probably contains 95% of what you need to know about DMVPN (the DMVPN New Features one describes DMVPN features introduced in IOS releases 15.x).