VPN: DMVPN, NHRP, and mGRE – Brief initial configuration review, verification review, and a link to all the gritty details!

Since we are now efficient at all things GRE and IPSec VPN at this point, that makes for a smooth transition into DMVPN , though I want to be crystal clear that the ROUTE Blueprint mentions only “Describe DMVPN (Single Hub)” so I will not be configuring it all over again, I do have a very config heavy link provided below for that.

First I’ll go over the theory, then throw up some initial config / verification examples just to familiarize yourself with, then finally a link to the page from whence they came.

So the above Topology gives the a good visual of all the components involved including:

• NHRP Client / Server model in action, there is a Hub (NHS) and spokes (NHC’s)
• mGRE (Multipoint) configured on the Hub to build multiple GRE tunnels
• Physical (Underlay) Tunnel (Overlay) address terms
• IPSec profiles to use in GRE for Securing the DMVPN tunnels once built (GRE over IPSEC!)

Now after drilling the last 3 posts about GRE, IPSec, and GRE over IPSEC we have a huge head start on understanding the initial configurations of (minus NHRP which will be referenced in the configs on this page only):

First lets review the roles that both (m)GRE and NHRP play in this to make it work:

• First the spokes will report their Underlay (Physical) and Overlay (Tunnel) mappings to the NHS for its Database for future NHC Query’s as illustrated here:

• Then a spoke router can Query the NHS for the Underlay mapping to the Overlay address requested as demonstrated here:

• And in theory if all configurations are correct and good to go, a tunnel should be formed between R2 and R3 as illustrated here:

• And that’s how babies are made (and DMVPN tunnels).

Now as mentioned above, I will post the initial configuration of both the NHS and the two spoke NHC’s, and link to it below the configurations / verification outputs:

GRE / NHRP (NOT IPSec initial configurations from R1 / R2 / R3:

R1

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int tu0
R1(config-if)#ip a
*Mar  1 17:39:30.031: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R1(config-if)#ip address 10.0.0.1 255.255.255.0
R1(config-if)#ip nhrp map multicast dynamic
R1(config-if)#ip nhrp network-id 1
R1(config-if)#tunnel source 172.12.123.1
R1(config-if)#tunnel mode gre multipoint
R1(config-if)#
*Mar  1 17:41:20.035: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R1(config-if)#ip mtu 1416
R1(config-if)#

R2

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int tu0
R2(config-if)#ip add 10
*Mar  1 18:00:20.802: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)#ip add 10.0.0.2 255.255.255.0
R2(config-if)#ip nhrp map 10.0.0.1 172.12.123.1
R2(config-if)#ip nhrp map multicast 172.12.123.1
R2(config-if)#ip nhrp network-id 1
R2(config-if)#ip nhrp nhs 172.12.123.1
R2(config-if)#tunnel source 172.12.123.2
R2(config-if)#tunnel mode gre multipoint
R2(config-if)#
*Mar  1 18:03:10.808: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R2(config-if)#ip mtu 1416
R2(config-if)#

R3

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int tu0
R3(config-if)#
*Mar  2 03:21:45.649: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip add 10.0.0.3 255.255.255.0
R3(config-if)#ip nhrp map 10.0.0.1 172.12.123.1
R3(config-if)#ip nhrp map multicast 172.12.123.1
R3(config-if)#ip nhrp network-id 1
R3(config-if)#ip nhrp nhs 10.0.0.1
R3(config-if)#tunnel source 172.12.123.3
R3(config-if)#tunnel mode gre multipoint
R3(config-if)#ip mt
*Mar  2 03:23:05.648: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#ip mtu 1416
R3(config-if)#

Then the final piece of the configuration, the GRE over IPSec configuration, R1 only:

Only the Hub(s) are configured with the GRE over IPSec configuration:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#hash md5
R1(config-isakmp)#encryption 3des
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#exit
R1(config)#crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
R1(config)#crypto ipsec transform TRANS esp-3des
R1(cfg-crypto-trans)#exit
R1(config)#crypto ipsec profile DMVPN
R1(ipsec-profile)#set transform-set TRANS
R1(ipsec-profile)#exit
R1(config)#int tu0
R1(config-if)#tunnel protection ipsec profile DMVPN
R1(config-if)#
*Mar  1 18:07:23.742: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R1(config-if)#

You see the IKE policy is set, the pre-shared key (PSK), the Transform-Set (Encryption), and the IPSec Profile that references the Transform set, which the Profile is then referenced by the GRE tunnel for Encryption for it’s tunnels.

Going over those configurations, I had a lot of difficulty in that lab, I don’t see that I actually configured a multi-point interface on s0/0 so I think that caused me a lot of problems (though few things work as they are expected to in my labs initially).

Speaking of discussing R1 as the Hub of this network, this is a good time to really underscore I don’t refer to it as the NBMA network Hub, but a DMVPN Hub as well – So when being referred to as a Hub in a VPN context, think DMVPN Hub router!

Ahem, moving on.

Now, to wrap this up, lets take a look at the verification command:

R1#sh ip nhrp
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:20:01, expire 01:58:16
  Type: dynamic, Flags: unique nat registered
  NBMA address: 172.12.123.3
R1#sh dmvpn
Legend: Attrb –> S – Static, D – Dynamic, I – Incompletea
        N – NATed, L – Local, X – No Socket
        # Ent –> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:1,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1    172.12.123.3        10.0.0.3    UP 00:20:24 D

R1#

• “sh ip nhrp” to see current Registered Clients, Tunnel IP’s and their corresponding Physical Interface IP addresses
• “sh dmvpn” gives about the same information, shows Registered Client status / uptime / IP Addresses, and will also show if you are on the Hub router.

Again this is from the initial setup, I go on to troubleshoot it, but I think I completely whiffed turning the Serial0/0 interface into a Multi-Point, and that’s why I initially had a single neighbor and later a flapping second neighbor at best in this post here regarding DMVPN configuration and troubleshooting that I am pulling this info from.

However given the ROUTE blueprint only requires a candidate to “Debscribe DMVPN”, the above commands mixed with a solid understanding of again the GRE / IPSec / GRE over IPSec posts that preceded this post on DMVPN.

If you read this post, and the preceding 3 posts regarding GRE / IPSec / GRE over IPSec, you will have that 10% of the VPN Section of the blueprint locked in!

Again, the hot-link to the whole DMVPN troubleshooting page is located here.

EDIT:

I wanted to add here a couple more pieces of material from the other page, that even if you don’t look at it, you should know for exam day:

NHRP and some details about it:

• The sending of tunnel / interface IP information to the NHRP Server, it is considered “Registering” to the NHS, including when it boots up.
• The NHS puts it in what is called its “Binding Table” or its “NHRP Database”

Also the “Phases” of DMVPN it is more like phases of its evolution rather than Phases of a VPN tunnel, so that has been said here are my comments from my earlier studies:

• Phase 1 – Hub and Spoke Topology only as mGRE is only configured on Hub, Spokes use point-to-point configuration so no spoke-to-spoke communication, Hub can become bottleneck from CPU or Bandwidth utilization of handling all communication
• Phase 2 – !!NO summarizaton allowed!!, Spoke-to-Spoke communications, No default route-originate from Hub, mGRE configured on Spokes and Hub router
• No idea, haven’t watched the hours of INE video yet, but it’s much more technical

We were configuring (and I would guess the exam tests) on Phase 2 of the 3, so I would just pay attention to the details when configured over EIGRP as I had, you cannot summarize or use default route originate on the Hub because I’d imagine it is a multi-point interface which I somehow completely missed during that lab.

Anyways, its even later, I just keep thinking over the topic and important things to note for exam day. I will try to stop updating this now, and leave the details on the other page.