Using Multiple Crypto Interfaces for High Availability
| It is very common for a networked IPsec VPN endpoint in a site-to-site deployment to have multiple interfaces available for IPsec configuration. One technique that can be used for local HA is to employ the use of multiple, redundant crypto interfaces in the IPsec VPN design. There are both advantages and disadvantages to leveraging this approach to IPsec local HA. Before we explore those advantages and disadvantages, let us first have a look at the failover process involved when activating multiple crypto interfaces for HA while exploring the simple site-to-site layout shown in Figure 6-1. Figure 6-1. Multiple Crypto Interface Configurations for IPsec HA When a serial interface failure occurs between Router_A and Router_B in Figure 6-1, the system undergoes the following sequence of events during the reconvergence process:
The use of crypto maps on redundant interfaces represents the most basic form of local HA available today. As one can tell from the preceding process, IPsec failover relies heavily on the reconvergence of the underlying routing protocol that the IPsec VPN tunnel is built on. Although this design is simple to deploy and to configure, there are quite a few ways to tune the process to fail over quicker. The failover scenario of Figure 6-1 and Example 6-1 describes the most simplistic, untuned way of providing local HA. The ISAKMP configuration on Router_A and Router_B must be capable of using matching preshared keys with both peers. Router_A's configuration, which is displayed in Example 6-1, would not only need to use the key "cisco" with 200.0.0.2 as the primary, but also with the redundant peer200.0.0.4. Router_A's crypto map configuration, also displayed in Example 6-1, uses redundant peer definitions within the same crypto map. If the first peer is unavailable, Router_A will use 200.0.0.4. This configuration is well suited for this environment only because the same address space will be protected for both peers. However, if different peers were to be used for different sets of protected address spaces, then another process within the same crypto map would be required (for example, crypto map chap6-dualit 20 IPsec-isakmp). Example 6-1. Local IPsec HA Using Separate Physical Interfaces
Let us take a look at some of the areas of this process that present opportunities for improvement and introduce some available design solutions:
Impact of Routing Protocol Reconvergence on IPsec ReconvergenceNote that Steps 3 and 6 of the failover process outlined in Figure 6-1 require that traffic be inspected by the crypto access list of the interfaces' crypto map before the new ISAKMP and IPsec SAs can be negotiated. Because of this, the availability of this design will directly depend on, among other things, the speed of RP reconvergence. With Cisco IOS, RP timers can be tuned to maximize the speed of reconvergence, resulting in faster failover to the redundant IPsec VPN tunnel. Note The discussion of RP timers is relevant to our discussion only in that speedy RP reconvergence times aid IPsec tunnel failover times. The subject is otherwise outside the scope of this publication. Tuning RP timers in an enterprise network produces an extremely large variety of effects beyond what we have discussed in relation to IPsec. For this reason, extreme caution should be exercised when altering RP timers in a network. In some instances, it may make sense to use floating static routes to expedite IPsec local HA even further. The floating static route approach describes a situation in which a static route is installed in the configuration with a higher administrative distance than an identical dynamically learned route. If that dynamically learned route is somehow removed from the routing table, then the floating static route is immediately installed. Additionally, floating static routes are simple to deploy, and they require less overhead. For these reasons, it may make sense in a network design to employ them in lieu of a full RP-based failover solution. One such popular instance in which floating static routes are commonplace is in highly available IPsec branch offices. Figure 6-2 illustrates the failover process of an IPsec HA branch failover scenario. Figure 6-2. Floating Static Routes and IPsec Tunnel Failover Example 6-2 illustrates the configuration of a floating static route on Branch_6A. Note in the configuration provided in Example 6-2, Ent_Main4a is using the loopback interface of Branch_4a to authenticate Phase 1 SAs and to negotiate Phase 2 SAs. Therefore, if Ent_Main4a is unable to effectively and rapidly route to that loopback interface, neither Phase 1 nor Phase 2 negotiations will complete successfully. Floating static routes can be used as follows to provide a means for rapid failover in this scenario: With floating static routes, the routing table does not need to wait on an update from Branch_4a to install the route to 10.1.1.4. Instead, the floating static route is immediately installed after the route with a lower admin distance is lost, thereby aiding the speed of reconvergence in the overall failover of the IPsec VPN tunnel. Like Ent_Main4a, Branch_4a uses a floating static route for failover of its IPsec tunnel. This allows Branch_4a to immediately renegotiate Phase 1 and Phase 2 SAs with Ent_Main4a without waiting for establishment of an RP adjacency and receipt of an RP update across the redundant link, thus trimming down the time it takes for the IPsec VPN to reconverge over the redundant path. Note in Example 6-2 the admin distance of 254 on this static route. Once the primary link is restored and an RP update with a lower admin distance is received over that path, that route will overwrite the static route in Branch_4a's routing table. Example 6-2. Using Floating Static Routes for Fast IPsec HA Failover
Now that we have briefly discussed the motivators for using floating static routes in local IPsec HA scenarios, we will consider the disadvantages of such a design that arise as the scale and complexity of the network increases. There are many situations in which floating static routes may not be a viable option. For example, a large routed domain between the VPN endpoints rather than a single Layer-3 hop (as is the case in Figure 6-1 and Figure 6-2) could make the use of static routes difficult to scale and manage. While floating static routes have design advantages in simple local IPsec HA deployments, a full RP-based approach to IPsec HA is recommended as the scale of the network increases. Impact of Stale SAs on IPsec ReconvergenceWhen new SAs are negotiated, the old (stale) SAs are not automatically reaped from the SADB. If IKE keepalives are not enabled, therefore, stale SAs can remain in for the duration of their original lifetime. As we have discussed in Chapter 4, "Common IPsec VPN Issues," stale IPsec and ISAKMP SAs can cause problems in IPsec VPNs. As we will see later in this section when discussing stateful and stateless IPsec HA solutions, stale SAs must be removed in order for an IPsec tunnel to fail over to its redundant peer. IPsec HA mechanisms therefore rely on IKE keepalives to reap stale SAs left in the SADB upon failover so that new SAs can be negotiated with the redundant peer. Improper handling of stale SAs can therefore lead to increased convergence times, or in some cases the inability to failover to a redundant peer in HA environments. Impact of IPsec and ISAKMP SA Renegotiation on IPsec ReconvergenceAlso note that in Steps 3 and 6 of Figure 6-2, new ISAKMP and IPsec SAs must be renegotiated. This process is initiated after the RP has reconverged, and traffic is forwarded matching a configured Crypto ACE on that interface's crypto map. This adds another layer of delay to the failover process, presenting us with another opportunity for optimizing local IPsec HA design. This hurdle for failover to a redundant IPsec VPN tunnel is inherent to a "stateless" failover. However, because we are currently speaking only of local HA solutions, this failover can be mitigated by sourcing updates from a highly available address (such as a loopback address) rather than the physical interface itself. In doing so, the original IPsec and ISAKMP SAs are preserved, and the failover time is limited to RP reconvergence across the redundant physical link. Consider once again the HA IPsec branch scenario in Figure 6-2. The branch and hub now use loopback64 to initiate/terminate the IPsec tunnel. Recall that Branch_4A uses a floating static route for Layer-3 redundancy to minimize failover delay attributable to RP reconvergence. Additionally, Branch_4A and Ent_Main4A use their loopback interface for IPsec tunnel termination. This method removes the dependency of the physical interface state to maintain the local state of IPsec. Therefore, Branch_4A can now fail over without having to renegotiate IPsec and ISAKMP SAs. Note It is important to note that when the RP fails, the hub in this case will not know how to get to the branch loopback interface. The loopback interfaces must be able to communicate in order for the IPsec tunnel to come up, because they are the precise endpoints used to terminate the tunnel. Note that in Figure 6-2 and Example 6-2, there are two floating static routes on Hub_Main4Aone to establish connectivity between the loopback interfaces for IPsec failover and another to establish connectivity to the actual branch network ("Branch4A_Net" of Figure 6-2). Example 6-3 illustrates a configuration in which IPsec and ISAKMP are sourced and terminated on highly available (loopback) interfaces. In this case, Branch_4a uses the highly available loopback interface of Ent_Main4a to identify the peer to use the key "cisco" with when authenticating Phase 1 SAs. Alternatively, Branch_4a could have been configured to share the key with a hostname, such as "Ent_Main4a", to accomplish the same thing. Branch_4a also uses the loopback interface as the termination point for the IPsec VPN tunnel. Because the IP address 200.1.1.5 is available to Branch_4a over either WAN link to Ent_Main4a, this separates the availability of the IPsec VPN tunnel from the availability of any one given physical interface, thereby providing a means of local HA between Branch_4a and Ent_Main4a. Example 6-3. IPsec Tunnel Termination to Highly Available Interfaces
Now that we have introduced some of the basic challenges with IPsec tunnel failover in HA environments and discussed some of the basic concepts of designing resiliency into the local design of the IPsec VPN, we will look at some of the more robust alternatives to HA design. We will begin our exploration of these HA design concepts by discussing a prevalent improvement to the "stateless" HA designs previously discussed in this chapter. Following our discussion of stateless HA concepts and solutions, we will discuss the concept of "stateful" HA design requirements and some effective solutions for IPsec Stateful HA VPNs. |
EAN: 2147483647
Pages: 113