Dynamic Multipoint Virtual Private Network (DMVPN)

This chapter is from the book

CCNP Security Virtual Private Networks SVPN 300-730 Official Cert Guide

Learn More Buy

This chapter is from the book

This chapter is from the book 

CCNP Security Virtual Private Networks SVPN 300-730 Official Cert Guide

Learn More Buy

DMVPN Phase 2 Spoke-to-Spoke Implementation

To enable spoke-to-spoke communication, you need to focus on two configuration changes versus what we worked through when deploying a hub-and-spoke DMVPN deployment. First, you need to make sure that the two routers can communicate via IPsec. This means that any spoke that needs to talk to another spoke needs to include an additional crypto isakmp key statement. You also need to enable routing to use the correct next hop IP address. Let’s first look at the IPsec configuration.

IPsec for Spoke-to-Spoke

Example 5-23 shows the addition of extra IPv4 ISAKMP keys on Spoke1. You need to add these keys on both spokes so that they can encrypt and decrypt the traffic when they communicate directly with one another. After adding the second crypto map statement to the Spoke1 router, you need to also add it to the Spoke2 router.

Example 5-23 IPv4 Additional Spoke Crypto Keys

Spoke1(config)# crypto isakmp key TESTKEY address 209.0.2.3
Spoke1(config)# crypto isakmp key TESTKEY address 209.165.202.130 

In IPv6, you do a similar configuration. Example 5-24 shows the addition of extra IPv6 ISAKMP keys on Spoke1.

Example 5-24 IPv6 Additional Spoke Crypto Keys

Spoke1(config)# crypto isakmp key TESTKEY address 2001:db8:aaaa:1::1/64
Spoke1(config)# crypto isakmp key TESTKEY address 2001:db8:cccc:2::2/64 

Spoke-to-Spoke Routing

In spoke-to-spoke routing configuration, spokes do not directly exchange routing information with each other, even though they may be on the same logical subnet (that is tunnel IP address range) with each other. You need to enable a few commands to ensure that routing functions correctly and spokes use the correct next hop IP address.

Example 5-25 expands the EIGRP configuration for spoke-to-spoke communications by resolving the issue of the hub router setting the next hop address to its own IPv4 address.

Example 5-25 IPv4 Additional EIGRP Configuration

HQ-Router(config)# router eigrp 1
HQ-Router(config-router)# no auto-summary
HQ-Router(config-router)# network 10.1.1.0 0.0.0.255
HQ-Router(config-router)# network 192.168.1.0 0.0.0.255
 
HQ-Router(config-router)# interface tunnel 0
HQ-Router(config-router)# no ip split-horizon eigrp 1
HQ-Router(config-router)# no ip next-hop-self eigrp 

Notice the addition of the command no ip next-hop-self eigrp. This command tells the hub router that, when it redistributes the subnets received from one spoke back out to other spokes, it should not replace its own next hop address but should leave the original address provided by the spoke.

IPv6 Spoke-to-Spoke Routing Configuration

The IPv6 spoke-to-spoke routing configuration is not very complex in terms of DMVPN phase 3 support. You only need to add a command to disable the split horizon associated with EIGRP. Example 5-26 also includes the ipv6 summary command to expose some options for simplifying routing tables.

As you can see in Example 5-26, with IPv6 you address the split horizon issue but do not have to address the next-hop-self challenge that occurs in IPv4.

Example 5-26 IPv6 Additional EIGRP Configuration

HQ-Router(config)# interface tunnel 1
HQ-Router(config-if)# no ipv6 split-horizon eigrp 1
HQ-Router(config-if)# ipv6 summary-address eigrp 1 2001:db8:AAAA::/48