Dynamic Multipoint Virtual Private Networks
| At this point, we've covered basic IP routing continuity options over IPsec VPN tunnels in the context of Geographic HA, each of which presents its own unique design challenges. In large-scale IPsec+GRE designs, two such unique design challenges include management and configuration on IPsec+GRE hub/aggregation routers and peer scalability in the hub/aggregation router SADB. DMVPN addresses these concerns, among others, by greatly decreasing the configuration and management effort on the IPsec+GRE hub/aggregation routers using mGRE with Next Hop Resolution Protocol (NHRP) and enabling spoke routers to dynamically build SAs directly to their desired spoke routers. In this section, we will review all of the required components of DMVPN and reinforce these components with an enterprise DMVPN deployment case study. DMVPN Solution Design DriversDMVPN designs enable administrators to address several key design considerations with large-scale IPsec+GRE deployments. Our discussions in this section focus on two of these critical design considerations in large-scale IPsec+GRE designs found in many of today's enterprise-class networks:
Note Even in DMVPN networks, having 1 GRE IDB entries is rare to the point of being infeasible. This implies 100 percent spoke-to-spoke traffic. Any time a spoke requires IPsec-secured connectivity to the hub, regardless of whether or not DMVPN is configured, 2 IPsec SAs and 1 IDB entry will be created on the hub. The example described previously is used to reinforce that, with DMVPN, IPsec SAs and GRE IDBs are created only as needed. In addition to improved SA and IDB management, DMVPN decreases unnecessary decrypt/reencrypt behavior on the hub IPsec VPN gateway for spoke-to-spoke communications. In traditional IPsec+GRE hub and spoke deployments, a branch must encrypt traffic to the hub, where it is decrypted and then reencrypted before sending to the destination branch in a spoke-to-spoke scenario. We will explore in our step-by-step discussions how DMVPN can be used to eliminate this by enabling the spokes in the previous example to directly negotiate Phase 1 and 2 SAs with each other, as opposed to both spokes negotiating Phase 1 and 2 SAs with the hub. In doing this, DMVPN changes the behavior of the spoke-to-spoke communication example described above to a direct spoke-to-spoke IPsec VPN tunneling model, including one encrypt action on the source IPsec spoke and one decrypt action on the destination IPsec spoke with no encryption or decryption occurring on the hub at all. DMVPN therefore presents an opportunity to dramatically decrease the processing load on the hub router in networks with heavy spoke-to-spoke IPsec VPN traffic. DMVPN Component-Level Overview and System OperationAt this point, we've covered several key design drivers for DMVPN in IPsec+GRE environments, including DMVPN's ability to ease configuration and management burden on administrators, increase IPsec scalability through better management of the IPsec SADB and GRE IDB entries, and increase IPsec scalability by eliminating processing load on the hub IPsec VPN gateway attributable to spoke-to-spoke communications. In this section, we will discuss the step-by-step process involved in hub-to-spoke and spoke-to-spoke communication examples in a DMVPN network. However, before we dive in to the step-by-step operation of DMVPN in these scenarios, it is important to understand the required components of the overall DMVPN architecture:
The components described above work in concert to deliver the overall DMVPN solution. Figure 7-5 illustrates an enterprise hub-and-spoke DMVPN design in which several spokes communicate in both a spoke-to-spoke and spoke-to-hub fashion. Figure 7-5. Enterprise DMVPN Topology In the DMVPN topology, C3845ISR-A and B communicate to the hub securely using IPsec+GRE, without any dynamic next-hop discovery behavior with NHRP. In other words, in this topology, or any DMVPN topology, IPsec+GRE tunnels are created from hub-to-spoke once tunnel protection is enabled on the hub and spoke tunnel interfaces. The dynamic behavior of the DMVPN implementation of Figure 7-5 is introduced only when C3845ISR-A and B communicate with one another directly. In this case, NHRP is used to dynamically determine the peering information necessary to build a direct IPsec tunnel between the two spokes, effectively bypassing any crypto requirements on the hub for that specific spoke-to-spoke tunnel. The following list illustrates the sequence of events corresponding to dynamic spoke-to-spoke SA establishment between two endpoints illustrated in Figure 7-5:
Note When the NHRP entry timeout intervals expire, the NHRP entries learned in #3 and #7 will be removed from the NHRP mapping tables on C3845ISR-A and B, respectively. This causes IPsec to tear down the VPN tunnel built between C3845ISR-A and B in #4. The process described above illustrates several benefits of DMVPN from administrative, management, and scalability perspectives. The configurations for C7304, C3845ISR-A, C3845-ISR-B can be referenced in Examples 7-12 and 7-13 to further reinforce the illustration of these benefits. Before reviewing the required configurations for the DMVPN implementation topology of Figure 7-5, let's quickly review the DMVPN benefits against the step-by-step DMVPN operation on C3845ISR-A and B described above:
As with traditional IPsec+GRE, the ISAKMP must be configured to establish the Phase 1 SAs that DMVPN will use to build Phase 2 SAs. Unlike the configurations used earlier in this chapter, this design uses RSA-sigs (the IOS default) to authenticate the IKE SA. The crypto transform used in this example is 3DES with MD5 HMAC authentication on the ciphered blocks. A crypto profile is used to bind the transform set described above to the tunnel interface used for DMVPN (Example 7-9, lines 11-12). Unlike traditional IPsec and IPsec+GRE designs, there is no need for a crypto map or crypto ACL in a DMVPN design. The IPsec transform set is applied to the interface by referencing the IPsec profile configured earlier. This effectively turns on ISAKMP on physical interface protecting the tunnel and also includes all GRE traffic sent out of this interface to be included in the crypto switching path. As such, there is no concept of a crypto ACL for defining crypto-protected traffic flows in a DMVPN. Instead, all traffic forwarded out of the GRE interface with tunnel protection enabled will be encrypted using the appropriate crypto transform. NHRP is used to dynamically learn next-hop addresses for spoke-to-spoke GRE tunnel terminations. NHRP Authentication is performed in cleartext, as shown in Example 7-10, line 18. Additional authentication is provided at the GRE layer using a tunnel key, as shown in Example 7-10, line 25. The NHRP network ID shown in Example 7-10, line 20, must be consistent between all of the spokes and the hub in the same DMVPN deployment that uses the same mGRE tunnel interface on the hub. All of the spokes with this network ID will use this hub router as the NHRP NHS. Tip The GRE tunnel maximum transmission unit (MTU) can be adjusted to avoid fragmentation issues that could lead to performance issues if reassembly is required prior to decryption at the opposite end of the tunnel. Example 7-10, line 14, illustrates how this can be done on a DMVPN hub router. For more information on proper handling of IP fragmentation in IPsec VPNs, please refer to Chapter 4. The IP address of the tunnel interface is injected in to EIGRP 10. The routing protocol configuration in this design is configured in the same fashion as traditional IPsec+GRE: EIGRP 10 is used as the routing protocol for the tunnel interfaces and the private networks communicating over the IPsec+GRE DMVPN tunnels, while OSPF is used as the routing protocol for DMVPN IPsec and GRE tunnel establishment. Disabling split horizon for EIGRP AS 10 allows RP updates to be exchanged from spoke to spoke. Updates flow in to the mGRE tunnel interface on the hub and are then transmitted out of the hub to the destination spoke. EIGRP split horizon prevents this behavior, and is on by default, so it must be explicitly disabled when using EIGRP to route between private networks over the DMVPN IPsec+GRE infrastructure. Example 7-10. DMVPN Hub Configuration for C7304 (Figure 7-5)
In terms of encryption and routing processes, the configuration of the DMVPN spoke in Example 7-11 is similar to that of the DMVPN hub provided in Example 7-10. Unlike the hub (which is actually the NHS and is aware of all spoke addresses), the spoke dynamically learns next hop addresses for spoke-to-spoke GRE tunnel terminations via NHRP by querying the NHS. Like the hub, the spoke performs NHRP Authentication in cleartext, and additional authentication is provided at the GRE layer using a tunnel key. The NHRP network ID shown must match the hub in order for the spoke to effectively use the hub as the NHS for resolving next-hop queries. A static NHRP map (Example 7-11, line 18) is required on the spoke to allow queries to the NHS (192.168.0.1) to be mapped to the physical interface of the NHS itself (200.1.1.1). The spoke is then configured to use this static map to query for the unknown next-hop IP addresses using NHRP. Although the NHS is defined as a tunnel interface, it is manually mapped to a physical interface, as shown previously in this example. The NHS responds to NHRP next-hop queries that are subsequently used by DMVPN for dynamic spoke-to-spoke IPsec VPN tunnel establishment. Example 7-11. DMVPN Spoke Configuration for C3845ISR-A and B (Figure 7-5)
|
EAN: 2147483647
Pages: 113