- “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 Design Considerations
Before you start designing a DMVPN network, it is critical to establish a goal for the solution. Just like with any VPN technology, you first need to understand what business problems you are going to solve. Once you have determined the goal, you can work back from the goal to the solution. We performed a similar exercise in the last chapter when covering design considerations for deploying GETVPN.
This section looks at some of the common design challenges and issues that security engineers must consider. In addition, equipment has a significant impact on a solution, and you might need to upgrade some of your equipment to support DMVPN, especially if you are trying to reuse existing equipment for remote site deployments. (Chapter 3 includes a list of pre-design questions that a team should consider before deploying DMVPN. Many of them specifically address equipment issues.)
DMVPN Planning
During the DMVPN design phase, a key constraint would be what applications will be running over the DMVPN links. Are you deploying VoIP or video conferencing solutions? Such low-latency applications might require QoS and priority over other applications. In addition, what level of fault tolerance is needed at the headend (hub) site to which the DMVPN remote sites connect? Will multicast traffic need to traverse the VPN links? What type of routing protocol will you use? The routing protocol setup requires some serious consideration. You should think about the following questions before configuring your routing protocol:
What network IP blocks need to be accessible from the remote sites?
Do remote site IP blocks need to be accessible from other locations?
Does traffic need to be filtered for specific IP address ranges?
Is QoS required?
Based on the answers to these questions, you might need to configure spoke-to-spoke communication across the VPN tunnel. If the objective of your design is to create spoke-to-spoke communication, you will need to answer another question: Will that traffic go through the headend router, or will it travel directly to the spoke? The answer impacts the configuration of your solution.
You need to think about all the questions posed so far, but these are just a few of the many considerations. Later in this chapter, you will see how to configure traffic from one spoke destined for another to be routed through the hub. You will also see how to configure a solution in which the spoke router can establish a direct VPN link to the other spoke router, thus reducing the overhead on the headend router.
DMVPN Fault Tolerance Considerations
We would be remiss if we did not talk about fault tolerance in this or any section that involves design considerations. Even though we do not focus on fault tolerance/high availability in our examples in this chapter, having multiple hub sites should be part of your design for high-availability purposes. Including multiple hub sites will add to the configuration on the spoke routers, but that additional work will not be a significant amount, and it could also increase the available bandwidth at the hub site. The level of fault tolerance your organization requires will impact your solution and its cost. As stated in the last chapter, we find cost is the number one factor that impacts how an organization will include fault tolerance within its VPN design.
Key DMVPN Considerations
One best practice we will continue to use in this chapter is creating a design on paper first. We recommend you share your design with your peers to validate and assess the design before moving forward with any deployment. The following are some of the many factors that should be documented and discussed before an implementation. You find this list to be similar to the one used in the last chapter.
IOS requirements
Platform capabilities (and upgrade options)
IP address scheme: IPv4, IPv6, or both
Tunnel addresses
External (public) addresses
DMVPN hub-and-spoke or partial mesh
Routing requirements
Authentication method: RSA signature, PKI, or pre-shared key
Encryption scheme
Deployment strategy
Application requirements
DMVPN Phases
DMVPN comes in three different designs, referred to as DMVPN phase 1, DMVPN phase 2, and DMVPN phase 3. The DMVPN phase you choose determines how spokes communicate with one another as well as the routing configuration. In the next three sections we discuss the differences between each phase and the major configuration differences between them.
DMVPN Phase 1
DMVPN phase 1 is the first phase that was defined when this technology was implemented by Cisco and is strictly designed for hub-and-spoke communications only. Spoke-to-spoke traffic flows will need to reach the hub and then be transported to the other spoke. This is the same traffic flow as a hub-and-spoke design in Frame Relay or ATM. For example, consider the topology shown in Figure 5-7.
)
Figure 5-7 Basic DMVPN Hub-and-Spoke Example
R1 is acting as the DMVPN hub for this network and is therefore the NHS for NHRP registration of the spokes. In DMVPN phase 1 the GRE tunnels shown are multipoint GRE on the hub and point-to-point on the spokes. This forces hub-and-spoke traffic flows on the spokes. In addition to this, the next-hop value of any routes sent from the hub to spoke show the hub as the next hop. Therefore, a spoke has no knowledge of other spokes and sends all traffic destined to another spoke via the hub.
DMVPN Phase 2
In DMVPN phase 2, spoke-to-spoke traffic flow is now permitted, and all spoke routers implement multipoint GRE. Equally, resolution request NHRP messages are now sent to resolve a spoke’s VPN address to its NBMA address. However, this function relies heavily on your routing design and in ensuring that the next-hop address is preserved during advertisement from the hub down to other spokes, much like how the next hop is preserved on an ethernet switch to allow more efficient traffic flows. To demonstrate this, the topology in Figure 5-8 has been updated to reflect this change.
In DMVPN phase 2, when a spoke router wants to communicate with another spoke router it will look at its routing table to determine the next-hop address. When routes are advertised from the hub, the next hop address is preserved. One downside of this is that each spoke has to hold the full network routing table for all spokes on the DMVPN network. This downside is because the routing and NHRP tables are unable to exchange information in DMVPN phase 2. In Figure 5-8, if Spoke1 had a change in its routing table with the failed link that triggered an update, Spoke2 would see this change and update its routing table. The reason is that the Spoke2 routing table has received routes from Spoke1 via the hub router, including the next hop of the tunnel address, which is 192.168.1.2 (Spoke1). Spoke1 only knows of Spoke2 through the tunnel address 192.168.1.3; it is not aware of the NBMA address (public) that lies in between. The hub router knows of the Spoke2 NBMA address and would forward the route update to Spoke2. You need to understand that changes or queries by any spoke of another spoke would, at a minimum, generate an NHRP resolution request to the hub. In this example, a failed link would generate not only an NHRP resolution request but also a routing protocol update packet.
)
Figure 5-8 Spoke-to-Spoke Added
Figure 5-9 shows that a link on Spoke1 has failed. This figure demonstrates that in a DMVPN phase 2 solution, a failed link such as the one on Spoke1 will trigger a routing update being sent to Spoke2 to notify that router of the change.
)
Figure 5-9 DMVPN Phase 2
DMVPN Phase 3
With DMVPN phase 3, Cisco modified the Cisco Express Forwarding (CEF) table and the NHRP table so that they can work together. This enables the NHRP table to resolve the next hop information and the CEF table to route the packets. This change enables the hub router to set the next hop to itself and advertise summarized routes to all of the spokes. This configuration option supports the use of smaller spoke routers by eliminating the need to support the entire corporate routing table.
Now that we have tackled all the design concepts behind DMVPN, we next learn what is involved with deploying DMVPN. Let’s first start with a look at a hub-and-spoke implementation.