- “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 1 Hub-and-Spoke Implementation
Now it is time to dive into DMVPN implementations. The best way to address learning how technology is configured is to break it down into manageable parts. This section shows the implementation of a basic hub-and-spoke DMVPN design for both IPv4 and IPv6 by breaking down the process into four parts. We highly recommend that you understand how each part works as you study DMVPN technology because you will see questions about the different parts of a DMVPN configuration on the SVPN exam. The following are the four parts of a DMVPN configuration:
Crypto IPsec policy configuration
GRE tunnel configuration
NHRP hub-and-spoke configuration
Routing configuration
Breaking down the process into these four parts will make it easier to troubleshoot which part of the configuration is incorrect and which parts are correct. It will also help with identifying wrong answers for questions about specific parts of a DMVPN configuration. For example, if you are dealing with a routing issue, any answer regarding the GRE tunnel configuration could be eliminated.
Figure 5-10 shows the topology and IPv4 design, and Figure 5-11 shows the topology and IPv6 design for the following configuration examples. Use this as a reference for this next section.
)
Figure 5-10 DMVPN IPv4 Solution
)
Figure 5-11 DMVPN IPv6 Solution
Crypto IPsec Policy Configuration
As discussed in earlier chapters, the Internet Key Exchange (IKE) management protocol is primarily used to authenticate IPsec peers. Configuring a crypto IPsec policy can be broken into the following three steps:
Creating an IKE Policy
Creating Pre-shared Key Authentication Credentials
Creating a Profile and Transform Set
This section works through each of these three steps starting with creating an IKE Policy.
Creating an IKE Policy
In Example 5-1, the IKE management protocol is used by the two spoke routers and the hub router to authenticate, negotiate, and distribute IPsec encryption keys. Today, this is optional on some Cisco platforms because there is a default IKE policy; however, your organization may require a more secure policy. In this example, this policy will be repeated on the two remote site routers (spokes) and must match the HQ router policy. Let’s work through each step of the IKE policy configuration. We will break this into steps as well to clearly work through how the configuration is performed.
Example 5-1 shows the basic crypto IKE policy used by all the routers in Figures 5-8 and 5-9.
){kind=link}
){kind=link}
Example 5-1 Creating an IKE Policy
HQ-Router(config)# crypto isakmp policy 10 HQ-Router(config-isakmp)# encryption aes 192 HQ-Router(config-isakmp)# hash sha256 HQ-Router(config-isakmp)# authentication pre-share HQ-Router(config-isakmp)# group 5
The policy shown in Example 5-1 is policy number 10. You can have policies from 1 to 65,535, ordered by priority. If you establish a VPN with another router that does not have a policy matching this one, your router could potentially find another policy that might match the remote side. If, during troubleshooting, you notice that the IKE policy fails to negotiate, the first place to look is at the IKE policy parameters on both routers.
Example 5-1 shows the use of AES-192 encryption and the hash policy SHA-256. Notice in this example that the authentication in use is pre-shared. This means that you are going to have to manually set up authentication keys on all the DMVPN routers. Another option would be to use certificate authority (CA) signatures. The third method for authentication would be to use encrypted nonces. (Both forms of certificate authentication are discussed in Chapter 3.) We recommend that you take the time to learn how to use certificates for authentication because this process is critical for large-scale deployments. By using certificates, you remove the need to keep track of pre-shared keys, which significantly improves security.
Finally, Example 5-1 specifies group 5 for the Diffie-Hellman key algorithm, which uses a 1536-bit modulus, which in turn uses 2048 bits to create a prime and generate numbers as security association (SA) keys. Depending on your router and its IOS version, you might be able to create a more secure solution by increasing the AES encryption to AES-256 with SHA-512. Chapter 7, “Remote Access VPNs,” covers encryption in more detail.
Creating Pre-shared Key Authentication Credentials
The next step is creating a pre-shared key. Example 5-2 shows an implementation of IPv4 pre-shared keys for the two remote spoke routers.
Example 5-2 Creating Pre-shared Key Authentication Credentials, IPv4
HQ-Router(config)# crypto isakmp key TESTKEY address 209.165.201.2 HQ-Router(config)# crypto isakmp key TESTKEY address 209.165.202.130
On the main router, you need to reference the remote site routers or, in this case, the spokes. It is critical that you reference the public IP address of the router or the address that is reachable by the router if you are implementing a DMVPN solution on a private network. The spoke routers at first have just one crypto pre-shared key configuration line. With spoke-to-spoke configuration, this changes, as you’ll see later in this chapter.
Example 5-3 shows an implementation of IPv6 pre-shared keys for the two remote spoke routers.
Example 5-3 Creating Pre-shared Key Authentication Credentials, IPv6
HQ-Router(config)# crypto isakmp key TESTKEY address ipv6 2001:db8:bbbb:2::2/64 HQ-Router(config)# crypto isakmp key TESTKEY address ipv6 2001:db8:cccc:2::2/64
Notice in Example 5-3 that the IPv6 command has similar syntax to the IPv4 command, and both reference the public endpoint IP addresses of the devices that are authenticating.
Example 5-4 shows the IPv4 pre-shared key used by the spoke to authenticate to the hub router.
Example 5-4 Spoke Router Pre-shared Key in IPv4
Spoke1(config)# crypto isakmp key TESTKEY address 192.0.2.3
Similarly, with IPv6, the spoke would reference the public IPv6 address of the hub router. Example 5-5 shows the IPv6 pre-shared key used by the spoke to authenticate to the hub router.
Example 5-5 Spoke Router Pre-shared Key in IPv6
Spoke1(config)# crypto isakmp key TESTKEY address 2001:db8:aaaa:1::1/64
Creating a Profile
Next, you need to create a profile and transform set. Example 5-6 shows the implementation of a profile and transform set, which is the same for IPv4 and IPv6 and the same on both the hub and the spoke.
Example 5-6 Creating a Profile and a Transform Set for IPv4 or IPv6
HQ-Router(config)# crypto ipsec transform-set MYSET esp-aes esp-sha-hmac HQ-Router(cfg-crypto-trans)# mode tunnel HQ-Router(cfg-crypto-trans)# crypto ipsec profile MYIPSECPROFILE HQ-Router(ipsec-profile)# set transform-set MYSET
Notice that these two commands are tied together by the crypto profile referencing the transform set. You will see later how the profile is used by the DMVPN configuration. As discussed in Chapter 3, the transform set is for IKE Phase 2 negotiation of the encrypted tunnel. As with the IKE policy, some IOS versions now include a default transform set, as you can see with the command show crypto ipsec profile in Example 5-7. The key pieces of the transform set are the encryption method, the hash type, and whether Perfect Forward Security (PFS) is used. These must all match except for the security association lifetime. The two sides select the SA lifetime with the smallest size and use that for the tunnel.
In Example 5-7, the command show crypto ipsec profile validates your previous profile configuration steps.
Example 5-7 Output Crypto IPsec Profile
HQ-Router(config)# show crypto ipsec profile
IPSEC profile MYIPSECPROFILE
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): N
Mixed-mode : Disabled
Transform sets={
MYSET: { esp-aes esp-sha-hmac } ,
}
IPSEC profile default
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): N
Mixed-mode : Disabled
Transform sets={
default: { esp-aes esp-sha-hmac } ,
}
Creating a Transform Set
The transform set is a collection of individual IPsec parameters designed to implement the security policy on the traffic that is transmitted across the tunnel. During ISAKMP IPsec security association negotiation, the two routers need to agree on the parameters; if the parameters are not the same, the tunnel setup fails. For example, if one side has transport mode set to AH and the other side only supports ESP, the negotiation will fail.
Example 5-8 shows how to verify the transform set configuration. It is important that both sides of the tunnel solution have a match.
Example 5-8 Verifying the IPsec Transform Set
HQ-Router(config)# show crypto ipsec transform-set
Transform set default: { esp-aes esp-sha-hmac }
will negotiate = { Transport, },
Transform set MYSET: { esp-aes esp-sha-hmac }
will negotiate = { Tunnel, },
In the default configuration, transport mode only protects the upper layer protocols with payload encapsulation mode, and tunnel mode protects the entire IP datagram.
GRE Tunnel Configuration
A GRE tunnel is required for a DMVPN network. If you think about it, the tunnel interface allows the consolidation of numerous remote site point-to-point links into one interface. In some of the legacy Cisco site-to-site configurations, you would have one crypto map on the outside interface with multiple configuration sections for each remote site VPN link. That would cause the router configuration to be extensive and possibly complex to troubleshoot. With the GRE tunnel solution, you have one tunnel interface scaling to support hundreds of remote site locations. The tunnel interface is designated as a multipoint interface, resulting in an NBMA network. Typically, when you configure a GRE tunnel, the source and destination IP addresses are configured so that the tunnel can be established; however, with DMVPN, you do not need this because you use NHRP to solve endpoint address resolution.
A GRE tunnel configuration on the hub consists of a single step, which is creating a multipoint GRE tunnel.
Creating a Multipoint GRE Tunnel on the Hub
Example 5-9 shows how to build a basic DMVPN hub router tunnel configuration. The key to this configuration is the tunnel command, which sets the mode to multipoint. This tunnel configuration works for both IPv4 and IPv6.
Example 5-9 Creating a Multipoint GRE Tunnel on a Hub Router for IPv4 or IPv6
HQ-Router(config)# interface tunnel0 HQ-Router(config-if)# ip address 192.168.1.1 255.255.255.0 HQ-Router(config-if)# ipv6 address 2001:db8:aaaa:1::1/64 HQ-Router(config-if)# tunnel source GigabitEthernet1 HQ-Router(config-if)# tunnel mode gre multipoint HQ-Router(config-if)# tunnel key 12345
Notice that Example 5-9 has both an IPv4 address and an IPv6 address on the tunnel interface. That means you can configure it for either solution, and you can select the one you need for your environment. If IPv6 is used, the command tunnel mode gre multipoint must be changed to tunnel mode gre multipoint ipv6. It is possible to use the tunnel mode command without the ipv6 keyword, but without this keyword, your IPv6 configuration will not work. The tunnel source is the outside interface (that is, the interface of the router in this example).
The command tunnel mode gre multipoint in Example 5-9 makes the GRE tunnel a multipoint GRE (mGRE) tunnel, which allows multiple remote sites to be grouped into a single multipoint interface. The tunnel key command provides a weak form of security, but it could help prevent misconfiguration of a remote site from impacting a large-scale DMVPN environment.
Creating a GRE Tunnel on the Spoke
Unlike the hub, in DMVPN phase 1 the spoke uses a point-to-point tunnel. To put it another way, the command tunnel mode gre multipoint is replaced with the command tunnel destination ip_address, where ip_address is the public IP address of the hub router, as shown in Example 5-10.
Example 5-10 Configuring a Spoke Router for IPv4
Spoke1(config)# interface tunnel0 Spoke1(config-if)# ip address 192.168.1.2 255.255.255.0 Spoke1(config-if)# tunnel source GigabitEthernet0 Spoke1(config-if)# tunnel destination 192.0.2.3 Spoke1(config-if)# tunnel key 12345
Example 5-11 shows the IPv6 configuration of a spoke router tunnel interface.
Example 5-11 Configuring a Spoke Router for IPv6
Spoke1(config)# interface tunnel0 Spoke1(config-if)# ipv6 address 2001:db8:beef:4::2/64 Spoke1(config-if)# tunnel source GigabitEthernet0 Spoke1(config-if)# tunnel destination 2001:db8:aaaa:1::1 Spoke1(config-if)# tunnel key 12345
The tunnel configuration for the spoke router references the outside interface with the tunnel source command. Because GRE is the default tunnel mode, no specific tunnel mode command is required to support both unicast and multicast traffic. It will be important that the tunnel supports the use of multicast communication mechanisms later, when you want to run routing protocols such as OSPF. As mentioned earlier, the tunnel key command provides a weak form of security, preventing misconfiguration of a spoke router from impacting a production DMVPN network.
NHRP Hub-and-Spoke Configuration
The next part of the configuration is the NHRP hub-and-spoke configuration. Configuring NHRP for hub-and-spoke is a three-step process on the hub:
Configure NHRP
Configure the tunnel
Configure tunnel optional parameters
Configure NHRP on the Hub
Let’s start by setting up NHRP using IPv4. Example 5-12 shows the required commands for NHRP on a hub router tunnel interface with IPv4.
Example 5-12 Setting Up NHRP IPv4 Server Parameters on the mGRE Tunnel
HQ-Router(config)# interface tunnel0 HQ-Router(config-if)# ip nhrp authentication KEY123 HQ-Router(config-if)# ip nhrp map multicast dynamic HQ-Router(config-if)# ip nhrp network-id 1
Example 5-13 shows the required commands for NHRP on a hub router tunnel interface for IPv6. Notice that these two examples are almost the same; the only difference is the addition of ipv6 at the start of the commands in Example 5-13.
Example 5-13 Setting Up NHRP IPv6 Server Parameters on the mGRE Tunnel
HQ-Router(config)# interface tunnel0 HQ-Router(config-if)# ipv6 nhrp authentication KEY123 HQ-Router(config-if)# ipv6 nhrp map multicast dynamic HQ-Router(config-if)# ipv6 nhrp network-id 1
The tunnel interface is set up as NBMA. You need a mechanism to allow the remote sites to communicate with the hub router. NHRP acts like dynamic DNS, as it allows remote sites to communicate and register with the DMVPN hub router. The command map multicast dynamic in Example 5-12 and Example 5-13 enables the DMVPN hub router to receive inbound registration requests from any spoke router IP address. Furthermore, the dynamic command enables the replication of multicast packets to each of the spoke routers through the single tunnel interface. Think of this in terms of the hub router referencing the NHRP database, and for each entry, it sends a unicast/multicast packet to that spoke IP address. It does this until each spoke has received the routing update. This way, the router is able to establish dynamic routing protocol adjacencies by utilizing the database to map the multicast endpoints.
Configure NHRP on the Spoke
The configuration of NHRP on the spoke router is different from the configuration on the hub router. Notice that there are a few more commands, and you must specify the IP address of the next hop server. In this case, you provide the tunnel IP address for the hub router. In addition, you add an NBMA address that can receive the broadcast or multicast packets you send out the tunnel interface. Finally, the key to mapping the NHRP tunnel address to the outside public address is to provide the mapping of the NHS tunnel IP address (192.168.1.1) to the NBMA IP address (192.0.2.3).
Example 5-14 shows a basic IPv4 NHRP configuration setup.
Example 5-14 Configuring NHRP on a Spoke Router for IPv4
Spoke1(config)# interface tunnel0 Spoke1(config-if)# ip nhrp authentication KEY123 Spoke1(config-if)# ip nhrp network-id 1 Spoke1(config-if)# ip nhrp nhs 192.168.1.1 Spoke1(config-if)# ip nhrp map multicast 192.0.2.3 Spoke1(config-if)# ip nhrp map 192.168.1.1 192.0.2.3
The IPv6 configuration of NHRP on the spoke is different from the configuration on the hub router, just as it is for IPv4. You use a few more commands and must specify the IP address of the NHS. In this case, you provide the tunnel IP address for the hub router (2001:db8:beef:1::1). In addition, you add an NBMA address that can receive the broadcast or multicast packets you send out the tunnel interface. Finally, it is critical to provide the mapping of the NHS tunnel IP address (192.168.1.1) to the NBMA IP address (192.0.2.3).
Example 5-15 shows a basic IPv6 NHRP configuration setup.
Example 5-15 Configuring NHRP on a Spoke Router for IPv6
Spoke1(config)# interface tunnel0 Spoke1(config-if)# ipv6 nhrp authentication KEY123 Spoke1(config-if)# ipv6 nhrp network-id 1 Spoke1(config-if)# ipv6 nhrp nhs 2001:db8:beef:1::1 Spoke1(config-if)# ipv6 nhrp map multicast 2001:db8:aaaa:1::1 Spoke1(config-if)# ipv6 nhrp map 2001:db8:beef:1::1/64 2001:db8:aaaa:1::1
Configure Tunnel Protection
Now we need to configure the tunnel interface. Example 5-16 shows the configuration required to encrypt the traffic passing through the tunnel. This same configuration should be applied to both the hubs and the spokes.
Example 5-16 Configuring the Tunnel Interface with IPsec Profile Protection
HQ-Router(config)# interface tunnel0 HQ-Router(config-if)# tunnel protection ipsec profile MYIPSECPROFILE
The tunnel protection ipsec profile command applies the IPsec profile created previously to the tunnel interface. No crypto map is required. All traffic that passes through the tunnel will be encrypted with IPsec, and traffic outside the tunnel will not be encrypted. The use of tunnel protection and an IPsec profile significantly simplifies the IPsec configuration when compared to crypto maps.
Configure Tunnel Optional Parameters
Next, we need to address issues such as MTU size and the maximum segment size that is negotiated during the TCP synchronization handshake. For any TCP packet going through the tunnel, the router will adjust the maximum segment size (MSS) in the TCP header to match the value you have set it to. This will force the end hosts to also adjust their setting to this value. The mtu and adjust-mss commands help resolve issues with most TCP-based applications that need to traverse the DMVPN tunnel.
Example 5-17 shows additional commands to prevent applications from failing to function across the DMVPN tunnel.
Example 5-17 Configuring the Tunnel Interface with Optional IP Parameters
HQ-Router(config)# interface tunnel0 HQ-Router(config-if)# ip mtu 1400 HQ-Router(config-if)# ip tcp adjust-mss 1360
IPv6 has a different header than with IPv4. You still have to be concerned about the MTU size, but with IPv6, the fragmentation and reassembly process is improved; thus, most hops can handle average IP datagrams along the path without needing to fragment packets.
IPv6 has built-in solutions to address fragmentation, and Example 5-18 shows that you only need to adjust the MTU size.
Example 5-18 Sample IPv6 Configuration of the Tunnel Interface
HQ-Router(config)# interface tunnel0 HQ-Router(config-if)# ipv6 mtu 1400
Routing Protocol Configuration
Routing protocol configuration is the final part in setting up a DMVPN solution. During the design phase, you needed to determine which routing protocol you would select. There are a few options, such as EIGRP or OSPF. This section walks you through an example of configuring EIGRP. (For other configuration examples, such as OSPF, please refer to the documentation links included at the end of this chapter.)
Configure Routing on the Hub
With DMVPN, the NHRP database enables the hub router to replicate the individual multicast packets needed by the routing protocol to each site, one by one. In DMVPN, the routing protocol neighbor relationship is only established between the hub and the spoke routers. Thus, the hub is responsible for distributing routes learned from one spoke back out to another spoke. Thus, you run into an issue where a feature in the link state routing protocols, split horizon, works against you. With split horizon, any network learned on an EIGRP interface is not advertised back out the same interface. With DMVPN, you must disable this so that routes propagate successfully to all of the spoke routers.
Example 5-19 shows how to configure EIGRP for IPv4. Notice the commands no auto-summary and no ip split-horizon eigrp 1.
Example 5-19 IPv4 Hub Router 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
Notice that Example 5-19 includes a command under the tunnel interface that disables split horizon. In addition, you can (for EIGRP) disable route summarization on the hub so that the hub router will send complete spoke route information out to each spoke rather than summarizing it.
Configure Routing on the Spoke Using IPV4
Example 5-20 shows the IPv4 spoke router configuration for EIGRP.
Example 5-20 IPv4 Spoke Router Configuration
Spoke1(config)# router eigrp 1 Spoke1(config-router)# no auto-summary Spoke1(config-router)# network 10.2.2.0 0.0.0.255 Spoke1(config-router)# network 192.168.1.0 0.0.0.255
The spoke routers have a simple EIGRP configuration that identifies the GRE tunnel IP network and the inside network that you need propagated to the hub routing table.
Example 5-21 shows the IPv6 configuration of EIGRP on the hub router.
Example 5-21 IPv6 Hub Router Configuration
HQ-Router(config)# ipv6 unicast routing HQ-Router(config)# ipv6 cef HQ-Router(config)# ipv6 router eigrp 1 HQ-Router(config-rtr)# eigrp router-id 192.0.2.3 HQ-Router(config-rtr)# interface tunnel 1 HQ-Router(config-if)# ipv6 eigrp 1
Configure Routing on the Spoke Using IPV6
For the IPv6 configuration, we show you an example of enabling IPv6 unicast routing on the router and then configuring the IPv6 router with an EIGRP router ID. It is a good practice to control the router ID; in this case, you are using the outside IPv4 address of the HQ router, which is 192.0.2.3. (Yes, in an IPv6 configuration, you can use an IPv4 address as an identifier.)
Next, on the interface tunnel, you enable EIGRP routing by specifying IPv6 EIGRP with the autonomous system number you set up, which in this case is 1.
Example 5-22 shows the IPv6 EIGRP configuration on the spoke router.
Example 5-22 IPv6 Spoke Router Configuration
Spoke1(config)# ipv6 unicast routing Spoke1(config)# ipv6 cef Spoke1(config)# ipv6 router eigrp 1 Spoke1(config-rtr)# eigrp router-id 2.2.2.2 Spoke1(config-rtr)# interface tunnel 1 Spoke1(config-if)# ipv6 eigrp 1
For the IPv6 configuration, you configure the spoke with IPv6 unicast routing and then configure the IPv6 router with the EIGRP router ID 2.2.2.2. Again, in this case, you do this simply to identify the router when looking at the EIGRP neighbors.
That wraps up our DMVPN hub-and-spoke configuration walkthrough. Next, let’s look at a DMVPN phase 2 spoke-to-spoke configuration.