CONFIGURING CISCO DYNAMIC MULTIPOINT VPN

(DMVPN) - HUB, SPOKES , MGRE PROTECTION AND

ROUTING - DMVPN CONFIGURATION
DMVPN OPERATION - HOW DMVPN OPERATES
Before diving into the configuration of our routers, well briefly explain how the DMVPN is expected to work.
This will help in understanding how DMVPN operates in a network:

Each spoke has a permanent IPSec tunnel to the hub but not to the other spokes within the network.

Each spoke registers as a client of the NHRP server. The Hub router undertakes the role of the NHRP
server.

When a spoke needs to send a packet to a destination (private) subnet on another spoke, it queries the
NHRP server for the real (outside) address of the destination (target) spoke.

After the originating spoke learns the peer address of the target spoke, it can initiate a dynamic IPSec
tunnel to the target spoke.

The spoke-to-spoke tunnel is built over the multipoint GRE (mGRE) interface.

The spoke-to-spoke links are established on demand whenever there is traffic between the spokes.
Thereafter, packets are able to bypass the hub and use the spoke-to-spoke tunnel.

All data traversing the GRE tunnel is encrypted using IPSecurity (optional)

OUR DMVPN NETWORK

The diagram below depicts our DMVPN example network. Our goal is to connect the two remote networks
(Remote 1 & 2) with the company headquarters. The headquarters router R1 is the central Hub router that
will hold the NHRP database containing all spoke routers, their public IP addresses and LAN networks.

FOUR STEPS TO FULLY CONFIGURE CISCO DMVPN

To help simplify the configuration of DMVPN weve split the process into 4 easy-to-follow steps. Each step
is required to be completed before moving to the next one. These steps are:

Configure the DMVPN Hub

Configure the DMVPN Spoke(s)

Protect the mGRE tunnels with IPSecurity (optional)

Configure Routing Between DMVPN mGRE Tunnels (static routing or routing protocol)

CONFIGURING THE DMVPN HUB R1 ROUTER

Configuring the Hub router (R1) is simple. After configuring the routers LAN and WAN interfaces we create
our mGRE tunnel interface. Let's start with the routers Ethernet interfaces:
interface FastEthernet0/0
description LAN-Network
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1

description WAN-Network
ip address 1.1.1.10 255.255.255.0
duplex auto
speed auto

Next, we configure the Tunnel0 interface. Notice this is an almost typical tunnel interface configuration with
some minor but important changes that have been highlighted:
interface Tunnel0
description mGRE - DMVPN Tunnel
ip address 172.16.0.1 255.255.255.0
no ip redirects
ip nhrp authentication firewall
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source 1.1.1.10
tunnel mode gre multipoint
Engineers familiar with GRE Tunnels will immediately notice the absence of the tunnel
destination command. It has been replaced with the tunnel mode gre multipointcommand, which
designates this tunnel as a multipoint GRE tunnel.
The ip nhrp map multicast dynamic command enables the forwarding of multicast traffic across the tunnel
to dynamic spokes. This is usually required by routing protocols such as OSPF and EIGRP. In most cases,
DMVPN is accompanied by a routing protocol to send and receive dynamic updates about the private
networks.
The ip nhrp network-id 1 command is used to identify this DMVPN cloud. All routers participating in this
DMVPN cloud must have the same network-id configured in order for tunnels to form between them.
The ip nhrp authentication command is used to allow the authenticated updates and queries to the NHRP
Database, ensuring unwanted queries are not provided with any information about the DMVPN network.

CONFIGURING THE DMVPN SPOKES R2 & R3 ROUTERS

Spoke router configuration is similar to that of the hub. First configure the LAN and WAN interfaces:
interface FastEthernet0/0
description LAN-Network
ip address 192.168.2.1 255.255.255.0
duplex auto

speed auto
!
interface FastEthernet0/1
description WAN-Network
ip address 2.2.2.10 255.255.255.0
duplex auto
speed auto

Next, its time to build that tunnel:

interface Tunnel0
description R2 mGRE - DMVPN Tunnel
ip address 172.16.0.2 255.255.255.0
no ip redirects
ip nhrp authentication firewall
ip nhrp map multicast dynamic
ip nhrp map 172.16.0.1 1.1.1.10
ip nhrp map multicast 1.1.1.10
ip nhrp network-id 1
ip nhrp nhs 172.16.0.1
tunnel source FastEthernet0/1
tunnel mode gre multipoint
After a couple of seconds, we receive confirmation that our tunnel interface is up:
Sep 9 21:27:29.774: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
The ip nhrp nhs 172.16.0.1 command tells our spoke router who the Next Hop Server (NHS) is, while
the ip nhrp map 172.16.0.1 1.1.1.10 command maps the NHS address (172.16.0.1) to the Hubs (R1)
public IP address (1.1.1.10).
The ip nhrp map multicast 1.1.1.10 ensures multicast traffic is sent only from spokes to the hub and not
from spoke to spoke. All multicast traffic should be received by the hub, processed and then updates are
sent out to the spokes.
Lastly, notice that tunnel source FastEthernet0/1 command. All spokes with dynamic WAN IP address
must be configured to bind the physical WAN interface as the tunnel source. This way, when the spokes
WAN IP changes, it will be able to update the NHS server with its new WAN IP address.
Note: In R2s configuration, weve configured a static IP address on its WAN interface FastEthernet0/1, but
for the sake of this example, let us assume it was dynamically provided by the ISP.
R3s configuration follows, similar to that of the R2 spoke router:

interface FastEthernet0/0
description LAN-Network
ip address 192.168.3.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
description WAN-Network
ip address 3.3.3.10 255.255.255.0
duplex auto
speed auto

Next, our tunnel configuration:

interface Tunnel0
description R3 mGRE - DMVPN Tunnel
ip address 172.16.0.3 255.255.255.0
no ip redirects
ip nhrp authentication firewall
ip nhrp map multicast dynamic
ip nhrp map 172.16.0.1 1.1.1.10
ip nhrp map multicast 1.1.1.10
ip nhrp network-id 1
ip nhrp nhs 172.16.0.1
tunnel source FastEthernet0/1
tunnel mode gre multipoint
Note: In R3s configuration, weve configured a static IP address on its WAN interface FastEthernet0/1,
but for the sake of this example, let us assume it was dynamically provided by the ISP.
This completes the DMVPN configuration on our central hub and two spoke routers. It is now time to verify
the DMVPNs are working correctly.

VERIFYING DMVPN FUNCTIONALITY AT THE R1 HUB ROUTER

After completing our routers configuration, its time to verify everything is working as planned.
First we turn to our main hub, R1, and check the DMVPN by using the show dmvpn command:

The output of our command provides us with some valuable information. To start with, the router
provides an explanation for each column presented (right under the show command) but we are still going
to cover them so that we are not left with any unanswered questions.
The first column #Ent shows the number of entries that exist in the NHRP Database for the same spoke.
Usually, we wouldnt expect to see more than one for each spoke.
The second column Peer NBMA Addr presents the spokes public IP address, while the third column, Peer
Tunnel Add, shows each spokes local Tunnels IP address.
Next, the State column shows the current state the tunnel is in. In our case, both tunnels are UP. Right next
to the State is the UpDN Tm, which is the Up or Down Time of the current State. This is a very important
bit of information as you can clearly see out how long your tunnel has been in its current state.
For our example, both spokes have been up for almost 5 minutes.
Lastly, the Attrib column shows the type of tunnels established by the spokes. D stands for Dynamic, S for
Static and I for Incomplete. Usually dynamic spokes will create D type tunnels. Tunnels established from
the spokes to the Hub router are expected to be S type, since the Hub remains static.

VERIFYING DMVPN FUNCTIONALITY AT THE R2 & R3 SPOKE ROUTER

Turning to R2 router, our first spoke, we can repeat the same show dmvpn command and obtain a list of
dmvpns currently created:

As expected, R2s output shows one entry only. When traffic needs to be directed to R3, a second GRE
tunnel will come up. Well try this soon. For now lets check our third remote site, R3 spoke router
Using the same show dmvpn command we obtain the following similar output:

PROTECTING - ENCRYPTING DMVPN MGRE TUNNELS WITH IPSEC

Since we have our GRE tunnels up and running, we need to encrypt them using IPSec to ensure data
confidentiality. Protecting GRE Tunnels is covered in great depth in our Protected GRE over IPSec article,
so we are going to simply display the commands here without repeating the topic.
First stop is our headquarters R1 Hub router:

crypto isakmp policy 1

encr 3des
hash md5
authentication pre-share
group 2
lifetime 86400
!
crypto isakmp key firewall.cx address 0.0.0.0
!
crypto ipsec transform-set TS esp-3des esp-md5-hmac
!
crypto ipsec profile protect-gre
set security-association lifetime seconds 86400
set transform-set TS
!
interface Tunnel 0
tunnel protection ipsec profile protect-gre
Notice the command crypto isakmp key firewall.cx address 0.0.0.0 0.0.0.0. The peer address for which
the isakmp key is valid is0.0.0.0 0.0.0.0, which means every possible host on the Internet. When our
remote routers (spokes) have dynamic IP addresses, 0.0.0.0 0.0.0.0 must be used.
The following configuration applies to R2 & R3 spoke routers:
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
lifetime 86400
!
crypto isakmp key firewall.cx address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set TS esp-3des esp-md5-hmac
!
crypto ipsec profile protect-gre
set security-association lifetime seconds 86400
set transform-set TS
!
interface Tunnel 0
tunnel protection ipsec profile protect-gre
Again weve defined 0.0.0.0 0.0.0.0 as the isakmp peer address. While the hubs public IP address is
known we must keep in mind that R2 and R3 can build dynamic VPN tunnel between them. Taking into

consideration that their public IP address is dynamic it is imperative to use 0.0.0.0 0.0.0.0 for the remote
peer.

VERIFYING THE DMVPN CRYPTO TUNNELS

Once all routers are configured IPSec VPN tunnels are brought up. We can verify this by using the show
crypto session command at our R1 hub router:
R1# show crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 2.2.2.10 port 500
IKE SA: local 1.1.1.10/500 remote 2.2.2.10/500 Active
IPSEC FLOW: permit 47 host 1.1.1.10 host 2.2.2.10
Active SAs: 2, origin: crypto map
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 3.3.3.10 port 500
IKE SA: local 1.1.1.10/500 remote 3.3.3.10/500 Active
IPSEC FLOW: permit 47 host 1.1.1.10 host 3.3.3.10
Active SAs: 2, origin: crypto map

ROUTING BETWEEN DMVPN MGRE TUNNELS

Last step involves enabling routing in our DMVPN network. This is required so that the hub and spoke
routers are aware which packets need to be sent via the VPN network.
There are two ways this can be achieved: 1) Static routes 2) Routing protocol.
For the sake of simplicity we are going to focus on static routes. DMVPN and routing protocol configuration
will be covered in another article.
Configuring the necessary static routes is very simple. All that is required is a set of simply static routes on
each router (hub and spoke), pointing to the other networks.
On the R1 hub router:
ip
route
192.168.2.0
ip route 192.168.3.0 255.255.255.0 172.16.0.3
On R2 spoke router:

255.255.255.0

172.16.0.2

ip
route
192.168.1.0
ip route 192.168.3.0 255.255.255.0 172.16.0.3

255.255.255.0

172.16.0.1

255.255.255.0

172.16.0.1

And finally on R3 spoke router:

ip
route
192.168.1.0
ip route 192.168.2.0 255.255.255.0 172.16.0.2

OUR DMVPN NETWORK IS READY!

At this point, our DMVPN network is ready and fully functional. All networks are connected between each
other and dynamic VPN tunnels between spokes can be established. GRE tunnels are protected properly,
providing data confidentiality and ip routing is enabled.
As a final step, we can try sending traffic between the spokes and verify the dynamic tunnel is being
established:
From R2 spoke router, we try to ping R3s LAN IP address:

It is evident that the two spoke routers have established communication.

The DMVPN is up and routing is working perfectly: