Dynamic Multipoint Virtual Private Network, or DMVPN, is a Cisco technology for creating scalable and dynamic multipoint...
Generic Routing Encapsulation, or GRE, tunnels.
This is different than standard GRE tunnels or standard site-to-site VPN tunnels because a DMVPN infrastructure can provide dynamic remote sites, dynamic IPsec tunnels and a full-mesh architecture with on-demand spoke-to-spoke connectivity. One of the benefits of using DMVPN is it provides a mechanism for interior gateway protocols -- such as the Routing Information Protocol, Open Shortest Path First (OSPF) or Enhanced Interior Gateway Routing Protocol (EIGRP) -- to function between nondirectly connected devices over the public internet. Today, DMVPN Phase 3 is the most common version.
Its versatility notwithstanding, there are important factors to consider when designing a DMVPN approach. Among the most important is deciding which interior gateway protocol to use over the DMVPN cloud. Since multiple protocols are supported, it's possible to make it work regardless of which is chosen; however, there are potential issues with using OSPF instead of others.
OSPF requires care with DMVPN Phase 3
Consider this: Every router in an OSPF area has a full view of the network in its link-state database. This is one of the benefits of a link-state routing protocol, but DMVPN is so scalable -- it's often used in networks with thousands of routers -- this behavior can pose a serious problem.
Routers running OSPF over DMVPN all need to be in the same area to form neighbor relationships. This is because all spokes in the network connect to the hub on a single multipoint interface that can be assigned to only one area. Therefore, an OSPF over DMVPN design requires single-area OSPF within the DMVPN cloud.
Every time there is a network change within an OSPF area, all routers within that area must rerun the Shortest Path First algorithm to reconverge. This can be very CPU-intensive in large networks. This may not be a problem if the issue was high CPU utilization during only the initial convergence. Yet, in a large network, the topology changes often, which results in frequent reconvergence.
Many of today's larger routers can handle the CPU load associated with a large single area, but typically, those types of routers are prohibitively expensive and not used in small branch locations. The smaller routers used at spoke locations wouldn't be able to handle the strain of a large single OSPF area, causing them to crash altogether.
Summarization would fix this problem, but OSPF routes can't be summarized within a single area. Summarization is possible between areas at the area border router or autonomous system border router. Using multiple areas is how OSPF can be scaled large, as the link-state updates that notify routers to rerun SPF don't leave an area. Because DMVPN uses a single multipoint interface on the hub, this isn't an option, which is why OSPF over DMVPN Phase 3 doesn't scale well.
Some types of organizations, such as service providers, use only the biggest and most powerful routers and are, therefore, somewhat immune to the adverse effects of an extremely large, single OSPF area. In most other enterprise organizations, this isn't the case.
Making OSPF scale properly requires NSSA configuration
To make OSPF over DMVPN Phase 3 scale properly, each spoke should be configured as a Totally Not-So-Stubby Area (NSSA) to decrease the number of link-state advertisements (LSA) that propagate to spoke routers. Also, the timers used for sending and processing LSA updates can be adjusted, as well. This allows changes to be queued and SPF to be run in predefined intervals. When using DMVPN in Phase 2, there are also settings that must be configured to control the election of the designated router and backup designated router; however, DMVPN Phase 2 is considered somewhat legacy and isn't as common as Phase 3.
Among the interior gateway protocols, a distance vector protocol like EIGRP is a better option to use over DMVPN. EIGRP allows for arbitrary summarization, or in other words, the ability to summarize and filter at any point in the network. Stub routing can be configured on each spoke, further reducing load on CPUs, but this isn't necessary if simplicity is important. Routers running EIGRP don't need to know about the overall topology -- only directly connected neighbors. The design is simpler, and by default, topology-change notifications don't flood the entire network.
For example, picture a global company with 3,000 locations throughout the world. Some sites are large, with a few thousand end users and redundant, high-quality internet connections. However, some sites are small and located in remote locations where the best internet connection available is a flaky T1. This isn't at all hypothetical. This is common among large organizations with sites located in emerging countries.
In this design, all DMVPN spokes register with the DMVPN hub locations -- for example, one in New York and one in London. Additionally, spokes have dynamically created on-demand spoke-to-spoke connectivity. With 3,000 locations around the world and likely tens of thousands of routes, the topology changes often, even if the changes are relatively minor. If the organization chooses to run OSPF over DMVPN using default OSPF settings, whenever one of these changes occurs, all 3,000 routers would have to rerun SPF. And this is why it's advisable to run stub or NSSA areas.
Though OSPF over DMVPN phase 3 can be configured and fine-tuned to function over a DMVPN topology, a better option is to run EIGRP and configure spokes as stubs. This eliminates configuration complexity and the risk for high CPU utilization from running SPF due to route churn. If CPU utilization is consistently high enough, it can bring down a network. OSPF is extremely popular, especially since it's an open standard. An exterior gateway protocol, such as the Border Gateway Protocol, is also a good option for very large deployments, but when choosing an IGP for use over a DMVPN infrastructure, using a vector protocol such as EIGRP is best practice.
The emerging role of segment routing in next-gen networks
IPV6 and the future of routing
Understanding link-state advertisements and OSPF