DMVPN-Dynamic Multipoint VPN-High Level Overview

DMVPN (dynamic multipoint virtual private network) is a design approach that allows full mesh connectivity with the use of multipoint GRE tunnels. DMVPN itself is not a protocol but rather it is a design approach.

The router at the HeadQuarter undertakes the role of a Hub while branch routers take the role of Spokes. In this Hub-and-Spoke topology, each Branch can access some resources on the HeadQuarter. But there are some disadvantages with this topology:

When a spoke wants to communicate with another Spoke, it must go through the Hub which increases the traffic passing through the Hub, increase CPU and memory usage on Hub and can create bottle-neck problem.

Each site requires a static public IP address if the environment between them are public (like the Internet).

The configuration is complex, especially with large network. When a new Spoke is added, additional configuration is required on Hub

Dynamic Multipoint VPN (DMVPN) is a solution of Cisco that can be used to overcome these disadvantages.

DMVPN provides the following advantages:

• Provides full meshed connectivity with simple Hub-and-Spoke topology. The spokes can communicate between each other without going through Hub
• Only one static public IP address is required on Hub. Spokes can use dynamic (unknown) public IP addresses
• The configuration is simple even in large network. No additional configuration is required on Hub when new Spokes are added.

DMVPN is the combination of the following technologies:

• Multipoint GRE (mGRE)
• Next-Hop Resolution Protocol (NHRP)
• Dynamic Routing Protocol (EIGRP, RIP, OSPF, BGP…) (optional)
• Dynamic IPsec encryption (optional)

Multipoint GRE (mGRE):

An mGRE tunnel inherits the concept of a classic GRE tunnel but an mGRE tunnel does not require a unique tunnel interface for each connection between Hub and spoke like traditional GRE. One mGRE can handle multiple GRE tunnels at the other ends. Unlike classic GRE tunnels, the tunnel destination for a mGRE tunnel does not have to be configured; and all tunnels on Spokes connecting to mGRE interface of the Hub can use the same subnet.

Next-Hop Resolution Protocol (NHRP):

NHRP is a resolution protocol that behaves like ARP. In an NHRP environment, there are two roles, the NHS (next-hop server) and the NHC (next-hop client). The NHCs register themselves with the NHS and provide information, such as their logical VPN IP addresses and the physical NBMA mapping. The NHCs also request information from the NHS about how to reach the other NHCs by learning the logical IP to NBMA mapping information. 

• When a Spoke joins a DMVPN network, it sends a Registration Request to the Hub whose IP address has already been configured on the Spoke (via the “ip nhrp nhs <Hub IP address>” command)
• The Registration Request contains the Spoke’s Tunnel and NBMA addresses along with the hold time -> Hub does not have to statically configure Spoke IP -> simplify Hub configuration
• Hub then create an NHRP mapping entry in its NHRP cache (just like an ARP cache) to keep the mapping between Spoke’s Tunnel and NBMA addresses. The hold time of this mapping equals to the hold time in the Registration Request.
• Hub sends a NHRP Registration Reply to the Spoke to complete the process.

A cool advantage of NHRP is the ability to help DMVPN establish direct Spoke-to-Spoke communication without going through Hub. Let’s see how NHRP works in this case.

1. Before a spoke-1 can directly send traffic to another spoke-1, it must still query the Hub to get the NBMA address of the destination spok2. To do this, Spoke-1 must send a NHRP Resolution Request to the Hub asking for the NBMA address of the destination spoke-2.

2. The Hub replies with the NBMA (public) address of Spoke 2.

3. The direct tunnel between two spokes is built only after that. But the spoke-to-spoke tunnel is only temporary and is torn down after a pre-configured period of inactivity to save resources.

Additional Information:

why we have to run GRE on DMVPN ?

The answer is because we want to run IPSec on it. And why we need IPSec? Because we want to utilize the power of cheap but insecure Internet (and other insecure public) connections at our sites.

mGRE tunnel is treated as a non-broadcast multi-access (NBMA) environment. mGRE tunnel does not have to be configured with a tunnel destination so we need another protocol to take care of the destination addresses. In this case NHRP is used for NBMA environment.

Besides the Tunnel IP address, each Spoke and Hub will have a NBMA IP address, which is a public IP address used as the tunnel source IP address.