DMVPN is a design concept. The idea is to create tunnels between devices (HUB- SPOKE or SPOKE-to-SPOKE) to pass traffic between them.

DMVPN emulates a cloud where we can combine different types of traffic (Multicast, broadcast) and send it as a unicast through the tunnel. GRE (Generic Routing Encapsulation) is the TCP/IP protocol used to build this tunnels.

 

Basic components needed to create a DMVPN

 

  • NHRP (Resolution protocol)

  • GRE  (Point to Point tunnel)

  • mGRE (Multiple Tunnels)

 

When a packet is received or sourced from one of the sides of the tunnel, the router adds an IP and GRE header  to the original packet so the router can determine exactly the destination of the packet. Once the packet reaches its destination, the other router deencapsulates the packet, stripping off the IP header and GRE header, leaving the original packet header intact so the router will know what physical interface to send the packet.

 

How routers made a decision when tunneling traffic?

 

NHRP (Next-Hop-Resolution-Protocol)

 

NHRP is a protocol that maps a private address to a public address. Let’s take a look at this example.

 

 

The IP addresses colored in black represents the IP public addresses assigned by the ISP. The Private addresses are red colored representing the private tunnels between the routers.

 

IPVLCOUD-HUB is like a server, SPOKE-A and SPOKE-B routers respond to the server. When a tunnel interface is configured with NHPR, as soon as the router boots up, it performs the NHRP registration. Routers create a binding table that tell the other router where to go when a packets need to be sent or received.  For example:

 

 

Let’s say that the user A wants to talk to User B

 

  1. User A sends  a request  (ARP) to  router (SPOKE-A)
  2. SPOKE-A  finds out that user A packets needs to go through the tunnel between  (SPOKE-A an d IPVCLOUD-HUB)
  3. SPOKE-A asks to NHRP protocol; how can I get to IPVCLOUD-HUB ? I need to send some packets over the tunnel

  4. IPVCLOUD-HUB checks its NHRP binding table and replies: “Sure!, If you want to reach 10.10.10.1 subnet, please use my public IP address 200.10.0.1 to get there, my routing table will take care of the rest!

Basically, “NHRP” resolves the private address using the public addresses. This communication  happens within the tunnel.

 

DMVPN has three phases:

 

Phase 1

This phase only allows a routing adjacency between a (HUB-to-SPOKE) If a spoke wants to communicate to another spoke, it has to go through the HUB first.

Limitations:

  • Not scalable
  • HUB CPU and Memory Burdened.
  • Inefficient

 

Phase 2

 

In this phase  the spoke router can talk to another spoke router without taking suboptimal path through the HUB.

 

Restrictions:

  • Spokes has to use mGRE so they create multiples dynamic tunnels
  • Specific routes for remote subnets has to be configured using routing protocols
  • Split Horizon has to be disable

 

Phase 3

In this phase configuration the hub job is reduce by allowing spokes to respond to resolution requests. This is a sort of phase II enhancement.

 

In this article I am going to show you an example of a phase 2 DMVPN configuration. I am in the process to achieve the CCNP certification and this article reflects it as way to reinforce and practice the knowledge. Suggestions or comments to enhance this article are more than welcome.

 

DMVPN Phase 2 configuration

 

In this scenario, the goal is to allow SPOKE to SPOKE to create a tunnel dynamically without detouring to IPVCLOUD-HUB.

 

 

  1. Create tunnel for IPVCLOUD-HUB:

 

IPVCLOUD-HUB#sh run int Tunnel 1

Building configuration…

 

(REDACTED)

interface Tunnel1

ip address 10.10.10.1 255.255.255.0

no ip next-hop-self eigrp 1

no ip split-horizon eigrp 1

ip nhrp authentication ipvcloud

ip nhrp map multicast dynamic

ip nhrp network-id 1

tunnel source Ethernet1/1

tunnel mode gre multipoint

tunnel key 1

End

 

 

For this lab I will use EIGRP routing protocol for the tunnels. Two important considerations regarding DMVPN with EIGRP.  When EIGRP is enabled, the hub will not advertise a route out of the interface from which the route was learned (Split Horizon Rule).

 

 

 

If we check EIGRP routes with the command “show ip route eigrp” on SPOKE-B, it is only showing one route (11.11.11.0) learned via  IPVCLOUD-HUB.

 

 

For the Hub the tunnel configuration is pretty straight forward:

 

  • “Ip nhrp map multicast dynamic”       Allows multicast traffic on the tunnel.

 

  • “tunnel mode gre multipoint”     Tells the hub that is going to form multiple tunnels (mGRE)

 

Note:” Tunnel Key and authentication hast to match on all routers for the tunnels to be formed.”

We disable split horizon using the command “no ip split horizon eigrp 1.”  Now, let’s check SPOKE-B router:

 

 

The route (22.22.22.0) coming from (SPOKE-A) through (IPVCLOUD-HUB) router is learned.

 

Then, we have to tell the HUB to not advertise itself as the next hop for route 22.22.22.0. This is because we want to form a dynamic tunnel between SPOKES. If the HUB advertises itself as the next hop when advertising routes, it will defeat the whole purpose of the DMVNP phase 2 in the first place. So, let’s disable it:

 

 

Let’s check the routes on SPOKE-B again:

 

 

SPOKE-A Tunnel Configuration:

 

 

SPOKE-B Tunnel Configuration

 

 

The private address will be 10.10.10.2 and 10.10.10.3 for the SPOKES routers respectively.

 

“ip nhrp map 10.10.10.1 200.10.0.1”  This command tells the NHRP protocol to map the private address with the public address, so the packets will know what physical interface and public address to use to get to the other side of the tunnel. Notice that is the same command for both SPOKE-A and SPOKE-B

 

“ip nhrp map multicast 200.10.0.1”  Enables forwarding of multicast traffic using the HUB as a “Server”

 

“ip nhrp nhs 10.10.10.1”                  Enables the IPVCLOUD-HUB router as a server ( nhs –> Next Hop Server)

 

“tunnel source Ethernet 1/1”           Tells the router what physical interface to use for one of the sides of the tunnel.

 

“tunnel mode gre multipoint”            Because this is a multiple tunnel design, we do not use Tunnel destination but tunnel mode gre      multipoint instead, so the SPOKE-to-SPOKE tunnel can form.

 

“tunnel Key and ip nhrp authentication ipvclou”  

These parameters have to match for the tunnels to be formed in all the routers that are participating in the DMVPN.

 

Let’s test it:

IPVCLOUD-HUB

 

 

SPOKE-A

 

 

SPOKE-B

 

 

I pinged SPOKE-B from SPOKE-A successfully and vice versa. The traceroute shows that when pinging SPOKE-A private address, it goes like point-to-point which proves that packets are no taking suboptimal paths through IPVCLOUD-HUB.

 

Let’s trace the LAN 22.22.22.1 from SPOKE-B sourcing tunnel 1:

 

 

 

SPOKE-B now knows how to reach the HUB and the other SPOKE router

 

 

SPOKE-A now knows how to reach the HUB and the other SPOKE router

 

 

 

The Hub now has a table with the dynamic tunnels information.

 

Why do we need DMVMP in real life?

Well, depends of the type of situation. But, for example, when a company needs to connect two branch using the internet, they usually use a VPN connection type like Site-to-Site which uses an IPSEC tunnel feature to encrypt the data. IPSEC does not allow multicast traffic. By using mGRE the “multicast traffic” can be encapsulated as “unicast traffic” and be sent through the GRE tunnel.

 

Thank you,

 

Jesus Contreras.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Bitnami