What is a Dynamic Multipoint Virtual Private Network (DMVPN)?

Dynamic Multipoint Virtual Private Network is a technique that enables the data to transfer between multiple sites, without having to statically configure all the devices. It is an effective solution for a dynamic secure overlay network. It is a hub and spoke network where the spokes directly communicate with each other by creating a dynamic IPSEC tunnel without having to go through the hub.

The Need For Dynamic Multipoint Virtual Private Network (DMVPN)

Let us consider an example, for instance, a company has 200 branch locations that are connected to the head office. Without DMVPN, we have to configure 200 point-to-point GRE tunnel interfaces on Head office router, with each interface requiring at least seven lines of configuration code, therefore a total of 1400 lines of code on the Head office router, plus configuring each branch office router. The new addition of the branch office needs to configure an additional tunnel interface on the Head office router.

The DMVPN requires only one interface configuration on the Head office router to connect 200 branch offices with fifteen lines of code. The new branch office addition doesn’t require any change in the configuration of the Head office router.

The direct spoke-to-spoke VPN deployment provides a number of benefits over the normal VPN deployments, such as:

• Direct spoke-to-spoke traffic flow.
• Eliminates additional bandwidth requirements at the hub.
• Eliminate additional network delays.
• Conserve WAN
• They lower capital and operational expenses
• They increase resiliency and redundancy.
• Simplifies branch communications.

How Does A Dynamic Multipoint Virtual Private Network (DMVPN) Work?

DMVPN is a combination of the following technologies.

• Multipoint GRE (mGRE)
• Next-Hop Resolution Protocol (NHRP)
• Dynamic Routing Protocol (EIGRP,RIP,OSPF,BGP) to learn network between hub and spokes
• Dynamic IPSEC encryption

Multipoint GRE

Let us start with the basic building component of DMVPN – multipoint GRE (mGRE). mGRE tunnel interface is used to allow a single GRE interface to support multiple IPSec tunnels and helps to simplify the complexity and size of the configuration.

Our regular GRE tunnels are point-to-point and not suitable for scalable cases. Let us consider the following scenario. Our head office is in Cochin and our branch offices Chennai and TVM are connected to the Cochin office. Suppose if Chennai and TVM offices require to communicate with each other, we have to statically configure the tunnel between Chennai to Cochin, TVM to Cochin and Chennai to TVM. For each tunnel creation, we have to configure each tunnel interface. This static tunnel configuration is not a suitable method if we have a number of branch offices.

For the complex scalable networks, we can use mGRE tunnels. mGRE uses a single interface to connect multiple tunnels. Here all the branch offices will be connected to the Head office using a single mGRE interface.

Each branch office can directly communicate using Dynamic GRE tunnel creation between each other.

Let us consider an example. Branch1 wants to tunnel something to Branch2, for that Branch1 needs Branch2’s public IP address. NHRP is used for this situation.

Next-Hop Resolution Protocol

Now we can move to NHRP – the component makes DMVPN truly dynamic. NHRP is a resolution protocol similar to ARP and RARP. Here the Hub router will act as the server and the spoke routers will act as the clients. The Hub router will maintain a special NHRP database with the public IP addresses of all the registered spokes. Each spoke router registers its public IP address with the Hub router and queries the NHRP database for the public IP address of the destination spoke it needs to build a VPN tunnel.
The spoke1 will establish a tunnel with Hub and registers its public IP address 2.2.2.2 using the NHRP registration request. Spoke2 also registers its public IP address 3.3.3.3 in a similar way.

Now the Hub will have 2 spoke routers and save their public IP addresses into Hub router’s NHRP cache.
Spoke1 wants to send something to Spoke2, for that they need the public IP address of Spoke2. Spoke1 will query the Hub router using the NHRP resolution request. The hub router will check its NHRP cache for the public IP address of Spoke2 and reply back to spoke1 using the NHRP resolution reply. Now the Spoke1 knows the public IP address of Spoke2 and they can communicate with them directly.

IPSEC

Up to this point, the tunnels have been created as a clear text for the sake of simplicity, but in the real world, we probably want to include IPsec encryption to protect tunnels traversing an untrusted path. Fortunately, this is as simple as applying an IPsec protection policy to the tunnel interface on each router. IPsec Protocol is also known as IKE and ISAKMP, which create a unique strategy to design steps that facilitate privacy controls and make sure the authentic information to be transferred from one end to another among all the peers in the network.

DMVPN Design

We can use DMVPN in three different ways. These are called phases.
• Phase 1
• Phase 2
• Phase 2

Phase 1

Phase 1 is the Hub-to-Spoke tunneling model. All the traffic flows through the hub. The hub is used for the control plane of the network and is also used in the data plane path. Phase 1 was the original implementation of DMVPN.
Spokes will use NHRP so that spokes can register themselves with the hub. The hub router builds an mGRE tunnel to connect to all the spokes. Each spoke builds a regular point-to-point GRE tunnel, and will only connect to the hub. This means that there will be no direct spoke-to-spoke communication, all traffic has to go through the hub!
Since our traffic has to go through the hub, our routing configuration will be quite simple. Spoke routers only need a summary or default route to the hub to reach other spoke routers.

Phase 2

Phase 2 is the Spoke-to-Spoke tunneling model. Spoke-to-spoke communication does not need the hub in the actual data plane. Spoke-to-spoke tunnels are on-demand based on spoke traffic triggering the tunnel. This phase involves every spoke being configured with mGRE interface so you get your dynamic spoke-to-spoke connectivity, no more static tunnel destinations will be configured. There are two restrictions in phase 2:
1. Spoke routers need to have a route for the network that they are trying to reach.
2. The next-hop IP address of the route has to be the remote spoke.
The route summarization and default routing are not possible in Phase 2.

Phase 3

Phase 3 overcomes the restrictions in phase 2. In phase 3 the spoke routers no longer need specific routes to reach remote spokes and don’t matter what the next-hop IP address is. The configuration of ‘ip nhrp redirect’ on the hub and ‘ip nhrp shortcut’ on spokes take care of traffic flows.

Initially, the traffic will forward to the hub and hub will send NHRP to redirect to both spokes that are source spoke and destination spoke. Both the spokes send NHRP resolution request to a hub to figure out each other’s NBMA IP address. Hub router reply back with requested public IP addresses. The spoke routers then install a new entry in their routing table so that they can reach each other directly.

DMVPN Services from ThinkPalm Technologies can help you transform the branch experience and accelerate business innovation and growth, Contact us to learn more about DMVPN and it’s implementations.

Author Bio

Nikhila M T is a Senior Software Engineer at ThinkPalm Technologies. With 5 years of experience in the Datacom Domain. She is always passionate about learning new technologies. Her hobbies are drawing and cooking.