Dynamic Multipoint Virtual Private Network (DMVPN)

Abstract

A Dynamic Multipoint Virtual Private Network (DMVPN) can be used with other networks like Multiprotocol Label Switching (MPLS), but streaming multicast is accomplished quite well using "Default" and "Data" Multicast Distribution Trees (MDTs) with MPLS.

Sample

Before implementing a Dynamic Multipoint Virtual Private Network (DMVPN) as a hub and spoke solution, or streaming multicast with a DMVPN, an explanation of DMVPN may be in order for many of us trying to implement this solution. All examples of VPNs in this paper cross the public Internet. DMVPNs could be used with other networks like Multiprotocol Label Switching (MPLS), but streaming multicast is accomplished quite well using "Default" and "Data" Multicast Distribution Trees (MDTs) with MPLS.

DMVPN

A DMVPN is not a protocol so there are no configuration commands that trigger it like "ip dmvpn xxxx." A DMVPN is instead a network design. This design allows remote sites/spokes in a "Hub and Spoke" or "Star" VPN router topology to connect to each other directly without sending the traffic/data packets through the Hub. In other words, it is one hop rather than two hops which is sometimes called a hairpin turn. Most of this paper will describe Phase 2 DMVPN design. Phase 3 is also available and the differences are explained at the end of this paper.

The DMVPN design is made up of the following technologies, which will be explained separately:

1. Multipoint Generic Routing Encapsulation (mGRE)

2. Next Hop Resolution Protocol (NHRP)

3. Routing protocol-EIGRP is often mentioned as a good choice

4. IP sec encryption

Background

Next Hop Resolution Protocol (NHRP) was originally used in non-broadcast multi-access networks (NBMA), like Frame-Relay and Asynchronous Transfer Mode (ATM). Devices/routers connected to an NBMA network typically are all on the same IPv4 subnet. Broadcasts and multicasts do not reach all devices like they do on an Ethernet network because legacy NBMA networks are usually Layer 2 WAN implementations with no routing inside the WAN. Without routing inside the NBMA network, spoke routers have to go through the hub router to get to another spoke as described above. This limitation could cause a bandwidth bottleneck at the hub router. One solution is to put the routers in a full mesh topology, but spoke routers would need an extensive configuration and the expense of extra virtual circuits to reach each other in one hop.

Like any NBMA configuration there needs to be a mapping either statically, like shown here, or dynamically of the IPv4 next hop address to the NBMA next hop address. The NBMA next hop address in this example is a Frame-Relay DLCI number. The above example is with only four locations. A topology of twenty routers would need a total of 190 virtual circuits and 380 map statements. A more scalable, less expensive solution is needed that also does not cause a bandwidth bottleneck at the hub router.

The solution is to have a Layer 3 inexpensive WAN like the public Internet. The Internet has routers inside the backbone that can make routing decisions. The 190 virtual circuit problems go away as Internet routers have a path to every destination. Also, the Internet routers are fully meshed or at least heavily partially meshed so two remote spoke routers likely have a better path to each other than going through a hub router. The problem is the routers connected to the Internet are likely not all on the same subnet so they do not form an NBMA and NHRP registration and discovery would not take place. Therefore, for spoke routers to connect directly to other spoke routers and provide the security necessary on the public Internet, some form of VPN tunnel configuration is needed. The 380 map statements problem would still exist as 380 VPN configurations.