The setup

In my previous post, I explained the building blocks of a DMVPN Phase 2 tunnel. DMVPN has three phases, differentiated in the way spoke-to-spoke traffic is handled:

  • Phase 1: route all traffic through the hub
  • Phase 2: Have the spoke as a next hop in your routing table for every spoke network. When you need to know where the spoke is, ask the hub and set up a spoke to spoke tunnel.
  • Phase 3: Route all traffic through the hub. If the hub notices traffic is spoke-to-spoke, it will send a redirect, triggering a spoke to spoke tunnel.

This means that Phase 1 is inefficient from a forwarding perspective, Phase 2 is inefficient in it’s use of routing information, Phase 3 addresses both problems. Phase 1 and 2 are considered obsolete, but we still need to know how to configure all of them. First I will explain the difference in config on the tunnel interface, then I will explain how to handle the routing over the different phases.

Tunnel configuration

The tunnel config difference is surprisingly small:

Phase Hub Spoke
1 mGRE GRE, so it also needs a destination address
3 mGRE plus NHRP redirect & shortcut mGRE plus NHRP shortcut

So, moving from the phase 2 config to a phase 1, on the spokes you simple do:

When you want to move from phase 2 to phase 3, you have to add NHRP shortcut to all routers and NHRP redirects on the hub.



And that is all there is to it. Well, all but the hardest part: You need to adjust your routing protocol to make sure to hubs and spokes behave in accordance to the phase they are in. In the next posts, I will explain this for distance-vector protocols and for OSPF respectively.

Building a DMVPN topology, has quite a few bits of configuration on quite some devices. It can all seem a bit daunting, especially since most examples just give you the different configurations for the hubs and the spokes in one go. Iin reality, there are only a few lines that differ among the devices. There is some configuration that has to be unique on each device, some that differentiates between a hub and a spoke and the rest is the same across the board. The differences all have to do with these answering these questions:

Scope Questions
Unique per device: How do I source my packets?
Hubs only: What should I do with incoming NHRP registrations?
Spokes only: Where should I send my NHRP registrations?
All devices: How do I identify a tunnel and how should I handle my packets?

I will handle each seperately. All configuration here is done under interface tunnel NUM.

Unique per device

To answer the question how to source the packets, you need two pieces of information: A source address outside of the tunnel and a source address inside of the tunnel, so there are only two lines unique per device:

Hub config

The difference between hubs and spokes is that the hub listens for incoming tunnels. You don’t actually have to configure anything, but since we want multicast to work for routing protocols to work properly, we will tell the Hub to register multicast traffic in NHRP:

Spoke config

The spokes are the ones actually actively setting up the tunnels. So, they need to know where to send their NHRP registrations. For this, they need to know two addresses. The NBMA (hubs public IP) and the Tunnel IP of the hub. You can repeat this line to create a multi-hub topology:

Shared config

The shared config is all about identifying the tunnel, and specifying common parameters, such as ipsec profiles, MTU and timers. All parameters should match between the devices.

First, we set the type of tunnel, which is mGRE

The MTU needs to be lowered, in order to be able to fit all the tunnel overhead in the packets. mGRE costs 28 bytes. If you add IPsec in tunnel mode, this could balloon fast. The biggest I could find in the IPsec overhead calculator was a total of 152 bytes, including GRE.

Next, we have the NHRP id and password in combination with the tunnel key to identify the set of tunnels. These are just identifiers, and can be set to anything you like. The password is set plaintext, if you don’t use any encryption on IPsec.

Optionally, we can set a holdtimer for NHRP routes. Cisco recommends a value between 300 – 600.

Last, but most certainly not least, we can set the IPsec profile. Without this, the tunnels will come up, but your data will be unencrypted. The configuration of the IPsec profile is out of scope of this post, but should also be the same on all DMVPN devices.


There you have it. The only difference between the spokes and the hubs is the NHRP mapping, the only difference between all devices is the source information. At least, for a phase 2 DMVPN, which we built here. The differences between the phases will be explained in a different post.