- “Do I Know This Already?” Quiz
- Foundation Topics
- DMVPN Overview
- DVMPN Network Components
- DMVPN Design Considerations
- DMVPN Phase 1 Hub-and-Spoke Implementation
- DMVPN Phase 2 Spoke-to-Spoke Implementation
- DMVPN Phase 3 Spoke-to-Spoke Implementation
- DMVPN Troubleshooting
- Summary
- References
- Exam Preparation Tasks
- Review All Key Topics
- Complete Tables and Lists from Memory
- Define Key Terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
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