When Cisco introduced the new IKE (IKEv2) and the new unified configuration for all types of VPN (excluding GET VPN), they also updated the DMVPN. The new version (phase 4 - but I’m not sure if it is official name) spoke-to-spoke has changed many things. There is no more point-to-multipoint tunnels. For spoke-to-hub connection you have to configure a tunnel interface (for each hub in case you have more than one) on your spoke routers. For spoke-to-spoke communication you need to create a virtual-template and every time the new connection will be built, based on this template, the new, dynamic interface will be created.

In my configuration I will use as much default settings as it is possible. Let’s start with the hub configuration.

I enable following ikev2 settings on all routers (hub and spoke):

default crypto ikev2 proposal
default crypto ikev2 policy
default crypto ipsec

I would like to share with you very useful commands which can helpful you during your troubleshooting. Instead of checking (sometimes very long) configuration, you can check/compare the same block of configuration between your peers.

1) ikev2 proposal

r5sh crypto ikev2 proposal
 IKEv2 proposal: IKEV2-PROPOSAL
     Encryption : AES-CBC-128
     Integrity  : SHA512
     PRF        : SHA512
     DH Group   : DH_GROUP_1536_MODP/Group 5
 IKEv2 proposal: default
     Encryption : AES-CBC-256 AES-CBC-192 AES-CBC-128
     Integrity  : SHA512 SHA384 SHA256 SHA96 MD596
     PRF        : SHA512 SHA384 SHA256 SHA1 MD5
     DH Group   : DH_GROUP_1536_MODP/Group 5 DH_GROUP_1024_MODP/Group 2
r5

From above output you can learn about all available ikev2 proposals. As you see there is one proposal default. You can use it in your config but you can also disable it:

r5(config)no crypto ikev2 proposal

It’s time to test IKEv2. Cisco introduced the new IKE version 2 together with new configuration “standard” - FlexVPN. The idea was to have one unified way of configuration for all VPN types like site-to-site, client server, DMVPN (GET VPN is still in development phase).

You should remember the IKEv1 and IKEv2 are not compatible and devices with different IKE versions can’t establish a secure connection. More information about IKEv2 and the FlexiVPN you can find here:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/xe-3s/sec-flex-vpn-xe-3s-book.html

In today’s lab I would like to configure client-server VPN. Let’s start from parts which are common for the client and the server:

1) ikev2 proposal

Like with IKEv1 you need to specify parameters for the phase 1. You can use default ones or you can define your own:

crypto ikev2 proposal IKEV2-PROPOSAL

Today I would like to test an integration of DMVPN and GET VPN technologies. DMVPN can be used over the public network like Internet and GET VPN only over private like MPLS (because of IP preservation).

As you remember from my previous posts about DMVPN the best option is the phase 3. With thousands of spokes your hub has to keep the same number of SAs (security association).

As you remember, for the phase 3, the first packet was sent to the hub and then was redirected (NHRP) to the destination. Next packets were sent directly to the spoke:

R2traceroute 100.33.33.33 source 100.22.22.22

Type escape sequence to abort.
Tracing the route to 100.33.33.33

  1 10.10.10.1 40 msec 56 msec 76 msec
  2 10.10.10.3 104 msec 88 msec 140 msec
R2 



R2traceroute 100.33.33.33 source 100.22.22.22

Type escape sequence to abort.
Tracing the route to 100.33.33.33

  1 10.10.10.3 104 msec 104 msec 72

Today I’m going to test a phase 3 with EIGRP. To present all differences, pros, cons I have changed LAN’s IP addresses ( I strongly recommend to read my previous posts about different variances of DMVPN) :

Before I start configuring the phase 3 I would like to show some limitations of the phase 2. As you know for phase 2 we can’t summarize what means every spoke needs to keep all spoke routers in its routing table to be able to establish spoke-to-spoke communication.

Let’s test it on my example:

R1:

!
interface Loopback0
 ip address 100.11.11.11 255.255.255.0
!
router eigrp 1
 network 10.10.10.0 0.0.0.255
 network 100.11.11.0 0.0.0.255
 no auto-summary
!

R2:

!
interface Loopback0
 ip address 100.22.22.22 255.255.255.0
!
router eigrp 1
 network 10.10.10.0 0.0.0.255
 network 100.22.22.0 0.0.0.255
 no auto-summary
!

R3:

!
interface Loopback0
 ip address 100.33.33.33

The phase two allows me on spoke-to-spoke communication. Please read my previous post (EIGRP phase one): http://myitmicroblog.svbtle.com/dmvpn-phase-one-eigrp

You should know the phase two is not recommended because the phase three solves many issues like scalability. I will describe the differences between them in my next post.

From the configuration perspective I need to change:

R1 (hub):

interface Tunnel0
  no ip next-hop-self eigrp 1

Let’s check the settings on R2 before we send traffic:

R2sh ip route eigrp
     33.0.0.0/24 is subnetted, 1 subnets
D       33.33.33.0 [90/310172416] via 10.10.10.3, 00:22:35, Tunnel0
D    11.0.0.0/8 [90/297372416] via 10.10.10.1, 00:22:37, Tunnel0
R2

As you see the next hop for Lan3 (33.33.33.33) is R3 not R1 like with the phase one.

R2sh ip nhrp
10.10.10.1/32 via 10.10.10.1, Tunnel0 created 01:40:18, never expire
  Type: static, Flags: nat

Today I would like to implement DMVPN with EIGRP. This protocol is very popular because of its scalability. Please read this post before you start because I’m not going to implement it from scratch:

http://myitmicroblog.svbtle.com/dmvpn-phase-one-ospf

I assume you have your hub and spoke router configured (IP addressing, hub and spoke configuration, firewall rules).

I have to add following configuration:

R1:

!
router eigrp 1
 network 10.10.10.0 0.0.0.255
 network 11.11.11.0 0.0.0.255
 auto-summary
!
interface Tunnel0
 no ip split-horizon eigrp 1
!

R2:

!
router eigrp 1
 network 10.10.10.0 0.0.0.255
 network 22.22.22.0 0.0.0.255
 no auto-summary
!
interface Tunnel0
 ip address 10.10.10.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication cisco
 ip nhrp map multicast 5.5.5.1
 ip nhrp map 10.10.10.1 5.5.5.1
 ip nhrp network-id 12
 ip nhrp nhs 10.10.10.1
 ip nhrp

The third version of DMVPN is the improved version of phase 2. To be more specific there are two modes of the phase 3: early and new implementation. The main difference between them is not how it works but how you can check what is the real next-hop. The new commands (rather new parameter) is:

sh ip route next-hop-override

You can find there new sub-entries which show you the real next hop. The new version is available on: ASR1K, 15.2(1)T - ISR, 7200 and I don’t have chance to test it (on 7200 even with higher version it didn’t work, there was a problem with NHRP protocol). I was able to test only the early mode on 12.4.

Both versions support spoke-to-spoke communication but the version 3 was improved NHRP shortcut and redirection feature. Let’s do some tests.

R2sh ver | i Ver
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.4(11)T1, RELEASE SOFTWARE (fc5)
...

In my second post about DMVPN and OSPF I would like to change my configuration from my previous post to enable direct communication between spoke routers.

I strongly recommend to read my previous post first before you start reading this one, because I’m not going to configure it from scratch.

https://myitmicroblog.svbtle.com/dmvpn-phase-one-ospf

As you remember, traffic between R2 and R3 is sent through the hub (R1);

R2traceroute 33.33.33.33 source 22.22.22.22
Type escape sequence to abort.
Tracing the route to 33.33.33.33
VRF info: (vrf in name/id, vrf out name/id)
  1 10.10.10.1 92 msec 124 msec 132 msec
  2 10.10.10.3 180 msec 156 msec 180 msec
R2

I need to change following parameters to enable phase two (before was: ip ospf network point-to-multipoint). This is the only one requirements for changing mode from phase 1 to phase 2 (the reason for that is installing new next hope...

Today I would like to start with very known and widely spread technology - Dynamic Multipoint Virtual Private Network (DMVPN). It was invented more than 10 years ago. DMVPN is very popular because it allows us to create point-to-point or full mesh secure connections between many hosts. The main problem with point-to-point VPN is its lack of scalability in terms of configuration management with more than few point-to-point tunnels.
DMVPN is not one protocol, it is collections of protocols, frameworks: IPsec, multipoint GRE (mGRE), Next Hop Resolution Protocol (NHRP).
Let’s look on the below scenario where you can see one hub (for example HQ) and two spokes (branches). You can try to compare it with GET VPN but between them are more differences than similarities. General speaking DMVPN consist of one hub router (it has to have static IP) and many spokes (static IP is not required). From...