DMVPN uses multipoint GRE (Generic Routing Encapsulation) tunnel interfaces. We can use GRE to encapsulate multiple protocols, including IPv6.
This allows us to run IPv6 on our DMVPN tunnel interfaces while using IPv4 (or IPv6) on the underlay network. In this lesson I’ll show you how to run DMVPN IPv6 over an IPv4 underlay network.
Here’s the topology we will use:
Above we have a hub and two spoke routers. The underlay network uses IPv4 and subnet 192.168.123.0/24. On the tunnel interfaces we will use 2001:DB8::/64.
Before we start working on the DMVPN configuration, let’s make sure the underlay network is up and running:
Hub#ping 192.168.123.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
Hub#ping 192.168.123.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/4 ms
No issues there, the hub can ping both spoke routers. Let’s take a look at the tunnel interfaces…
The configuration above is pretty much the same as for IPv4, there are a few differences:
We map the IPv6 tunnel address to the IPv4 NBMA address of the hub router.
We map multicast traffic to the IPv4 NBMA address of the hub router.
The NHS server is the IPv6 address on the tunnel interface of our hub router.
We are using GRE multipoint on the spoke router which makes it a DMVPN phase 2 network. The spoke2 router will use the exact same configuration as spoke1 but we use another IPv6 address:
Let’s verify our work, first we’ll check if the hub router has NHRP registrations:
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, IPv6 NHRP Details
Type:Hub, Total NBMA Peers (v4/v6): 2
1.Peer NBMA Address: 192.168.123.2Tunnel IPv6 Address: 2001:DB8::2
IPv6 Target Network: 2001:DB8::2/128
# Ent: 1, Status: UP, UpDn Time: 00:00:58, Cache Attrib: D
2.Peer NBMA Address: 192.168.123.3Tunnel IPv6 Address: 2001:DB8::3
IPv6 Target Network: 2001:DB8::3/128
# Ent: 1, Status: UP, UpDn Time: 00:00:56, Cache Attrib: D
Above you can see the two NHRP registrations from the spoke routers. We see the IPv4 NBMA addresses and the IPv6 tunnel addresses. Below you can see the NHRP registration request in wireshark:
And here’s the reply from the hub:
Let’s make sure that the tunnels are working, we’ll send some quick pings from the hub to the spoke routers:
Hub#ping 2001:DB8::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/10 ms
Hub#ping 2001:DB8::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/6/6 ms
Excellent these pings are working. What about spoke-to-spoke traffic?
Spoke1#ping 2001:DB8::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms
No problem, this is also working!
We now have a basic DMVPN IPv6 Phase 2 configuration that you can use to practice with some of the IPv6 routing protocols.
Want to take a look at the NHRP IPv6 registration packets? You can find them here:
hostname Hub
!
interface Tunnel0
no ip address
no ip redirects
ipv6 address 2001:DB8::1/64
ipv6 nhrp authentication DMVPN
ipv6 nhrp map multicast dynamic
ipv6 nhrp network-id 1
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
end
hostname Spoke1
!
interface Tunnel0
no ip address
no ip redirects
ipv6 address 2001:DB8::2/64
ipv6 nhrp authentication DMVPN
ipv6 nhrp map 2001:DB8::1/128 192.168.123.1
ipv6 nhrp map multicast 192.168.123.1
ipv6 nhrp network-id 1
ipv6 nhrp nhs 2001:DB8::1
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.2 255.255.255.0
duplex auto
speed auto
media-type rj45
!
end
hostname Spoke2
!
interface Tunnel0
no ip address
no ip redirects
ipv6 address 2001:DB8::3/64
ipv6 nhrp authentication DMVPN
ipv6 nhrp map 2001:DB8::1/128 192.168.123.1
ipv6 nhrp map multicast 192.168.123.1
ipv6 nhrp network-id 1
ipv6 nhrp nhs 2001:DB8::1
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.3 255.255.255.0
duplex auto
speed auto
media-type rj45
!
end
Conclusion
The configuration of DMVPN IPv6 over IPv4 is pretty much the same as using IPv4 everywhere. The main difference is that you have to use the “ipv6 nhrp” command instead of “ip nhrp” and you need to map the correct addresses.
I hope you enjoyed this lesson, if you have any questions feel free to leave a comment!
In a DMVPN network it’s likely that your spoke routers are connected using a variety of connections. You might be using DSL, cable or wireless connections on different sites.
With all these different connections, it’s not feasible to use a single QoS policy and apply it to all spoke routers. You also don’t want to create a unique QoS policy for each router if you have hundreds of spoke routers.
Per-Tunnel QoS allows us to create different QoS policies and we can apply them to different NHRP “groups”. Multiple spoke routers can be assigned to the same group but each router will be individually measured.
For example, let’s say we have 300 spoke routers:
100 spoke routers connected through DSL (1 Mbps).
100 spoke routers connected through Cable (5 Mbps).
100 spoke routers connected through Wireless (2 Mbps).
In this case we can create three QoS policies, one for DSL, cable and wireless. In each QoS policy we will configure the correct shaping rate so our spoke routers don’t get overburdened with traffic. When we apply one of the QoS policies, traffic to each spoke router will be shaped to the correct rate.
Let’s take a look at the configuration so you can see how this works…
Configuration
To demonstrate DMVPN Per-Tunnel QoS I will use the following topology:
Above we have a hub and four spoke routers. Let’s imagine that the spoke1 and spoke2 routers are connected using a 5 Mbps link, the spoke3 and spoke4 routers are using a slower 1 Mbps link.
Our DMVPN network is used for VoIP traffic so our QoS policy should have a priority queue for RTP traffic.
We use subnet 192.168.123.0/24 as the “underlay” network and 172.16.123.0/24 as the “overlay” (tunnel) network.
The DMVPN network is used for VoIP traffic
Let’s start with a basic DMVPN phase 2 configuration. Here’s the configuration of the hub router:
Hub#
interface Tunnel0
ip address 172.16.123.1 255.255.255.0
ip nhrp authentication DMVPN
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source GigabitEthernet0/1
tunnel mode gre multipointend
And here’s the configuration of one spoke router:
Spoke1#
interface Tunnel0
ip address 172.16.123.2 255.255.255.0
ip nhrp authentication DMVPN
ip nhrp map 172.16.123.1 192.168.123.1
ip nhrp map multicast 192.168.123.1
ip nhrp network-id 1
ip nhrp nhs 172.16.123.1
tunnel source GigabitEthernet0/1
tunnel mode gre multipointend
The configuration above is the same on all spoke routers except for the IP address.
Let’s start with the hub configuration…
Hub Configuration
Let’s create a class-map and policy-map that gives priority to VoIP traffic:
Hub(config)#class-map VOIP
Hub(config-cmap)#match protocol rtp
I’ll use NBAR to identify our RTP traffic. Here’s the policy-map:
Hub(config)#policy-map PRIORITY
Hub(config-pmap)#class VOIP
Hub(config-pmap-c)#priority percent 20
In the policy-map we will create a priority queue for 20 percent of the interface bandwidth. Instead of applying this policy-map to an interface, we’ll create two more policy-maps. The first one will be for our spoke routers that are connected through the 1 Mbps connections:
Hub(config)#policy-map SHAPE_1M
Hub(config-pmap)#class class-default
Hub(config-pmap-c)#shape average 1m
Hub(config-pmap-c)#service-policy PRIORITY
In the policy-map above called “SHAPE_1M” we shape all traffic in the class-default class-map to 1 Mbps. Within the shaper, we apply the policy map that creates a priority queue for 20% of the bandwidth. 20% of 1 Mbps is 200 kbps.
Let’s create the second policy-map for our spoke routers that are connected through a 5 Mbps connection:
Hub(config)#policy-map SHAPE_5M
Hub(config-pmap)#class class-default
Hub(config-pmap-c)#shape average 5M
Hub(config-pmap-c)#service-policy PRIORITY
The policy-map is the same except that it will shape up to 5 Mbps. The priority queue will get 20% of 5 Mbps which is 1 Mbps.
We have our policy-maps but we still have to apply them somehow. We don’t apply them to an interface but we will map them to NHRP groups:
Hub(config)#interface Tunnel 0
Hub(config-if)#nhrp ?
attribute NHRP attribute
event-publisher Enable NHRP smart spoke feature
group NHRP group name
map Map group name to QoS service policy
route-watch Enable NHRP route watch
On the tunnel interface we can use the nhrp map command. Take a look below:
Hub(config-if)#nhrp map ?
group NHRP group mapping
Let’s use the group parameter:
Hub(config-if)#nhrp map group ?
WORD NHRP group name
Now you can specify a NHRP group name. You can use any name but to keep it simple, it’s best to use the same name as the policy-maps that we created earlier:
Hub(config-if)#nhrp map group SHAPE_1M ?
service-policy QoS service-policy
The only thing left to do is to attach the NHRP group to the policy-map:
Hub(config-if)#nhrp map group SHAPE_1M service-policy output SHAPE_1M
We now have a NHRP group called “SHAPE_1M” that is attached to our policy-map “SHAPE_1M”. Let’s do the same thing for our second policy-map:
Hub(config-if)#nhrp map group SHAPE_5M service-policy output SHAPE_5M
That’s all we have to do on the hub router.
Spoke Configuration
The only thing left to do is to configure the spoke routers with the correct NHRP group:
Spoke1 & Spoke2
(config)#interface Tunnel 0
(config-if)#nhrp group SHAPE_1M
Spoke3 & Spoke4
(config)#interface Tunnel 0
(config-if)#nhrp group SHAPE_5M
When the spoke routers register themselves with the hub through NHRP, they will include the NHRP group that they want to use.
To see this in action, let’s bounce all the tunnel interfaces. I’ll start with the hub:
Great, this completes our configuration. Let’s verify our work.
Verification
The first thing we should check is if the spoke routers registered themselves with the hub:
Hub#show dmvpn detail
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 is up/up, Addr. is 172.16.123.1, VRF ""
Tunnel Src./Dest. addr: 192.168.123.1/MGRE, Tunnel VRF ""
Protocol/Transport: "multi-GRE/IP", Protect ""
Interface State Control: Disabled
nhrp event-publisher : Disabled
Type:Hub, Total NBMA Peers (v4/v6): 4
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network
----- --------------- --------------- ----- -------- ----- -----------------
1 192.168.123.2 172.16.123.2 UP 00:01:02 D 172.16.123.2/32
NHRP group: SHAPE_1MOutput QoS service-policy applied: SHAPE_1M
1 192.168.123.3 172.16.123.3 UP 00:00:56 D 172.16.123.3/32
NHRP group: SHAPE_1MOutput QoS service-policy applied: SHAPE_1M
1 192.168.123.4 172.16.123.4 UP 00:00:53 D 172.16.123.4/32
NHRP group: SHAPE_5MOutput QoS service-policy applied: SHAPE_5M
1 192.168.123.5 172.16.123.5 UP 00:00:49 D 172.16.123.5/32
NHRP group: SHAPE_5MOutput QoS service-policy applied: SHAPE_5M
When you use show dmvpn detail, you can see the NHRP groups and the policy-maps.
Here’s what the NHRP registration looks like in wireshark. Here’s a capture of the spoke1 router:
Above you can see the “data” field. That’s the NHRP group in hexadecimal:
Data: 010853484150455f314d
Use your favorite hex-to-ascii tool to convert it and you get “SHAPE_1M”.
We can also see the NHRP group in the NHRP registration reply from the hub to the spoke router:
Above we can see that our traffic matches the class-map and ends up in the priority queue.
hostname Hub
!
class-map match-all VOIP
match protocol rtp
!
policy-map PRIORITY
class VOIP
priority percent 20
policy-map SHAPE_1M
class class-default
shape average 1000000
service-policy PRIORITY
policy-map SHAPE_5M
class class-default
shape average 5000000
service-policy PRIORITY
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Tunnel0
ip address 172.16.123.1 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map multicast dynamic
ip nhrp network-id 1
nhrp map group SHAPE_1M service-policy output SHAPE_1M
nhrp map group SHAPE_5M service-policy output SHAPE_5M
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.1 255.255.255.0
duplex auto
speed auto
media-type rj45
no cdp enable
!
end
hostname Spoke1
!
interface Tunnel0
ip address 172.16.123.2 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 172.16.123.1 192.168.123.1
ip nhrp map multicast 192.168.123.1
ip nhrp network-id 1
ip nhrp nhs 172.16.123.1
nhrp group SHAPE_1M
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.2 255.255.255.0
duplex auto
speed auto
media-type rj45
no cdp enable
!
end
hostname Spoke2
!
interface Tunnel0
ip address 172.16.123.3 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 172.16.123.1 192.168.123.1
ip nhrp map multicast 192.168.123.1
ip nhrp network-id 1
ip nhrp nhs 172.16.123.1
nhrp group SHAPE_1M
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.3 255.255.255.0
duplex auto
speed auto
media-type rj45
no cdp enable
!
end
hostname Spoke3
!
interface Tunnel0
ip address 172.16.123.4 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 172.16.123.1 192.168.123.1
ip nhrp map multicast 192.168.123.1
ip nhrp network-id 1
ip nhrp nhs 172.16.123.1
nhrp group SHAPE_5M
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.4 255.255.255.0
duplex auto
speed auto
media-type rj45
no cdp enable
!
end
hostname Spoke4
!
interface Tunnel0
ip address 172.16.123.5 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 172.16.123.1 192.168.123.1
ip nhrp map multicast 192.168.123.1
ip nhrp network-id 1
ip nhrp nhs 172.16.123.1
nhrp group SHAPE_5M
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
!
interface GigabitEthernet0/1
ip address 192.168.123.5 255.255.255.0
duplex auto
speed auto
media-type rj45
no cdp enable
!
end
Conclusion
You have now learned how to create NHRP groups and how to attach QoS policies to them. This is a scalable method to deploy QoS policies for all of your spoke routers.
Want to take a look at the wireshark capture yourself? You can find it here:
In our first DMVPN lesson we talked about the basics of DMVPN and its different phases. DMVPN is a “routing technique” that relies on multipoint GRE and NHRP and IPsec is not mandatory.
However since you probably use DMVPN with the Internet as the underlay network, it might be wise to encrypt your tunnels. In this lesson I’ll show you how to configure IPsec to encrypt your multipoint GRE tunnels. Here’s the topology we will use:
Above we have a hub and spoke topology which I used in all of my previous DMVPN examples. We’ll use a DMVPN phase 2 network with RIP as the routing protocol to test IPsec.
Configuration
Tunnel Interfaces
Let’s start with the tunnel interfaces on all routers. This is a basic DMVPN phase 2 configuration:
That should do it. Now before we start messing around with IPsec, we should check if everything is working without encryption. Let’s check if the hub router has two NHRP registrations:
Hub#show dmvpn | begin Peer
Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.123.2 172.16.123.2 UP 00:06:15 D
1 192.168.123.3 172.16.123.3 UP 00:06:22 D
That’s looking good. Do we have some RIP routes?
Hub#show ip route rip
2.0.0.0/32 is subnetted, 1 subnets
R 2.2.2.2 [120/1] via 172.16.123.2, 00:00:02, Tunnel0
3.0.0.0/32 is subnetted, 1 subnets
R 3.3.3.3 [120/1] via 172.16.123.3, 00:00:11, Tunnel0
Spoke1#show ip route rip
1.0.0.0/32 is subnetted, 1 subnets
R 1.1.1.1 [120/1] via 172.16.123.1, 00:00:07, Tunnel0
3.0.0.0/32 is subnetted, 1 subnets
R 3.3.3.3 [120/2] via 172.16.123.3, 00:00:07, Tunnel0
Spoke2#show ip route rip
1.0.0.0/32 is subnetted, 1 subnets
R 1.1.1.1 [120/1] via 172.16.123.1, 00:00:28, Tunnel0
2.0.0.0/32 is subnetted, 1 subnets
R 2.2.2.2 [120/2] via 172.16.123.2, 00:00:28, Tunnel0
Yes we do! Everything is looking good so now we can focus on encryption.
IPsec
IPsec has two phases, phase 1 and 2 (don’t confuse them with the DMVPN phases).
Phase 1
We need an ISAKMP policy that matches on all our routers. Let’s pick something:
When it comes to encryption we can choose between pre-shared keys or PKI. To keep it simple, I’ll go for the pre-shared keys:
Hub(config)#crypto isakmp key DMVPN_KEY address ?
A.B.C.D Peer IP address
ipv6 define shared key with IPv6 address
When you configure the pre-shared key you have to enter the NBMA address. Keep in mind that encryption occurs before multipoint GRE / NHRP. We also have to specify a peer address, we have two options here:
Configure a pre-shared key for each “router pair” you have: this means we use a unique key for hub-spoke1, hub-spoke2 and spoke1-spoke2. This is secure but it’s not a very scalable solution, the more spoke routers we add to the network, the more keys we have to configure.
Configure a “wildcard” pre-shared key: this allows us to use a single key for all routers. This is the most convenient but it also means that if you want to change the key, you have to do it on all your routers.
I’ll use the wildcard pre-shared key for our example:
I’ll go for ESP with AES as the encryption algorithm and SHA for hashing. The mode is important, since we are using GRE we are already using tunnels so we can use transport mode. If you use tunnel mode then we will have even more overhead which is not required.
To apply the transform set on our tunnel interfaces we need to create a profile:
Everything is now in place. Let’s test drive this setup
Verification
IPsec occurs before multipoint GRE and NHRP. To test if everything is working properly we should go for a fresh start. I’ll shut all the interfaces on our routers:
Let’s check if the spoke routers were able to register again with the hub:
Hub#show dmvpn | begin Peer
Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.123.2 172.16.123.2 UP 00:02:35 D
1 192.168.123.3 172.16.123.3 UP 00:00:19 D
No problem at all…do we still have RIP routes?
Hub#show ip route rip
2.0.0.0/32 is subnetted, 1 subnets
R 2.2.2.2 [120/1] via 172.16.123.2, 00:00:02, Tunnel0
3.0.0.0/32 is subnetted, 1 subnets
R 3.3.3.3 [120/1] via 172.16.123.3, 00:00:11, Tunnel0
Spoke1#show ip route rip
1.0.0.0/32 is subnetted, 1 subnets
R 1.1.1.1 [120/1] via 172.16.123.1, 00:00:07, Tunnel0
3.0.0.0/32 is subnetted, 1 subnets
R 3.3.3.3 [120/2] via 172.16.123.3, 00:00:07, Tunnel0
Spoke2#show ip route rip
1.0.0.0/32 is subnetted, 1 subnets
R 1.1.1.1 [120/1] via 172.16.123.1, 00:00:28, Tunnel0
2.0.0.0/32 is subnetted, 1 subnets
R 2.2.2.2 [120/2] via 172.16.123.2, 00:00:28, Tunnel0
That’s also looking good. Let’s take a closer look at some of the IPsec show commands:
Hub#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.123.1 192.168.123.3 QM_IDLE 1008 ACTIVE
192.168.123.1 192.168.123.2 QM_IDLE 1007 ACTIVE
Spoke1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.123.1 192.168.123.2 QM_IDLE 1004 ACTIVE
Spoke2#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.123.1 192.168.123.3 QM_IDLE 1004 ACTIVE
As you can see above there are only two IPsec tunnels:
Hub to spoke1
Hub to spoke2
At this moment there is no IPsec tunnel from spoke1 to spoke2. This makes sense since there hasn’t been any traffic between the spoke routers. Let’s see what traffic is actually being encrypted, here’s an example for traffic between the hub and spoke1 router:
Hub#show crypto ipsec sa peer 192.168.123.2
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 192.168.123.1
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.123.1/255.255.255.255/47/0)remote ident (addr/mask/prot/port): (192.168.123.2/255.255.255.255/47/0)current_peer 192.168.123.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 17, #pkts encrypt: 17, #pkts digest: 17
#pkts decaps: 15, #pkts decrypt: 15, #pkts verify: 15
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 192.168.123.1, remote crypto endpt.: 192.168.123.2
plaintext mtu 1426, path mtu 1476, ip mtu 1476, ip mtu idb Tunnel0
current outbound spi: 0x87C9B200(2278142464)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x1150FD74(290520436)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 9, flow_id: SW:9, sibling_flags 80000000, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4288279/3285)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x87C9B200(2278142464)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 10, flow_id: SW:10, sibling_flags 80000000, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4288278/3285)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
Above we can see that traffic between 192.168.123.1 and 192.168.123.2 is encrypted. The “47” that you see is the protocol, GRE in our example. We can also see that we are using transport mode.
Now let’s send a ping from spoke1 to spoke2:
Spoke1#ping 3.3.3.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/41/59 ms
Our ping is working, behind the scenes our two spoke routers will establish an IPsec tunnel. You can the security association below:
Spoke1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.123.2 192.168.123.3 QM_IDLE 1006 ACTIVE
192.168.123.1 192.168.123.2 QM_IDLE 1004 ACTIVE
192.168.123.3 192.168.123.2 QM_IDLE 1005 ACTIVE
Spoke2#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.123.1 192.168.123.3 QM_IDLE 1004 ACTIVE
192.168.123.3 192.168.123.2 QM_IDLE 1005 ACTIVE
192.168.123.2 192.168.123.3 QM_IDLE 1006 ACTIVE
And we can see how many packets have been encrypted between spoke1 and spoke2:
Spoke1#show crypto ipsec sa peer 192.168.123.3
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 192.168.123.2
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.123.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (192.168.123.3/255.255.255.255/47/0)
current_peer 192.168.123.3 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 192.168.123.2, remote crypto endpt.: 192.168.123.3
plaintext mtu 1426, path mtu 1476, ip mtu 1476, ip mtu idb Tunnel0
current outbound spi: 0x2C6A6B7B(745171835)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x2375C852(594921554)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 7, flow_id: SW:7, sibling_flags 80004000, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4608000/3474)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
spi: 0xCD7F7ED0(3447684816)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 9, flow_id: SW:9, sibling_flags 80000000, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4608000/3474)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
spi: 0xCF0A21D9(3473547737)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 11, flow_id: SW:11, sibling_flags 80000000, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4301724/3484)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xE2EBC457(3807102039)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 8, flow_id: SW:8, sibling_flags 80004000, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4608000/3474)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
spi: 0xCE677AEE(3462888174)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 10, flow_id: SW:10, sibling_flags 80000000, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4608000/3474)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
spi: 0x2C6A6B7B(745171835)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 12, flow_id: SW:12, sibling_flags 80000000, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4301724/3484)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
That’s looking good. If you are curious to see what a packet looks like, here’s a protected capture in wireshark:
Here’s the capture file if you want to see it for yourself:
hostname Hub
!
crypto isakmp policy 10
encr aes
hash sha256
authentication pre-share
group 5
crypto isakmp key DMVPN_KEY address 0.0.0.0
!
crypto ipsec transform-set DMVPN_TRANSFORM esp-aes esp-sha-hmac
mode transport
!
crypto ipsec profile DMVPN_PROFILE
set transform-set DMVPN_TRANSFORM
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Tunnel0
ip address 172.16.123.1 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map multicast dynamic
ip nhrp network-id 1
no ip split-horizon
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN_PROFILE
!
interface GigabitEthernet0/1
ip address 192.168.123.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router rip
version 2
network 1.0.0.0
network 172.16.0.0
no auto-summary
!
end
hostname Spoke1
!
crypto isakmp policy 10
encr aes
hash sha256
authentication pre-share
group 5
crypto isakmp key DMVPN_KEY address 0.0.0.0
!
crypto ipsec transform-set DMVPN_TRANSFORM esp-aes esp-sha-hmac
mode transport
!
crypto ipsec profile DMVPN_PROFILE
set transform-set DMVPN_TRANSFORM
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Tunnel0
ip address 172.16.123.2 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 172.16.123.1 192.168.123.1
ip nhrp map multicast 192.168.123.1
ip nhrp network-id 1
ip nhrp nhs 172.16.123.1
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN_PROFILE
!
interface GigabitEthernet0/1
ip address 192.168.123.2 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router rip
version 2
network 2.0.0.0
network 172.16.0.0
no auto-summary
!
end
hostname Spoke2
!
crypto isakmp policy 10
encr aes
hash sha256
authentication pre-share
group 5
crypto isakmp key DMVPN_KEY address 0.0.0.0
!
crypto ipsec transform-set DMVPN_TRANSFORM esp-aes esp-sha-hmac
mode transport
!
crypto ipsec profile DMVPN_PROFILE
set transform-set DMVPN_TRANSFORM
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Tunnel0
ip address 172.16.123.3 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 172.16.123.1 192.168.123.1
ip nhrp map multicast 192.168.123.1
ip nhrp network-id 1
ip nhrp nhs 172.16.123.1
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN_PROFILE
!
interface GigabitEthernet0/1
ip address 192.168.123.3 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router rip
version 2
network 3.0.0.0
network 172.16.0.0
no auto-summary
!
end
Conclusion
Once you understand DMVPN, adding IPsec is pretty simple.
The only problem with this implementation is scalability. Our hub router will have a security association with each spoke router so if you have a large network, that’ll put quite some burden on the hub router.
One solution is to implement DMVPN over GETVPN (Group Encrypted Transport).
GETVPN is a “any to any” VPN where we use the same encryption and decryption for all routers which means the hub doesn’t need an unique security association with each spoke router. This is something we’ll look at in another lesson though.
I hope you enjoyed this lesson, if you have any questions feel free to leave a comment!
