Introduction to DMVPN

In the previous lesson, you built a single GRE tunnel between New York and San Francisco.
R1 had one Tunnel interface, linking both LANs across the Internet.

Figure 1 – One GRE tunnel, one branch

Now, your company opens two more branches: Chicago and Miami.

One Tunnel per Branch

Each branch has its own router and Internet connection.
Right now, they reach the Internet, but not New York.

Figure 2 – Two new branches, no tunnel yet

A standard GRE tunnel has one source and one destination.

To connect Chicago, you add a second Tunnel interface on R1. To connect Miami, you add a third.

Figure 3 – Three point-to-point tunnels on R1

Look at what R1 must manage:

• Three separate Tunnel interfaces (Tunnel0, Tunnel1, Tunnel2)

• Three different tunnel subnets

• Three separate routing adjacencies

With three branches, this is fine. With thirty, R1 becomes a bottleneck.
Every site change forces a hub reconfiguration.

Traffic Through the Hub

There is a second major problem: communication between branches.

Suppose a user in Chicago sends a file to a server in Miami.
Because R3 only has a tunnel pointing to New York, the packet cannot go direct.

Figure 4 – Branch traffic always crosses the hub

The packet crosses the Internet twice: Chicago to New York, then New York to Miami. R1 must decapsulate the packet, look up the routing table, and encapsulate it again toward R4.

All branch-to-branch traffic follows this path, placing unnecessary processing load on the hub. You could build direct tunnels between every pair of branches, but the number of required tunnels grows much faster than the number of branches.

One Destination per Tunnel

Both problems stem from the same root cause: a standard point-to-point GRE tunnel has exactly one destination.

Figure 5 – The cost of point-to-point tunnels

• One destination per tunnel interface means one interface per branch on the hub.

• A branch router can only talk to the hub, never directly to another branch.

To scale network design, the hub needs a single Tunnel interface capable of reaching multiple destinations dynamically.

DMVPN (Dynamic Multipoint VPN) solves these scaling limits.
"Multipoint" means a single Tunnel interface can reach multiple destinations dynamically.

You keep the exact same four routers and Internet links. Only the tunnel configuration changes.

One Tunnel for All Branches

Instead of creating one Tunnel interface per branch on R1, you configure a single Tunnel0 with no fixed destination.

Figure 6 – One Tunnel0 on the hub for every branch

That single interface reaches all three branches.
When a fourth branch opens, you do not touch R1 at all; the same Tunnel0 handles it.

This special interface type is called mGRE (multipoint GRE).
It uses standard GRE encapsulation, but omits the tunnel destination command. You will configure it in a later lesson.

Hub and Spoke Roles

DMVPN organizes routers into two roles:

• The Hub: R1, the central router that every spoke connects to.

• The Spokes: R2, R3, and R4, the branch routers.

Figure 7 – Hub and spoke roles

Spokes only need to know the public address of the hub.
They do not need any upfront configuration for the other branch routers.

In the next section, you will see how spokes manage to communicate directly without knowing each other in advance.

Compared to standard point-to-point GRE, DMVPN provides two major structural advantages.

Spoke-to-Spoke Traffic

Send the file from Chicago to Miami again.
This time, R3 builds a tunnel straight to R4, and your packet crosses the Internet only once.

Figure 8 – A spoke-to-spoke tunnel built on demand

The green tunnel in Figure 8 is a dynamic spoke-to-spoke tunnel.
R3 builds it only when it has traffic destined for R4, and the tunnel tears down automatically after a period of inactivity.

The hub stays completely out of the data path, reducing CPU overhead and latency.
This is why DMVPN is called dynamic.

Adding a Spoke

When a fifth branch opens, you configure its router with the public address of the hub.

Figure 9 – A new spoke, no change on the hub

The hub learns about the new spoke automatically. You do not add a Tunnel interface, create a new subnet, or modify any configuration on R1. The hub configuration is written once and remains identical whether you have 3 spokes or 300.

Point-to-Point GRE vs DMVPN

Side by side, here is how the two designs compare:

Table 1 – Point-to-point GRE vs DMVPN

Test what you just learned.
Open the branches, compare both designs, and earn your flag:

In the next lesson, you will see how the hub discovers new spokes automatically, and how a spoke finds the public address of another branch.