As organizations scale and connect more branches via the internet, traditional site-to-site VPNs quickly become cumbersome to manage. Each additional site introduces more tunnels and complexity, making the network difficult to scale and troubleshoot. DMVPN (Dynamic Multipoint VPN) solves this problem by providing a dynamic and scalable VPN infrastructure, particularly well-suited for environments with many branch offices.

In DMVPN, the architecture is based on hubs and spokes. The hub acts as the central server, while the spokes are clients. When a spoke boots up, it establishes a static tunnel to the hub. Later, if one speaker wants to communicate with another, a dynamic tunnel is automatically built between them, avoiding the need to route traffic through the hub once initial discovery and registration are done.

Understanding Phase 1: Static Hub-and-Spoke

DMVPN Phase 1 implements a strict hub-and-spoke model. In this phase, all traffic between spokes must traverse the hub. Even if Spoke A wants to communicate with Spoke B, the data path is Spoke A → Hub → Spoke B. The hub performs a route lookup and forwards traffic to the correct spoke.

This setup offers tight control over routing and traffic policy, as all communication is funneled through the hub. However, it comes with a major drawback: the hub becomes a bottleneck, especially in environments with high inter-branch communication, leading to suboptimal routing.

Phase 1 Configuration Details

Hub Configuration

At the hub (e.g., router R1), the tunnel interface must meet three critical criteria.

1. It must have an IP address:

interface tunnel0
ip address 172.16.1.1 255.255.255.0

2. It must have a tunnel source:

tunnel source f0/0

3. It must use multipoint GRE:

tunnel mode gre multipoint

Because multiple routes will be learned from the same interface, split horizon can disrupt routing updates. It must be disabled:

no ip split-horizon eigrp 123

For dynamic mapping of multicast traffic (required by EIGRP or OSPF), include:

ip nhrp network-id 123
ip nhrp map multicast dynamic

To secure the tunnel, enable IPsec encryption:

tunnel protection ipsec profile DMVPN

And configure the routing protocol:

router eigrp 123
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255

Notably, the hub does not require the no ip next-hop-self eigrp command, which would break routing since the hub needs to maintain itself as the next hop.

Spoke Configuration

At the spoke (e.g., R2 or R3), the configuration is similar with some specific tweaks. First, assign a tunnel IP:

interface tunnel0
ip address 172.16.1.2 255.255.255.0

The spoke must define the tunnel source and destination:

tunnel source f0/0
tunnel destination 100.1.1.1

In Phase 1, the tunnel destination on the spoke always points to the hub. The spoke initiates the tunnel, it is always the connection starter in all DMVPN phases.

The spoke must also register with the hub using NHRP:

ip nhrp network-id 123
ip nhrp nhs 172.16.1.1
ip nhrp map 172.16.1.1 100.1.1.1

Optionally, you can add authentication:

ip nhrp authentication pass

This enables the hub to dynamically learn public-to-private IP mappings. For encryption, apply the IPsec profile:

tunnel protection ipsec profile DMVPN

And set up the routing protocol:

router eigrp 123
network 172.16.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255

Crypto Configuration for IPsec

Both hub and spoke must share consistent crypto settings. Here’s a minimal example for ISAKMP and IPsec configuration:

crypto isakmp policy 10
encryption 3des
hash md5
group 2
authentication pre-shared
exit
-
crypto isakmp key cisco123 address peer-ip
crypto ipsec transform-set TS esp-aes esp-sha-hmac
mode transport
crypto ipsec profile DMVPN
set transform-set TS
exit
-
interface tunnel0
tunnel protection ipsec profile DMVPN

The hub can either define specific keys per spoke:

crypto isakmp key cisco123 address spoke1-ip
crypto isakmp key cisco123 address spoke2-ip

Or use a wildcard (less secure):

crypto isakmp key cisco123 address 0.0.0.0

Avoid wildcards in production unless using certificates.

MTU and MSS Tuning

To optimize performance, adjust MTU and MSS on the tunnel:

interface tunnel0
ip mtu 1400
ip tcp adjust-mss 1360

Tunnel Packet Structure

When packets move through the tunnel, they’re encapsulated with a GRE header, an ESP header (for encryption), and a new IP header with the tunnel’s public destination address. This allows private network traffic to securely traverse the internet, with encapsulation handling addressing and security transparently.

This Phase 1 configuration lays the foundation for more advanced DMVPN designs. While simple and centralized, it introduces some routing inefficiencies that Phase 2 and 3 aim to address by enabling direct spoke-to-spoke communication.