DMVPN Phase 1 Basic Configuration

In the first lesson about DMVPN I explained some of the basics of how multipoint GRE, NHRP and the different phases work. In this lesson, I’ll show you how to configure DMVPN phase 1. We will then use this configuration in some other examples where we try to run RIP, OSPF, EIGRP and BGP on top of it. Here’s the topology that we will use:

Above we have three routers, a hub and two spoke routers. The underlay network uses subnet 192.168.123.0/24 and the overlay network (our tunnel interfaces) will use 172.16.123.0/24.

Let’s take a look at the configuration!

Configuration

Hub

We will start with the hub configuration. Here’s what it looks like:

Hub(config)#interface Tunnel 0
Hub(config-if)#ip address 172.16.123.1 255.255.255.0
Hub(config-if)#tunnel mode gre multipoint 
Hub(config-if)#tunnel source Gigabit0/1
Hub(config-if)#ip nhrp authentication DMVPN
Hub(config-if)#ip nhrp map multicast dynamic 
Hub(config-if)#ip nhrp network-id 1

Let me explain the commands above:

• tunnel mode: by default the tunnel mode will be point-to-point GRE, we require a multipoint interface on the hub.
• tunnel source: the tunnel destinations will be dynamic but we still have to configure the source, our Gigabit0/1 interface.
• ip nhrp authentication: we can authenticate our NHRP traffic, it’s optional but a good idea to enable. I’m using pre-shared key “DMVPN”.
• ip nhrp map multicast dynamic:  this command tells the hub router where to forward multicast packets to. Since the IP addresses of the spoke routers are unknown, we use dynamic to automatically add their IP addresses to the multicast destination list when the spokes register themselves.
• ip nhrp network-id: when you use multiple DMVPN networks, you need the network ID to differentiate between the two networks. This value is only locally significant but for troubleshooting reasons it’s best to use the same value on all routers.

After a few seconds you will see the tunnel becoming active:

Hub#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

We are now ready to configure some spoke routers…

Spokes

Let’s start with spoke1, here’s what the configuration looks like:

Spoke1(config)#interface tunnel 0
Spoke1(config-if)#ip address 172.16.123.2 255.255.255.0
Spoke1(config-if)#ip nhrp authentication DMVPN
Spoke1(config-if)#ip nhrp map 172.16.123.1 192.168.123.1
Spoke1(config-if)#ip nhrp map multicast 192.168.123.1
Spoke1(config-if)#ip nhrp network-id 1    
Spoke1(config-if)#ip nhrp nhs 172.16.123.1
Spoke1(config-if)#tunnel source Gigabit0/1
Spoke1(config-if)#tunnel destination 192.168.123.1

Some of the commands are the same as on the hub, let me explain the commands that are different:

• ip nhrp map: we use this on the spoke to create a static mapping for the hub’s tunnel address (172.16.123.1) and the hub’s NBMA address (192.168.123.1). This will be stored in the NHRP cache of the spoke router.
• ip nhrp map multicast: here we specify which destinations should receive broadcast or multicast traffic through the tunnel interface. The confusing part is that you have to enter the NBMA address here. We need this command since routing protocols like RIP, EIGRP and OSPF require multicast.
• ip nhrp nhs: this is where we specify the NHRP server, our hub router.
• tunnel destination: we are using point-to-point GRE so we need to specify a destination for the tunnel, this will be the hub router.

After a few seconds you will see the tunnel interface:

Spoke1#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

Our tunnel interfaces are up and running but we should check if our spoke has registered with the hub:

Hub#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
	N - NATed, L - Local, X - No Socket
	T1 - Route Installed, T2 - Nexthop-override
	C - CTS Capable
	# Ent --> Number of NHRP entries with same NBMA peer
	NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
	UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details 
Type:Hub, NHRP Peers:1, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.2      172.16.123.2    UP 00:03:36     D

This is looking good, when you use the show dmvpn command you can see the NHRP cache of our hub. It shows us that our spoke with tunnel address 172.16.123.2 has registered its NBMA address 192.168.123.2. Another command that gives us this information is show ip nhrp:

Hub#show ip nhrp 
172.16.123.2/32 via 172.16.123.2
   Tunnel0 created 00:04:02, expire 01:55:57
   Type: dynamic, Flags: unique registered used nhop 
   NBMA address: 192.168.123.2

Let’s take a closer look at the NHRP registration from the spoke to the hub, we’ll enable a debug for this:

Hub & Spoke1
#debug nhrp 
NHRP protocol debugging is on

To see the registration, I shut both tunnel interfaces. Then activate the hub tunnel interface first and the spoke router a few seconds later. Here’s what you will see:

NHRP: Receive Registration Request via Tunnel0 vrf global(0x0), packet size: 105
NHRP: Tunnels gave us pak src: 192.168.123.2
NHRP: Could not find AVL node for vrf:global(0x0)
NHRP: Could not find AVL node for vrf:global(0x0)
NHRP: Inserted node for vrf global(0x0)
NHRP: Initialized cache radix head for vrf global(0x0)
NHRP: Adding Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP:  
NHRP: Peer capability:0
NHRP: Adding Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: NHRP subblock already exists for Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: Peer capability:0
NHRP: Cache already has a subblock node attached for Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: Enqueued dynamic mapping to end of list
NHRP: Tu0: Creating dynamic multicast mapping  NBMA: 192.168.123.2
NHRP: Added dynamic multicast mapping for NBMA: 192.168.123.2
NHRP: Attempting to send packet through interface Tunnel0 via DEST  dst 172.16.123.2
NHRP: Send Registration Reply via Tunnel0 vrf global(0x0), packet size: 125
      src: 172.16.123.1, dst: 172.16.123.2
NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 192.168.123.2
NHRP: 149 bytes out Tunnel0 
NHRP: Receive Registration Request via Tunnel0 vrf global(0x0), packet size: 105
NHRP: Tunnels gave us pak src: 192.168.123.2
NHRP: Adding Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: NHRP subblock already exists for Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: Peer capability:0
NHRP: Cache already has a subblock node attached for Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: Adding Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: NHRP subblock already exists for Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: Peer capability:0
NHRP: Cache already has a subblock node attached for Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: nhrp_subblock_check_for_map() - Map Already Exists
NHRP: Attempting to send packet through interface Tunnel0 via DEST  dst 172.16.123.2
NHRP: Send Registration Reply via Tunnel0 vrf global(0x0), packet size: 125
      src: 172.16.123.1, dst: 172.16.123.2
NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 192.168.123.2
NHRP: 149 bytes out Tunnel0 

This produces a lot of debug information. You can see that the hub receives a NHRP registration from the spoke and that it adds a multicast entry. Here’s what it looks like on the spoke:

Spoke1#
NHRP: if_up: Tunnel0 proto 'NHRP_IPv4'
NHRP: Registration with Tunnels Decap Module succeeded
NHRP: Adding all static maps to cache
NHRP: Adding multicast map entry to multicast list 192.168.123.1
NHRP: Could not find AVL node for vrf:global(0x0)
NHRP: Inserted node for vrf global(0x0)
NHRP: Initialized cache radix head for vrf global(0x0)
NHRP: No SNMP node found to add requestID
NHRP: Multicast enabled for dst 192.168.123.1
NHRP: NHS 172.16.123.1 Tunnel0 vrf 0 Cluster 0 Priority 0 Transitioned to 'E' from ' ' 
NHRP: Attempting to send packet through interface Tunnel0 via DEST  dst 172.16.123.1
NHRP: Send Registration Request via Tunnel0 vrf global(0x0), packet size: 105
      src: 172.16.123.2, dst: 172.16.123.1
NHRP: 129 bytes out Tunnel0 
NHRP: Receive Registration Reply via Tunnel0 vrf global(0x0), packet size: 125
NHRP: NHS 172.16.123.1 Tunnel0 vrf 0 Cluster 0 Priority 0 Transitioned to 'RE' from 'E' 
NHRP: NHS-UP: 172.16.123.1
NHRP: if_up: Tunnel0 proto 'NHRP_IPv4'
NHRP: Registration with Tunnels Decap Module succeeded
NHRP: Adding all static maps to cache
NHRP: Adding multicast map entry to multicast list 192.168.123.1
NHRP: No SNMP node found to add requestID
NHRP: Attempting to send packet through interface Tunnel0 via DEST  dst 172.16.123.1
NHRP: Send Registration Request via Tunnel0 vrf global(0x0), packet size: 105
      src: 172.16.123.2, dst: 172.16.123.1
NHRP: 129 bytes out Tunnel0 
NHRP: Receive Registration Reply via Tunnel0 vrf global(0x0), packet size: 125

Above we can see that the spoke adds an entry in its local NHRP cache and tries to send the NHRP registration message, it succeeds and receives the NHRP registration reply from the hub. Here’s what these packets look like in wireshark: