DMVPN stands for Dynamic Multipoint VPN and it is a dynamic tunneling form of a virtual private network (VPN). It represents an effective solution for dynamic secure overlay networks by forming a partial dynamic mesh network. Okay ! That’s a lot of ‘dynamic” but let’s move on.

In this post, I will show you the combination of different technologies used in a DMVPN scenario. We will also talk about the different DMVPN phases and their purposes. We will be using the following topology which represent a Single DMVPN solution or Single Tier Headend Architecture…

DMVPN is combination of the following technologies:

Multipoint GRE (mGRE)
Next-Hop Resolution Protocol (NHRP)
Dynamic Routing Protocol (EIGRP, RIP, OSPF, BGP)
Dynamic IPsec encryption (Optional)
Cisco Express Forwarding (CEF)

If you are unfamiliar with mGRE, I would suggest to read the post about GRE first.

At this point, I’m assuming you have a basic knowledge of GRE tunnels. From that perspective, let’s discuss the different technologies that add up to DMVPN. Let’s start with mGRE.

*mGRE differs from your traditional GRE setup in a sense where mGRE can actually have multiple destinations. It operates in a Non-Broadcast Multi-Access Network with dynamic tunnel destination and supports multicast and broadcast.

*NHRP is the key ingredient that makes DMVPN dynamic. How ? Well, it is layer 2 resolution protocol and cache mechanism similar to ARP (Address Resolution Protocol) in a sense that the hub router (Server) maintains a NHRP database compiled with NBMA addresses (WAN Interfaces Addresses) of all configured spokes (Clients). Each spoke needs to register its NBMA address with the server (Hub) and if a Spoke-to-Spoke connection needs to be established, the initiator queries the NHRP database for the peer NBMA address it needs to dynamically build a VPN tunnel with. It is also used to map a tunnel IP address to a NBMA address. Note that NHRP can have static and dynamic entries. One important aspect to remember is that since mGRE tunnels do not have a tunnel destination defined, they can not be used alone; NHRP tells mGRE where to send the packets to.

Let’s dive into the consoles so we can see the above in action. We will be using EIGRP as our IGP and as we move forward with the configuration, I’ll point out the different DMVPN phases…

At this point, we have similar configurations on all routers except for the IP addresses. Refer to the diagram for interface IPs.

We have our NBMPA addresses in, let’s start with the hub router…

Have you noticed anything different here ? There is no “Tunnel destination” command and instead you have the “Tunnel mode gre multipoint” command which classify this specific tunnel as a multipoint GRE tunnel.

Running a dynamic routing protocol across your DMVPN infrastructure is not necessary a technical requirement but you can imagine how unbearable it could be and the amount of management overhead it would add to the whole picture. It just does not scale ! In that sense, running a dynamic routing protocol across your DMVPN network is morally a must. When we are talking about IGPs, we are then talking about Multicast right ?. Well, that’s what the command “ip nhrp map multicast dynamic” does for us. It allows the forwarding of multicast packets to dynamic spokes. If you don’t have it configured here on the hub, your adjacency will not form.

The “ip nhrp network-id 100” identifies the DMVPN cloud. Note that all routers (Hub or Spoke) must have the same Network ID. This is useful when we talk about more advanced design such as DUAL DMVPN – Single Tier Architecture where you have 2 hub routers and 2 distinct DMVPN network.

The “ip nhrp authentication RT-Leak” command sets the a password for NHRP queries. Here we have set our password to “RT-Leak”.

Let’s now configure our spoke routers…

The command “ip nhrp map 172.16.1.1 210.1.1.1” simply maps the NHS (Next Hop Server) address which is the tunnel interface address to the NBMA (Non-broadcast multiple-access) address which is the WAN interface IP address.

The command “ip nhrp map multicast 210.1.1.1” instructs the spoke routers to send multicast traffic to the hub router only.

The command “ip nhrp nhs 172.16.1.1” basically informs the spoke router the whereabouts of the NHS (Next Hop Server) router which is the Hub router.

Note that the same configuration needs to be applied on the 2nd spoke router. Let’s do that…

At this point, our tunnel’s line status and protocol should be up. Let’s verify…

Our hub router is looking solid. Let’s check the spokes…

All right ! We are looking good. Note that this is the most basic configuration you can have to build a DMVPN network. Depending on your SLA requirements, you can tweak it to accommodate your network. I will show you how to validate functionality of your DMVPN network at the end of this post but for now let’s configure the Loopback addresses and EIGRP…

Nice ! Let’s check the Spokes…

All right ! Now is the time to talk about the different DMVPN phases. Let’s start with Phase 1…

Noticed here how we advertised the correct networks into EIGRP. Also noticed how the NBMA prefix is not advertised in EIGRP and that’s because we want to avoid recursive routing. I’ve talked about recursive routing in the GRE post. The command “no ip split-horizon eigrp 100” needs to be disabled as EIGRP is a distance vector protocol. EIGRP by default has “Split-Horizon” enabled and what it means is simply not to relay advertisement back out of the interface which it was received.

In a nutshell, this constitutes DMVPN Phase 1 in rapport with EIGRP and the limitations are as followed:
-Spoke to Spoke traffic always transits via the Hub
-Summary address is not supported in this Phase

Let’s move forward with Phase 2…

This is the only command needed for Phase 2 in addition with the commands for Phase 1 of course. In this phase, Spoke to Spoke tunneling is allowed. What does it mean ? Well, that means all spokes need to receive full routing information from its peer but the problem is that by default, EIGRP sends updates with the Next Hop Address embedded in the header. Let’s say the Hub router sends an update to Spoke 1; Spoke 1 will then receive the update and populate its routing table with the Hub router as the next hop for the addresses it received. Then in that case, Spoke to Spoke tunneling would not be possible because the next hop would be the Hub ! That’s why we have to specify the “no ip next-hop-self eigrp” command to send those updates with the next-hop unchanged. Note that this is only true for EIGRP.

All right ! In resume, here are what we have with Phase 2:
-Spoke to Spoke traffic does not transit via the Hub
-It requires the Hub router to advertise prefixes from Spokes to other Spokes along with the Spokes Next Hop IP Address
-This phases does not support summary address
-This phases relies on process switching

Let’s move forward with Phase 3…

Noticed how the command “ip nhrp redirect” is configured on the hub router (Tunnel Interface) ? Let’s see what we have on the Spoke routers…

Noticed here on the Spoke routers the command “ip nhrp shortcut” ? Let me elaborate…

All right ! Phase 3 and Phase 2 are somehow similar in a sense where Spoke to Spoke tunneling is allowed but there are much more to this phase than usual.

The command “ip nhrp redirect” is more or so similar to IP ICMP redirect messages. When a IP Packet is received inbound on the mGRE tunnel interface and switched out of the same interface, a “nhrp redirect message” is embeded in the frame with the goal of informing the source of the packet that it is currently using a suboptimal path to reach the destination and that it should look for a better path.

The originator now receives the message and queries the destination IP by traversing the hub. The Spoke now responds to the NHRP querie and forward the NBMA address back to the originator but this time, traffic flow does not include the hub as a hop; it rather establish a session directly with the originator. Remember this could not be done with the previous phases as the hub is no longer the only source of NHRP information. Note that in this phase, NHRP replies carry routing information rather than just next hop information. Summarization is also possible at this level !

Let’s now see the variation of commands in our troubleshooting toolset we can use to make sure we are in fact golden…

The “show dmvpn” command gives us useful information related to the state of the infrastructure. Here, we can see that we are in fact peering with the Spokes as the state is “UP” and we can observe the NBMA and NHS addresses. I want to show you shomething… Note that we are running Phase 3 as of this moment.

Noticed how the first traceroute from RouteLeak-RM2 to RouteLeak-RM1 traversed the hub but the second traceroute did not ? That’s because a Spoke to Spoke tunnel has now been dynamically built between the two Spokes. Let’s verify…

The command “sh ip nhrp” also gives us very useful information and should be added in our troubleshooting toolkit. Note that you can clear a DMVPN session by using the command “clear dmvpn session ?”.

Note that at this point, the DMVPN network is fully functional but the caveat is that traffic is not encrypted at this point. No Confidentiality ! No Integrity ! It is best practice to encrypt your traffic when configuring DMVPN. If you would like to learn about configuring IPSec for encryption purposes, please take the time to read about the post here.

You can download the GNS3 file pertaining to this lab here.

That’s all I have for you today… I’ll talk to you guys later.