Category Archives: CCNP – DMVPN

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

dmvpn_2

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:

dmvpn_3

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

dmvpn_4

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

dmvpn_5

  • 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.

More Intro to DMVPN! Phases descriptions, what NHRP is, a Phase 2 configuration and troubleshooting

dmvpn_2

This was a misleading Topology in the way that, this describes a Phase 1 DMVPN.

There are 3 phases of DMVPN, which are like different series, which has progressively gotten better over time and included more features. This is a list of the 3, and what features they included / lacked:

  • 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

Highlighted a few important parts in there, like I said the DMVPN INE section is 8-9 hours and I cannot derail from my warpath of Chris Bryants series right now, but I did want to touch a bit more on DMVPN.

Especially NHRP, cause I couldn’t find it in the INE or Chris Bryants CCNA or CCNP R/S courses and literally said out loud are you friggin kidding me? Apparently you are supposed to get your knowledge of it via DMVPN then kind of find your own resources, so wanted to have it’s own section here for just a moment.

NHRP and some details about it:

  • NHRP was really created to fill the gap of mapping tunnels to their physical or logical addresses used to build those tunnels
  • Upon configuring an NHC, when the router boots up it creates an “NHRP registration” that is sent to the NHS
  • The NHS puts it in what is called its “Binding table” or its “Database”

I thought I had more than that, but I guess that is it for now.

(Also, for the below config, I’d like to credit the Cisco web forum post https://supportforums.cisco.com/document/124431/dmvpn-configuration-example for their example configuration, cause I am totally stealing it for my rack and seeing if it works and turning off my brain for the night!)

Ok, onto configuration of a Phase 2 DMVPN:

I have no idea really where to start, you need to confirm connectivity between all spokes, which I confirmed by pinging from R2 – R1 – R3:

R2#ping 172.12.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/132/140 ms
R2#

So I am going to go for the gold and start configs on the Hub R1, and I will explain some of the values after the output:

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)#

Starting off with the pretty pink, you want to assign your tunnel interface the “Overlay” address of your tunnel end point, next I wanted to point out the network-id # is locally significant only but comes into play in DMVPN Phase 3 and can be used across multiple interfaces / tunnels on the same router (above my study pay grade), and to make it a point to point out the tunnel source will be the physical interface IP address that is orchestrating all this DMVPN madness, then finally the IP MTU being slightly lowered as the I believe it’s GRE that has a little extra baggage that adds to packet size so we need to adjust that payload size down a bit.

That was kind of fun, I should type in color more often.

Couple things to note was the tunnel went straight to a “Down” state upon configuring it unlike a loopback logical interface, however it came right back “Up” as soon as we issued a tunnel mode command (gre multipoint in this case).

So on 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)#

That seemed like a LOT of configuration for a spoke, I was beginning to think it was a Phase 1 example, however it does have the GRE Multipoint configured so I’ll go with it. The reason being it seems too hefty, it needs 3 references back to the Hub / NHS? What??

So I’ll play along and do it all over again on 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)#

Alrighty… Now what? Ahhh yes, this time we are adding the following IPSec crypto map policy to make sure our DMVPN traffic is secure, I will only post the configuration from R1 as it will be an exact copy on R2 and R3:

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)#

So to begin the blue section is setting the crypto isakmp policy to be used, next comes us defining the PSK (Pre-Shared Key) for our tunnels with an address of 0.0.0.0 0.0.0.0 (anyone), then we define a transform set to be used and exit out of its configuration (not going to define tunnel / transport mode for this), then a crypto ipsec profile named DMVPN is created and defined in its own config to use the transform-set we defined, and finally in the pretty purple we apply it to our tunnel interface and get a message showing us ISAKMP is ON and ready to rock and roll.

I really didn’t take any LSD before posting this, I just found with all this configuration color coding it is going to make it a lot easy to read later. So now I apply it to the spokes quick, and we’ll see if those kick out any odd messages.

No new messages from them, all showed ISAKMP turning on, I love universal configs for my lab from time to time! So lets see whats going on with the Hub R1:

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#

I am for some reason missing R2, I reviewed the config and it is exactly the same as R3, so I am going to wr / reload all 3 routers to see if that makes any difference:

R1#sh ip nhrp
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:00:07, expire 01:59:52
Type: dynamic, Flags: unique nat registered used
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:01:17 D

R1#
ASR#2
[Resuming connection 2 to r2 … ]

R2#ping 172.12.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/132/140 ms
R2#

So it’s still the same in only seeing R3 for some reason, and I have no idea why. I wanted to see if I could hold out, but it is time to put a layer 3 dynamic routing protocol or some static routes around to see if that does anything. Some of the videos on INE eluded that EIGRP was the best protocol for DMVPN deployments, so I will give that a try:

R1(config)#router eigrp 100
R1(config-router)#no auto
R1(config-router)#network 172.12.123.0 0.0.0.255
R1(config-router)#network 10.0.0.0 0.0.0.255
R1(config-router)#network 1.1.1.1 0.0.0.0
R1(config-router)#exit
R1(config)#int tu0
R1(config-if)#no ip next-hop-self eigrp 100
R1(config-if)#no ip split eigrp 100
R1(config-if)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router eigrp 100
R2(config-router)#no auto
R2(config-router)#network 172.12.123.0 0.0.0.255
R2(config-router)#ne
*Mar  1 18:43:16.179: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/0) is up: new adjacency
R2(config-router)#network 10.0.0.0 0.0.0.255
R2(config-router)#network 2.2.2.2 0.0.0.0
R2(config-router)#int tu0
R2(config-if)#no ip next-hop-self eigrp 100
R2(config-if)#no ip split eigrp 100
R2(config-if)#
ASR#3
[Resuming connection 3 to r3 … ]

R3#
R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#router eigrp 100
R3(config-router)#network 172.12.123.0 0.0.0.255
R3(config-router)#networ
*Mar  2 04:00:22.906: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/2) is up: new adjacency
R3(config-router)#network 10.0.0.0 0.0.0.255
*Mar  2 04:00:47.022: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is up: new adjacency <- What??? ARGHH
R3(config-router)#network 3.3.3.3 0.0.0.0
R3(config-router)#no auto
R3(config-router)#
*Mar  2 04:01:01.073: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is resync: summary configured
*Mar  2 04:01:01.073: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/2) is resync: summary configured
R3(config-router)#

What is R1’s problemo with R2’s Tunnel interface??? I hope to see it now despite not seeing that tunnel coming in the mf#R@*Eing output in router config:

R1#sh ip nhrp
10.0.0.2/32, Tunnel0 created 00:01:39, expire 00:01:25
  Type: incomplete, Flags: negative
  Cache hits: 7
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:15:18, expire 01:44:41
  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:2,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1         0.0.0.0        10.0.0.2  NHRP    never IX
     1    172.12.123.3        10.0.0.3    UP 00:15:25 D

R1#
*Mar  1 18:40:44.615: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is down: retry limit exceeded
R1#
*Mar  1 18:40:48.826: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
R1#

Success!! And then…. flapping. Well at least we know a dynamic protocol got it working again. Now I believe the output seen has something to do with EIGRP giving itself a next hop of 0.0.0.0 0.0.0.0 (itself) so I will investigate whats up on R2 but first I want to reserve this timing on the drops for later review when I’m all smarter at this:

R1#
*Mar  1 18:40:44.615: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is down: retry limit exceeded
R1#
*Mar  1 18:40:48.826: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
R1#
*Mar  1 18:42:08.349: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is down: retry limit exceeded
R1#
*Mar  1 18:42:12.503: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
R1#
*Mar  1 18:43:32.030: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is down: retry limit exceeded
R1#
*Mar  1 18:43:33.296: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
R1#

It goes down for about 4 seconds, then remains up for about 20 seconds, which is really goofy in terms of an EIGRP timer over a Serial link.

So the really odd thing doing a stare and compare of R2 to R3’s show run, I found that on R3, I did not put in any of tunnel interface “no eigrp …” commands because it came up right away, so I’m going to remove them from R2 to see what happens first:

R2(config)#no int tu0
R2(config)#
*Mar  1 19:01:13.846: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is OFF
R2(config)#interface Tunnel0
R2(config-if)# ip address 10.0.0.2 255.255.255.0
R2(config-if)# no ip redirects
R2(config-if)# ip mtu 1416
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)# tunnel protection ipsec profile DMVPN
R2(config-if)#
*Mar  1 19:01:47.276: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R2(config-if)#
ASR#1
[Resuming connection 1 to r1 … ]

R1#
R1#sh ip nhrp
10.0.0.2/32, Tunnel0 created 00:03:03, expire 00:00:01
  Type: incomplete, Flags: negative
  Cache hits: 7
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:29:14, expire 01:30:45
  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:2,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1         0.0.0.0        10.0.0.2  NHRP    never IX
     1    172.12.123.3        10.0.0.3    UP 00:29:22 D

R1#

Didn’t make a bit of difference, this is a bit baffling to me, so I am going to apply it to both tunnel interfaces and see what happens:
R2(config)#int tu0
R2(config-if)#ip hold-time eigrp 100 35
R2(config-if)#no ip next-hop-self eigrp 100
R2(config-if)#no ip split eigrp 100
R2(config-if)#
ASR#3
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int tu0
R3(config-if)#ip hold-time eigrp 100 34
R3(config-if)#no ip hold-time eigrp 100 34
R3(config-if)#ip hold-time eigrp 100 35
R3(config-if)#no ip next-hop-self eigrp 100
*Mar  2 04:21:43.750: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is down: next_hop_self value changed
*Mar  2 04:21:44.687: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is down: Interface Goodbye received
R3(config-if)#no ip
*Mar  2 04:21:48.061: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is up: new adjacency
R3(config-if)#no ip split eigrp 100
R3(config-if)#
*Mar  2 04:21:57.176: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel0) is resync: split horizon changed
R3(config-if)#

So from looking at the output, of course I run into another bug:

R2(config)#no crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
R2(config)#crypto isakmp key cisco123
% Incomplete command.

R2(config)#crypto isakmp key cisco123 ?
% Unrecognized command
R2(config)#crypto isakmp key cisco123

So here is a dump of R1’s “debug ip pack” for later dissection, I will be doing a “wr er” on these routers and try not to let this weird behavior drive me nuts 🙂 And on the next lab, we shall have a BRAND NEW TOPOLOGY (I know, I’m excited too) that looks like it would be a ROAS (Router On A Stick) setup which it very well could be, but we will be configuring VRF!

(I will circle back around to DMVPN when I can dedicate more time to studying the materials for it, but this will be the end of DMVPN for now).

See you on the next one, and this debug dump is for my future inspection, so feel free not to look at unless you are curious:

R1#debug ip pack
IP packet debugging is on
R1#
*Mar  1 19:00:25.227: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:25.227: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:25.227: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:25.423: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:25.423: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:25.423: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:26.332: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 69, sending broad/multicast
*Mar  1 19:00:26.332: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:26.332: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 93, sending
*Mar  1 19:00:26.336: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is down: retry limit
R1# exceeded
*Mar  1 19:00:26.461: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:26.461: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:26.461: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:26.465: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
*Mar  1 19:00:26.469: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:26.469: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:26.469: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:26.477: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:26.477: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
*Mar  1 19:00:27.374: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
*Mar  1 19:00:27.374: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
R1#
R1#
*Mar  1 19:00:28.476: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:28.476: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
R1#
*Mar  1 19:00:29.986: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:29.986: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:29.986: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
R1#
*Mar  1 19:00:31.040: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:31.040: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:31.040: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:31.112: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:31.112: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:31.112: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:31.477: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
R1#
*Mar  1 19:00:31.477: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
*Mar  1 19:00:31.781: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
*Mar  1 19:00:31.781: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
*Mar  1 19:00:32.082: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 339, rcvd 2
*Mar  1 19:00:32.362: IP: s=172.12.123.1 (local), d=224.0.0.10 (Serial0/0), len 60, sending broad/multicast
R1#
*Mar  1 19:00:34.943: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:34.943: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:34.943: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:35.507: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:35.507: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:35.507: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
R1#
*Mar  1 19:00:35.956: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:35.956: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:35.956: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:35.976: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:35.976: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
*Mar  1 19:00:36.080: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 339, rcvd 2
*Mar  1 19:00:36.685: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
R1#
*Mar  1 19:00:36.685: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
R1#
*Mar  1 19:00:39.666: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:39.666: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:39.666: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:39.939: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:39.939: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:39.939: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:40.079: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 339, rcvd 2
R1#
*Mar  1 19:00:40.660: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:40.660: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:40.660: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:40.976: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:40.976: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
*Mar  1 19:00:41.361: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
*Mar  1 19:00:41.361: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
R1#
*Mar  1 19:00:44.214: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:44.214: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:44.214: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:44.498: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:44.498: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:44.498: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:45.123: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
R1#
*Mar  1 19:00:45.123: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:45.123: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:45.780: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
*Mar  1 19:00:45.780: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
*Mar  1 19:00:45.977: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:45.977: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed
R1#
*Mar  1 19:00:48.725: IP: tableid=0, s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:48.725: IP: s=172.12.123.2 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:48.725: IP: s=10.0.0.2 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
*Mar  1 19:00:49.154: IP: tableid=0, s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), routed via RIB
*Mar  1 19:00:49.154: IP: s=172.12.123.3 (Serial0/0), d=172.12.123.1 (Serial0/0), len 84, rcvd 3
*Mar  1 19:00:49.154: IP: s=10.0.0.3 (Tunnel0), d=224.0.0.10, len 60, rcvd 0
R1#
*Mar  1 19:00:49.731: IP: s=10.0.0.1 (local), d=224.0.0.10 (Tunnel0), len 60, sending broad/multicast
*Mar  1 19:00:49.731: IP: tableid=0, s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), routed via FIB
*Mar  1 19:00:49.731: IP: s=172.12.123.1 (local), d=172.12.123.3 (Serial0/0), len 84, sending
*Mar  1 19:00:50.079: IP: s=0.0.0.0 (FastEthernet0/1), d=255.255.255.255, len 339, rcvd 2
R1#
*Mar  1 19:00:50.756: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback1), len 60, sending broad/multicast
*Mar  1 19:00:50.756: IP: s=1.1.1.1 (Loopback1), d=224.0.0.10, len 60, rcvd 2
*Mar  1 19:00:50.977: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, sending
*Mar  1 19:00:50.977: IP: s=10.0.0.1 (local), d=10.0.0.2 (Tunnel0), len 40, encapsulation failed

DMVPN – Theory, explanations, and illustrations! (Lab coming up next post)

dmvpn_1

So I have not been posting over the weekend, however I haven’t been slacking either. What I am going to post today is going to be a mixture of information from Chris Bryant’s 8 minute DMVPN video, and the few parts I watched from the 8 hours of INE CCNP DMVPN training.

INE really goes over the entire history of it, which I do intend to do as well, but right now I need to finish one study material first (Bryant) before filling the gaps.

So because my next topic was also very briefly covered (VRF) and I am doing a “wr er” and “reload” on all routers to demonstrate that topic, I will see if I can follow this up with a DMVPN configuration lab tomorrow although I have not gotten the formal training, so it will be off the cuff as they say (whoever they are).

All that being said, lets get into the theory of DMVPN

As can be seen in the upper left-hand corner of the Topology, they Physical and Tunnel addresses are listed for this network, also known as the Overlay and Underlay addresses.

  • Underlay addresses are the IP’s of the physical interfaces of our tunnel addresses
  • Overlay addresses will be the Tunnel’s endpoint IP addresses to Physical IP’s

So that is why I explained it as that right off the bat, so that terminology starts to sink in, the actual network address are the underlay our foundation that the Overlay or tunnel uses to do what it does.

Now, IPSec has one glaring gap in functionality and that is being able to encapsulate multicast packets, which GRE can do, then IPSec re-encapsulates them to encrypt the data and allow for the DMVPN to be not only dynamic but secure.

Speaking of things to start soaking in, there are a couple of key things that I’d like to point out before going deeper into theory, and firstly that DMVPN only needs two protocols technically to run : mGRE and NHRP. Although the tunnels will have no encryption due to IPSec missing from the configuration, which is basically in this day and age ‘required’, it actually isn’t and you need to know that.

So this is what a DMVPN topology model might look like, fully captioned for you:

dmvpn_2

As shown again in the above Topology, it works based off a Client / Server model, where the Spokes of our Hub-and-Spoke Topology is are the NHRP Client or NHC’s, and the Hub is the NHRP Server or NHC. The Hub also has the Multipoint GRE interface that will be managing tunnel information to its clients.

So you will want to configure the Hub first with both mGRE and NHRP configurations, so when NHRP / Tunnel configs are entered on Spoke routers, the NHC’s will advertise their Overlay / Underlay mapping to the Hub / NHS to put in it’s Database for queries by other DMVPN routers. The Hub should have mGRE running on it’s main outside interface, which will allow the transmission of these Overlay to Underlay mappings.

Speaking of mappings, this is where NHRP comes in, as it creates these overlay to underlay mappings to make the dynamic nature of these VPN’s possible for the NHS to share with it’s NHC’s.

So when the initial configuration is pumped in, this is what it should logically do:

dmvpn_3

So when R2 wants to build a Dynamic tunnel over to R3, it can query the NHS:

dmvpn_4

And now that R2 has the Physical IP to R3, it doesn’t need the Hub to reach it for a VPN:

dmvpn_5

Now, I am skeptical as to how this is going to work, as I will be trying my hand to configure this over a frame switch. However, I will google some commands and we will be taking a deeper dive that just the very top level Fundamentals (and maybe a deep dive down the road), however I need to keep pushing forward with studying new topics cause I tend to get stuck in quicksand topics that I spend forever trying to dig to the bottom of.

VRF and VRF Lite were also very lightly explained so that lends me some time this week to try my hand at a free style DMVPN config tomorrow, and that it is on to the kryptonite of Cisco material for me : IPv6.

I am hoping it isn’t going to be a lot of memorization as it was at the CCNA level, and we can do some labs with it, but we shall see. So I will set my routers R1, R2, and R3 up only for the next lab and we shall see what happens, hope to see you there! 🙂