Understanding Cisco Dynamic Multipoint VPN - DMVPN, mGRE, NHRP

Dynamic Multipoint VPN (DMVPN) is Cisco’s answer to the increasing demands of enterprise companies to be able to connect branch offices with head offices and between each other while keeping costs low, minimising configuration complexity and increasing flexibility.

Note: Users familair with DMVPN can also visit our article Configuring Cisco Dynamic Multipoint VPN (DMVPN) - Hub, Spokes , mGRE Protection and Routing

With DMVPN, one central router, usually placed at the head office, undertakes the role of the Hub while all other branch routers are Spokes that connect to the Hub router so the branch offices can access the company’s resources. DMVPN consists of two mainly deployment designs:

• DMVPN Hub & Spoke, used to perform headquarters-to-branch interconnections
  
• DMVPN Spoke-to-Spoke, used to perform branch-to-branch interconnections

In both cases, the Hub router is assigned a static public IP Address while the branch routers (spokes) can be assigned static or dynamic public IP addresses.

DMVPN combines multiple GRE (mGRE) Tunnels, IPSec encryption and NHRP (Next Hop Resolution Protocol) to perform its job and save the administrator the need to define multiple static crypto maps and dynamic discovery of tunnel endpoints.

NHRP is layer 2 resolution protocol and cache, much like Address Resolution Protocol (ARP) or Reverse ARP (Frame Relay).

The Hub router undertakes the role of the server while the spoke routers act as the clients. The Hub maintains a special NHRP database with the public IP Addresses of all configured spokes.

Each spoke registers its public IP address with the hub and queries the NHRP database for the public IP address of the destination spoke it needs to build a VPN tunnel.

mGRE Tunnel Interface is used to allow a single GRE interface to support multiple IPSec tunnels and helps dramatically to simplify the complexity and size of the configuration.

Following is an outline of the main differences between GRE and mGRE interfaces:

A GRE interface definition includes:

• An IP address  
• A Tunnel Source
• A Tunnel Destination
• An optional tunnel key

An mGRE interface definition includes:

• An IP address
• A Tunnel source
• A Tunnel key

It is important to note that mGRE interfaces do not have a tunnel destination. Because mGRE tunnels do not have a tunnel destination defined, they cannot be used alone.  NHRP fills this gap by telling mGRE where to send the packets.

DMVPN Benefits

DMVPN provides a number of benefits which have helped make them very popular and highly recommended. These include:

• Simplified Hub Router Configuration. No more multiple tunnel interfaces for each branch (spoke) VPN. A single mGRE, IPSec profile without any crypto access lists, is all that is required to handle all Spoke routers. No matter how many Spoke routers connect to the Hub, the Hub configuration remains constant.

• Full Support for Spoke Routers with Dynamic IP Addressing. Spoke routers can use dynamic public IP Addresses. Thanks to NHRP, Spoke routers rely on the Hub router to find the public IP Address of other Spoke routers and construct a VPN Tunnel with them.

• Dynamic Creation of Spoke-to-Spoke VPN Tunnels. Spoke routers are able to dynamically create VPN Tunnels between them as network data needs to travel from one branch to another.

• Lower Administration Costs. DMVPN simplifies greatly the WAN network topology, allowing the Administrator to deal with other more time-consuming problems. Once setup, DMVPN continues working around the clock, creating dynamic VPNs as needed and keeping every router updated on the VPN topology.

• Optional Strong Security with IPSec. Optionally, IPSecurity can be configured to provide data encryption and confidentiality. IPSec is used to secure the mGRE tunnels by encrypting the tunnel traffic using a variety of available encryption algorithms. More on GRE IPSec can be found on our Configuring P-to-P GRE VPN IPSec Tunnels article.

DMVPN Case Study - DMVPN = Configuration Reduction and Simplified Architecture

As stated, DMVPN greatly reduces the necessary configuration in a large scale VPN network by eliminating the necessity for crypto maps and other configuration requirements.

To help demonstrate the level of simplicity and dramatic reduction of administrative overhead, we’ve worked on an example from Cisco.com and made it a bit more realistic to help show how much DMVPN does really help when it comes to configuration complexity and length.

The following requirements have been calculated for a traditional VPN network of a company with a central hub and 30 remote offices. All GRE tunnels are protected using IPSec:

Before DMVPN With p-pGRE + IPSec Encryption

• Single GRE interface for each spoke

• All tunnels for each spoke (remote office) need to be predefined:
  • Use of static tunnel destination
  • Requires static addresses for spokes
  • Supports dynamic routing protocols
• Large hub configuration (HQ Router)
  • 1 interface/spoke -> 30 spokes = 30 tunnel interfaces
  • 7 lines per spoke -> 30 spokes = 210 configuration lines
  • 4 IP addresses per spoke -> 30 spokes = 120 addresses
• Addition of spokes requires changes on the hub
• Spoke-to-Spoke traffic must pass through the hub.

The diagram below shows a point-to-point GRE VPN network. All spokes connect directly to the hub using a tunnel interface. The hub router is configured with three separate tunnel interfaces, one for each spoke:

Each GRE tunnel between the hub-spoke routers is configured with its unique network ID.  For example, GRE tunnel between the HUB and Remote Office 1 could use network 10.0.0.0/30, while GRE tunnel between the HUB and Remote Office 2 could use 10.0.1.0/30 etc.

In addition, the hub router has three GRE tunnels configured, one for each spoke, making the overall configuration more complicated.  In case no routing protocol is used in our VPN network, the addition of one more spoke would mean configuration changes to all routers so that the new spoke is reachable by everyone.

Lastly, traffic between spokes in a point-to-point GRE VPN network must pass through the hub, wasting valuable bandwidth and introducing unnecessary bottlenecks.

After DMVPN With mGRE + IPSec Encryption

• One mGRE interface supports ALL spokes. Multiple mGRE interfaces are allowed, in which case each is a separate DMVPN.
• Dynamic Tunnel Destination simplifies support for dynamically addressed spokes with the use of NHTP registration and dynamic routing protocols
• Smaller hub configuration (HQ Router)
  • 1 interface for all 30 spokes = 1 tunnel interfaces
  • Configuration including NHRP for 30 spokes = 15 lines
  • 7 lines per spoke -> 30 spokes = 210 configuration lines
  • All spokes in the same subnet -> 30 spokes  = 30 addresses
• No need to touch the hub for new spokes
• Spoke-to-Spoke traffic via the hub or directly.

mGRE dramatically simplifies the overall setup and configuration of our VPN network. With mGRE, all spokes are configured with only one tunnel interface, no matter how many spokes they can connect to. All tunnel interfaces are part of the same network. In our diagram below, this is network 10.0.0.0/29.

Furthermore, spoke-to-spoke traffic no longer needs to pass through the hub router but is sent directly from one spoke to another.

It should be clear how much simpler and easier DMVPN with mGRE is when compared with IPSec VPN Crypto tunnels or point-to-point GRE.

Cisco DMVPN IOS Version Support

While DMVPN was introduced in the earlier 12.3.19T IOS versions it is highly recommended to use the latest possible IOS. This will ensure VPN stability and access to new DMVPN features found only on the latest IOS.

Summary - More DMVPN Articles

It is evident that DMVPN is not just another VPN technology but a revolution to VPN architecture design.  The flexibility, stability and easy setup it provides are second-to-none, making it pretty much the best VPN solution available these days for any type of network.

To learn how to configure a DMVPN network, you can read our Configuring Cisco Dynamic Multipoint VPN (DMVPN) - Hub, Spokes , mGRE Protection and Routing article.