| Once the RAVPN has the appropriate amount of resiliency designed into the VPN concentrator cluster, there are several design options that can be selected for VPN clients to take full advantage of the resilient concentrator cluster design. In this section, we will explore the use of geographic HA in an RAVPN. First, we will discuss how Domain Name System (DNS) can be configured to load balance inbound IPsec sessions from the VPN clients across multiple concentrators in a given cluster. After exploring this design alternative, we will then add the use of multiple peer definitions in the IPsec VPN client profile to provide resilient peering to multiple IPsec VPN concentrators. We will explore how these geographic HA options can be deployed in a standalone fashion, or in tandem for increased geographic IPsec HA. VPN Concentrator Session Load Balancing Using DNS Geographic HA can be designed in to an RAVPN deployment using DNS-based load balancing. In this section, we will explore how resolving a single IPsec VPN concentrator hostname to multiple IP address assigned to the public interfaces of different VPN concentrators in a cluster can result in a round-robin distribution of IPsec VPN client sessions across the VPN concentrators in a given cluster. Figure 9-19 illustrates a RAVPN deployment in which IPsec VPN clients resolve the hostname cluster-main.cisco.com to the various IP addresses of the public interfaces on the VPN concentrators in the cluster in a round-robin fashion. The following order of operations describes the numbered process of DNS-based round-robin IPsec VPN session load balancing across redundantly configured VPN concentrators: 1. | Client-A initiates an IPsec VPN tunnel to the concentrator cluster using the hostname "cluster-main.cisco.com." Client-A attempts to resolve the IP address of "cluster-main.cisco.com" sing the DNS server at 200.1.1.17.
| 2. | The DNS server at 200.1.1.17 responds with the first IP address assigned to cluster-main.cisco.com (200.1.1.101), which is also the IP address of the public interface configured on ASA5540-A.
| 3. | Client-A establishes an IPsec VPN tunnel to ASA5540-A using the IP address of 200.1.1.1 for IPsec peering.
| 4. | Client-B initiates an IPsec VPN tunnel to the concentrator cluster using the hostname "cluster-main.cisco.com." Client-B attempts to resolve the IP address of "cluster-main.cisco.com" using the DNS server at 200.1.1.17.
| 5. | The DNS server at 200.1.1.17 responds with the second IP address assigned to cluster-main.cisco.com (200.1.1.102), which is also the IP address of the public interface configured on ASA5540-B.
| 6. | Client-B establishes an IPsec VPN tunnel to ASA5540-B using the IP address of 200.1.1.102 for IPsec peering.
| 7. | Client-C initiates an IPsec VPN tunnel to the concentrator cluster using the hostname "cluster-main.cisco.com." Client-C attempts to resolve the IP address of "cluster-main.cisco.com" using the DNS server at 200.1.1.17.
| | | 8. | The DNS server at 200.1.1.17 responds with the third IP address assigned to cluster-main.cisco.com (200.1.1.103), which is also the IP address of the public interface configured on ASA5540-C.
| | | 9. | Client-C establishes an IPsec VPN tunnel to ASA5540-C using the IP address of 200.1.1.103 for IPsec peering.
|
The process described above continues in a round-robin fashion as new IPsec VPN clients attempt to build IPsec VPN tunnels with the IPsec VPN concentrator cluster. Although this method of RAVPN IPsec session load balancing is not as efficient or effective as VCA, it does ensure that inbound IPsec VPN tunnels are evenly distributed across the concentrators in the cluster. With DNS-based load balancing, an even distribution of IPsec VPN tunnels is achieved. Even distribution provides an effective means of load balancing, but perhaps not the most effective and efficient. VCA, however, does not provide an even distribution of inbound IPsec VPN sessions across the clusters. Instead, IPsec VPN session distribution decisions are made based on actual session load information taken from the concentrators in the cluster, accounting for platform-specific capacity considerations and fluctuation in IPsec session load statistics on the concentrators in the cluster. RAVPN HA designs using VCA are supported only by Cisco VPN concentrators, and as such, using VRRP-based RAVPN HA or DNS-based load balancing both present viable design alternatives for RAVPN HA in vendor-diverse environments. However, in Cisco-based RAVPN HA concentrator cluster designs, VCA adds an extra layer of intelligence to load balancing and redundancy operations that enable optimized distribution of IPsec VPN sessions across the different concentrators in the VCA cluster. VPN Concentrator Redundancy Using Multiple Peers Another layer of Geographic HA can be built in to the RAVPN design by defining multiple IPsec peers in the IPsec VPN client profile. In this section, we will explore two designs that use multiple IPsec peers for Geographic HA: Figures 9-20 through 9-22 illustrate the VPN client configuration required to leverage geographic HA using multiple IPsec peer definitions. The configuration is the same regardless of whether that peer represents an HSRP Standby interface or a VCA Virtual IP address. Figure 9-20. IPsec VPN Client Authentication Configuration 
Figure 9-21. IPsec VPN Client Transport Configuration 
Figure 9-22. Configuring Backup Peers on Cisco VPN Clients 
The first design we will discuss deploys a stateless IPsec VPN concentrator design using HSRP-based tunnel termination with multiple HSRP groups for HA and DNS-based. In Figure 9-19, the three IPsec VPN concentrators are configured for stateful HA using three HSRP groups with different HSRP Virtual Router IP addresses. Instead of statically assigning VPN clients to a VRRP group, the concentrators in this cluster use DNS-based load balancing to dynamically return a different HSRP Virtual Router IP address when a round-robin VPN client establishes an IPsec VPN session to the concentrator. The load-balancing configuration for Figure 9-23 is summarized in Table 9-2. Figure 9-23. Geographic IPsec HA Using Multiple IPsec Peer Hostnames in the VPN Client Profile, DNS-Based Load Balancing, and VRRP-Based IPsec VPN concentrator Local HA 
Table 9-2. VRRP-Based Stateless IPsec RAVPN HA Load Balancing with Multiple VRRP Groups, DNS-Based Load Balancing, and Multiple Peer Definitions in the IPsec VPN Client ProfileCluster Hostname: charlotte-vpn.cisco.com
DNS IP Resolutions: 200.1.1.100
200.1.2.100
200.1.3.100 | HSRP Group#: 1
IP: 200.1.1.100 | HSRP Group#: 2
IP: 200.1.2.100 | HSRP Group#: 3
IP: 200.1.3.100 |
|---|
Concentrator: | Priority: 30 | Priority: 20 | Priority: 10 | VPN7301-CHA-A | Status: Master | Status: 1st Backup | Status: 2nd Backup | VPN Clients: | | | | 1st + Every Other 3rd | | | | Concentrator: | Priority: 10 | Priority: 30 | Priority: 20 | VPN7301-CHA-B | Status: 2nd Backup | Status: Master | Status: 1st Backup | VPN Clients: | | | | 2nd + Every Other 3rd | | | | Concentrator: | Priority: 20 | Priority: 10 | Priority: 30 | VPN7301-CHA-C | Status: 1st Backup | Status: 2nd Backup | Status: Master | VPN Clients: | | | | 3rd + Every Other 3rd | | | | Cluster Hostname: boulder-vpn.cisco.com
DNS IP Resolutions: 200.2.1.100
200.2.2.100
200.2.3.100 | VRRP Group#: 1
IP: 200.2.1.100 | VRRP Group#: 2
IP: 200.2.2.100 | VRRP Group#: 3
IP: 200.2.3.100 | Concentrator: | Priority: 30 | Priority: 20 | Priority: 10 | VPN7301-BOU-A | Status: Master | Status: 1st Backup | Status: 2nd Backup | VPN Clients: | | | | 1st + Every Other 3rd | | | | Concentrator: | Priority: 10 | Priority: 30 | Priority: 20 | VPN7301-BOU-B | Status: 2nd Backup | Status: Master | Status: 1st Backup | VPN Clients: | | | | 2nd + Every Other 3rd | | | | Concentrator: | Priority: 20 | Priority: 10 | Priority: 30 | VPN7301-BOU-C | Status: 1st Backup | Status: 2nd Backup | Status: Master | VPN Clients: | | | | 3rd + Every Other 3rd | | | |
The design leverages the use of two concentrator clusters, boulder-vpn.cisco.com and charlotte-vpn.cisco.com. Each cluster acts as a "primary" cluster for its half of the VPN client population in the RAVPN design: boulder-vpn.cisco.com serves as the primary cluster for users in the western half of the country, while charlotte-vpn.cisco.com serves as the primary cluster for the eastern half of the country. The VPN clients are configured to use multiple IPsec peers for geographic HA. The IPsec VPN clients will therefore attempt to connect to their primary cluster first. If they are unable to connect to their primary cluster within a configurable timeout window, they will try the other cluster as a backup. Within each cluster, inbound IPsec sessions are distributed across three VRRP groups with skewed priorities consistent with the format in Table 9-2 using DNS-based load balancing. The following sequence of steps illustrates the order of operations executed when clients attempt to build IPsec VPN tunnels to the redundant pair of concentrator clusters illustrated in Figure 9-23. 1. | Client-Cha1 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.
| 2. | The DNS server returns the first HSRP Virtual Router IP address (Group 1 = 200.1.1.101) for charlotte-vpn.cisco.com.
| | | 3. | Client-Cha1 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-CHA-A (the Active HSRP Router for HSRP Group 1).
| 4. | Client-Cha2 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.
| 5. | The DNS server returns the second HSRP Virtual Router IP address (Group 1 = 200.1.1.102) for charlotte-vpn.cisco.com.
| 6. | Client-Cha2 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-CHA-B (the Active HSRP Router for HSRP Group 2).
| 7. | As long as the all of the concentrators in the VPN cluster charlotte-vpn.cisco.com are active, the DNS-server at 200.1.1.17 distributes the IPsec VPN sessions from the Charlotte clients evenly across the VPN concentrators in the Charlotte cluster (VPN7301-CHA-A, B, and C). This is achieved by using DNS-based load balancing to return the HSRP Virtual Router IP addresses corresponding to VPN7301-CHA-A, B, and C in a round-robin format following the same process as illustrated in steps 1-6 above.
| 8. | Client-Bou1 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.
| 9. | The DNS server returns the first HSRP Virtual Router IP address (Group 1 = 200.1.2.101) for boulder-vpn.cisco.com.
| 10. | Client-Bou1 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-BOU-A (the Active HSRP Router for HSRP Group 1).
| 11. | Client-Bou2 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.
| 12. | The DNS server returns the second HSRP Virtual Router IP address (Group 1 = 200.1.2.102) for boulder-vpn.cisco.com.
| 13. | Client-Bou2 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-BOU-B (the active HSRP Router for HSRP Group 2).
| 14. | As long as all of the concentrators in the VPN cluster boulder-vpn.cisco.com are active, the DNS server at 200.1.2.17 distributes the IPsec VPN sessions from the Boulder clients evenly across the VPN concentrators in the Boulder cluster (VPN7301-BOU-A, B, and C). This is achieved by using DNS-based load balancing to return the HSRP Virtual Router IP addresses corresponding to VPN7301-BOU-A, B, and C in a round-robin format following the same process as illustrated in steps 8-13 above.
| 15. | A power outage occurs in the Boulder Facility hosting the IPsec VPN concentrator cluster boulder-vpn.cisco.com, making all concentrators in the cluster unavailable.
| | | 16. | Client-Bou3 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname boulder-vpn.cisco.com to an IP address using the DNS server at 200.1.2.17. Due to the power outage in step 15 above, Client-Bou3 receives no reply from the DNS server at 200.1.2.17. Client-Bou3 queries 200.1.1.17 instead.
| 17. | The DNS server 200.1.1.17 returns the third HSRP Virtual Router IP address (Group 1 = 200.1.1.103) for charlotte-vpn.cisco.com to Client-Bou3.
| 18. | Client-Bou3 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-CHA-C (the Active HSRP Router for Group 3).
| 19. | As long as the all of the concentrators in the VPN cluster charlotte-vpn.cisco.com are active, the DNS-server at 200.1.1.17 distributes the IPsec VPN sessions from the Boulder clients evenly across the VPN concentrators in the Charlotte cluster (VPN7301-CHA-A, B, and C). This is achieved by using DNS-based load balancing to return the VRRP Virtual Router IP addresses corresponding to ASA5540-CHA-A, B, and C in a round-robin format. When the VPN concentrator cluster in Boulder recovers from the power outage in step 15, Boulder clients will revert back to boulder-vpn.cisco.com concentrator cluster.
|
Tip Upon recovery of a client's primary IPsec VPN concentrator cluster, the active remote VPN tunnels on a given VPN concentrator cluster will not revert back to their primary VPN concentrator until they are torn down and renegotiated (for example, torn down by the client, or timed out by the VPN concentrator). For this reason, and for others, it is useful to configure an effective timeout period on the VPN concentrators for client RAVPN sessions.
VCA can easily replace HSRP intra-cluster HA method for boulder-vpn.cisco.com and charlotte-vpn.cisco.com in the load-balancing scenario described above. If VCA were elected as the design option for charlotte-vpn.cisco.com and boulder-vpn.cisco.com in the clusters above, the DNS server would simply be altered to return VCA Virtual IP addresses for the hostnames boulder-vpn.cisco.com and charlotte-vpn.cisco.com to the IPsec VPN clients instead of the HSRP Virtual Router IP addresses in the scenario listed Figure 9-23 and Table 9-2. The IPsec VPN client profile configuration need not be changed when replacing HSRP with VCAthe VPN clients still use the hostnames charlotte-vpn.cisco.com and boulder-vpn.cisco.com to initiate IPsec VPN tunnels to the appropriate concentrator cluster. Within the VPN concentrator cluster, there are several key changes to the design that occur when changing from VRRP to VCA. Table 9-3 provides the information required to achieve Geographic HA using multiple hostnames for IPsec peering to IPsec VPN clusters enabled for load balancing and HA using VCA: There is no need for DNS-based load balancing The VCA master controller handles IPsec session load balancing within the cluster. There is no need for multiple HSRP groups or multiple HSRP Virtual Router IP addresses VCA dynamically redirects inbound IPsec sessions to the appropriate concentrator based on its current load relative to the platform maximum load. Although the VPN clients still use DNS to resolve the hostnames charlotte-vpn.cisco.com and boulder-vpn.cisco.com to an IP address, the DNS resolution for these hostnames is changed to yield a single VCA Virtual IP address to all DNS queries, rather than yielding multiple HSRP Virtual Router IP addresses in a round-robin fashion. VCA obsoletes the need for multiple DNS IP address under a single hostname.
Table 9-3. VCA IPsec RAVPN HA Load Balancing with DNS-Based Load Balancing and Multiple Peer Definitions in the IPsec VPN Client ProfileCluster Hostname: charlotte-vpn.cisco.com
DNS IP Resolutions: 200.1.1.100 | VCA Virtual IP: 200.1.1.100 |
|---|
Concentrator: ASA5540-CHA-A | Priority: 30 | VPN Clients: VCA Load-Based Distribution | Public IP: 200.1.1.101 | | | Status: Master | Concentrator: ASA5540-CHA-B | Priority: 20 | VPN Clients: VCA Load-Based Distribution | Public IP: 200.1.1.102 | | | Status: 1st Secondary | Concentrator: ASA5540-CHA-C | Priority: 10 | VPN Clients: VCA Load-Based Distribution | Public IP: 200.1.1.103 | | | Status: 2nd Secondary | Cluster Hostname: boulder-vpn.cisco.com
DNS IP Resolutions: 200.1.2.100 | VCA Virtual IP: 200.1.2.100 | Concentrator: ASA5540-BOU-A | Priority: 30 | VPN Clients: VCA Load-Based Distribution | Public IP: 200.1.2.101 | | | Status: Master | Concentrator: ASA5540-BOU-B | Priority: 10 | VPN Clients: VCA Load-Based Distribution | Public IP: 200.1.2.102 | | | Status: 2nd Backup | Concentrator: ASA5540-BOU-C | Priority: 20 | VPN Clients: VCA Load-Based Distribution | Public IP: 200.1.2.103 | | | Status: 1st Backup |
Figure 9-24 illustrates the operation of an RAVPN design in which multiple IPsec VPN peer definitions are configured in the VPN client profile to provide Geographic HA between two VCA-enabled RAVPN concentrator clusters in Boulder (boulder-vpn.cisco.com) and Charlotte (charlotte-vpn.cisco.com). We will used the stepped order of operation corresponding to Figure 9-24 to illustrate the order of operation that occurs when VPN clients attempt to access the VCA-enabled concentrator clusters in Boulder and Charlotte. Figure 9-24. Geographic IPsec HA Using Multiple IPsec Peer Hostnames and VCA Clustering for Local HA and Intracluster Session Load Balancing 
The following numbered list corresponding to the topology illustrated in Figure 9-24 describes the process of distributing inbound sessions from IPsec VPN clients when connecting to two geographically-disperse VPN concentrator clusters running the VCA session load-balancing protocol. 1. | Client-Cha1 looks up the first IPsec peer entry in its VPN Profile (charlotte-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.
| | | 2. | The DNS server returns the VCA Virtual IP address for charlotte-vpn.cisco.com (200.1.1.100).
| 3. | Client-Cha1 uses the IP address returned in step 2 to build an IPsec VPN tunnel with the cluster charlotte-vpn.cisco.com. The VCA master for charlotte-vpn.cisco.com (ASA5540-CHA-A) returns the physical public IP address of the least-loaded concentrator, which is currently ASA5540-CHA-B, (200.1.1.102).
| 4. | Client-Cha1 uses the public IP address of ASA5540-CHA-B as its IPsec peer when building the IPsec VPN tunnel.
| 5. | Client-Cha2 looks up the first IPsec peer entry in its VPN Profile (charlotte-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.
| 6. | The DNS server returns the same VCA Virtual IP address for charlotte-vpn.cisco.com (200.1.1.100) as it returned in step 2note that multiple DNS resolutions are not required here.
| 7. | Client-Cha2 uses the IP address returned in step 6 to build an IPsec VPN tunnel with the cluster charlotte-vpn.cisco.com. The VCA master for charlotte-vpn.cisco.com (ASA5540-CHA-A) returns the physical public IP address of the least-loaded concentrator, which is now ASA5540-CHA-C, to Client-Cha2 to use when building the IPsec VPN tunnel.
| 8. | Client-Cha2 establishes an IPsec VPN tunnel to the public interface on ASA5540-CHA-C (200.1.1.103).
| 9. | Client-Bou1 looks up the first IPsec peer entry in its VPN Profile (boulder-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.
| 10. | The DNS server returns the VCA Virtual IP address for boulder-vpn.cisco.com (200.1.2.100).
| 11. | Client-Bou1 uses the IP address returned in step 11 to build an IPsec VPN tunnel with the cluster boulder-vpn.cisco.com. The VCA master for boulder-vpn.cisco.com (ASA5540-BOU-A) returns the physical public IP address of the least-loaded concentrator, which is currently ASA5540-BOU-B.
| 12. | Client-Bou1 establishes an IPsec VPN tunnel to the public interface on ASA5540-BOU-B (200.1.2.102).
| 13. | Client-Bou2 looks up the first IPsec peer entry in its VPN Profile (boulder-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.
| 14. | The DNS server returns the same VCA Virtual IP address for boulder-vpn.cisco.com (200.1.2.100) as it returned in step 11 abovenote that there is no need for multiple DNS resolutions required here.
| | | 15. | Client-Bou2 uses the IP address returned in step 2 to build an IPsec VPN tunnel with the cluster boulder-vpn.cisco.com. The VCA master for boulder-vpn.cisco.com (ASA5540-BOU-A) returns the physical public IP address of the least-loaded concentrator, which is now ASA5540-BOU-C.
| 16. | Client-Bou2 establishes an IPsec VPN tunnel to the public interface on ASA5540-BOU-C (200.1.2.103).
| 17. | A power outage occurs in the Boulder Facility hosting the IPsec VPN concentrator cluster boulder-vpn.cisco.com, making all concentrators in the cluster unavailable.
| 18. | Client-Bou3 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname boulder-vpn.cisco.com to an IP address using the DNS server at 200.1.2.17. Due to the power outage in step 15, Client-Bou3 receives no reply from the DNS server at 200.1.2.17. Client-Bou3 queries 200.1.1.17 instead.
| 19. | Client-Bou3 attempts to resolve the backup IPsec peer hostname configured in its IPsec VPN profile (charlotte-vpn.cisco.com) with the DNS server at 200.1.1.17.
| 20. | The DNS server returns the VCA Virtual IP address for charlotte-vpn.cisco.com (200.1.1.100) to Client-Bou3.
| 21. | Client-Bou3 uses the IP address returned in step 2 to build an IPsec VPN tunnel charlotte-vpn.cisco.com. The VCA master for charlotte-vpn.cisco.com (ASA5540-CHA-A) returns the physical public IP address of the least-loaded concentrator, which is currently itself.
| 22. | Client-Bou2 establishes an IPsec VPN tunnel to the public interface on ASA5540-BOU-A (200.1.1.101).
| 23. | IPsec VPN sessions from both Charlotte and Boulder clients will continue to be load balanced across the concentrators participating the Charlotte VCA cluster. When the VPN concentrator cluster in Boulder recovers from the power outage in step 15, Boulder clients will revert to using boulder-vpn.cisco.com concentrator cluster for IPsec RAVPN session establishment.
|
|
