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

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


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:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 657 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

528 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , ,


Forum Replies

  1. Hi !

    Now i am on this , i get this debug message

    Packet received via GigabitEthernet1/0, not configured for NHRPsrc 192.168.123.3 dst 192.168.123.1
    *Dec 20 16:38:12.083: NHRP: Pak out GigabitEthernet1/0 would leave logical NBMA network

    I have tried with giga int as source also…but the same. I was wodering if it is the platform i am using in GNS3

  2. Hello Rene,

    I was wondering if you would help with the following?
    This was configured in GNS3, and I used the same IP addressing you have here. Well for the most part.
    I can’t figure out why I keep getting the “retry limit exceeded” message below.

    Hub# debug nhrp
    *Nov 29 21:19:02.135: NHRP: Receive Registration Request via Tunnel0 vrf 0, packet size: 105
    *Nov 29 21:19:02.135: NHRP: netid_in = 1, to_us = 1
    *Nov 29 21:19:02.139: NHRP: Adding Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.5)
    *Nov 29 21:19:02.139: NHRP: Cache already has a subblock node att
    ... Continue reading in our forum

  3. Joel,
    Does it keep bouncing back and forth between “retry exceeded” then having a new adjacency? If so, this is usually indicative of EIGRP trying to use the tunnel to discover the tunnel endpoints themselves (so it becomes a recursive logic problem). We won’t know for sure until we see your config, though.

  4. Hello Rene,
    I’m trying to complete the DMVPN Phase 1 Basic Config in my home lab using your configuration steps and the diagram from the lesson. I don’t understand how you have two connections coming into the hub router using the same interface. I appear to have a cabling issue. As of now I can only get one of the spokes registered with the hub but not both sides. Please advise, thanks.

    Willie Brown

  5. Hello Rob,
    based on your previous post you are misunderstanding concept of different phases.

    • Hub is configured with “tunnel mode gre multipoint” in every DMVPN Phase (1, 2, 3).
    • Spokes are configured differently based on Phase you want to go with.
      Phase 1 is configured with “tunnel destination ip” on spokes. In DMVPN Phase 1 traffic between spokes goes always through the hub. This is definition of Phase 1.
      Phase 2 is configured with “tunnel mode gre multipoint” on spokes. Phase 2 allows direct spoke to spoke communication, thus traffic does not need to go throu
    ... Continue reading in our forum

17 more replies! Ask a question or join the discussion by visiting our Community Forum