Dynamic Multipoint VPN (DMVPN) is a Cisco technology designed to simplify the creation and management of scalable VPNs by dynamically building tunnels between sites. One of the foundational components of DMVPN is Multipoint GRE (MGRE). MGRE enables a router to create a single GRE tunnel interface that can support multiple destinations, making it significantly more scalable than traditional point-to-point GRE tunnels.
Under the hood, DMVPN relies on the Next Hop Resolution Protocol (NHRP). This protocol functions much like ARP for tunnels, mapping a tunnel IP to its associated physical/public IP so that packets can be forwarded to the correct endpoint.
Basic MGRE Configuration
To configure a basic MGRE tunnel, start with the following on your router:
interface tunnel 1 ip address x.x.x.x mask tunnel source interface tunnel mode gre multipoint ip nhrp network-id num ip nhrp map tunnel-ip1 public-ip1 ip nhrp map tunnel-ip2 public-ip2
The key command here is tunnel mode gre multipoint, which transforms a standard tunnel into a multipoint GRE tunnel. The ip nhrp network-id activates NHRP on that tunnel, assigning a locally significant ID, similar to a process ID in routing protocols. Each ip nhrp map statement is a manual mapping between a peer’s tunnel IP and its public IP.
However, this method quickly becomes unmanageable. Every site requires a static IP and a corresponding ip nhrp map entry at every other site, making it difficult to scale. Every time a new site is added, all other routers need to be updated, clearly not ideal for dynamic environments.
Configuring DMVPN with an NHS
The NHS and spoke sites share a similar base configuration with a few key distinctions.
NHS Configuration:
interface tunnel 1 ip address x.x.x.x mask tunnel source interface tunnel mode gre multipoint ip nhrp network-id num
Spoke Configuration:
interface tunnel 1 ip address x.x.x.x mask tunnel source interface tunnel mode gre multipoint ip nhrp network-id num ip nhrp nhs NHS-tunnel-ip ip nhrp map NHS-tunnel-ip NHS-public-ip
Here, the ip nhrp nhs statement identifies the NHS router, and the ip nhrp map ensures the spoke knows how to reach it.
Supporting Multicast and Routing Protocols
Multicast traffic (required by dynamic routing protocols like EIGRP and OSPF) also needs special attention in DMVPN. By default, multicast packets can’t travel across GRE tunnels without being explicitly mapped. To enable multicast across the DMVPN cloud, you can add the following:
On the NHS:
ip nhrp map multicast dynamic
On the Spoke:
ip nhrp map multicast NHS-tunnel-ip
This ensures multicast packets are sent to the NHS, which will then replicate them to other dynamic endpoints as necessary.
Split Horizon Considerations
In a typical hub-and-spoke DMVPN design, split horizon can interfere with routing updates. For example, if EIGRP is being used, the NHS (hub) may receive updates from one spoke but won’t advertise them to other spokes due to split horizon rules. To resolve this, you must disable split horizon on the NHS’s tunnel interface:
no ip split-horizon eigrp 100
This allows the NHS to forward routing updates between spokes, effectively enabling full mesh communication where required.
This configuration gives you a dynamic, scalable VPN solution suitable for branch office connectivity and dynamic routing environments. DMVPN’s ability to dynamically build tunnels and use NHRP for next-hop resolution dramatically reduces administrative overhead, while features like multicast support and split-horizon mitigation make it suitable for modern routing protocols.
