Filter
Top Products
68-25
Cisco ASA 5500 Series Configuration Guide using ASDM
Chapter 68 Configuring IKE, Load Balancing, and NAC
Configuring Load Balancing
We have tested up to ten nodes in a load-balancing cluster. Larger clusters might work, but we do not
officially support such topologies.
Geographical Load Balancing
In a load balancing environment where the DNS resolutions are being changed at regular intervals, you
must carefully consider how to set the time to live (TTL) value. For the DNS load balance configuration
to work successfully with AnyConnect, the ASA name to address mapping must remain the same from
the time the ASA is selected until the tunnel is fully established. If too much time passes before the
credentials are entered, the lookup restarts and a different IP address may become the resolved address.
If the DNS mapping changes to a different ASA before the credentials are entered, the VPN tunnel fails.
Geographical load balancing for VPN often uses a Cisco Global Site Selector (GSS). The GSS uses DNS
for the load balancing, and the time to live (TTL) value for DNS resolution is defaulted to 20 seconds.
You can significantly decrease the likelihood of connection failures if you increase the TTL value on the
GSS. Increasing to a much higher value allows ample time for the authentication phase when the user is
entering credentials and establishing the tunnel.
To increase the time for entering credentials, you may also consider disabling Connect on Start Up.
Note Using a Cisco System VPN client, the geographical load balancing is not impacted, and the 20
second default setting is acceptable.
Mixed Cluster Scenarios
If you have a mixed configuration—that is, if your load-balancing cluster includes devices running a
mixture of ASA software releases or at least one ASA running ASA Release 7.1(1) or later and a VPN
3000 concentrator—the difference in weighting algorithms becomes an issue if the initial cluster master
fails and another device takes over as master.
The following scenarios illustrate the use of VPN load balancing in clusters consisting of a mixture of
ASAs running ASA Release 7.1(1) and ASA Release 7.0(x) software, as well as VPN 3000 Series
Concentrators.
Scenario 1: Mixed Cluster with No SSL VPN Connections
In this scenario, the cluster consists of a mixture of ASAs and VPN 3000 Concentrators. Some of the
ASA cluster peers are running ASA Release 7.0(x), and some are running Release 7.1(1). The pre-7.1(1)
and VPN 3000 peers do not have any SSL VPN connections, and the 7.1(1) cluster peers have only the
base SSL VPN license, which allows two SSL VPN sessions, but there are no SSL VPN connections. In
this case, all the connections are IPsec, and load balancing works fine.
The two SSL VPN licenses have a very small effect on the user’s taking advantage of the maximum IPsec
session limit, and then only when a VPN 3000 Concentrator is the cluster master. In general, the smaller
the number of SSL VPN licenses is on a ASA in a mixed cluster, the smaller the effect on the ASA 7.1(1)
device being able to reach its IPsec session limit in a scenario where there are only IPsec sessions.
Scenario 2: Mixed Cluster Handling SSL VPN Connections
Suppose, for example, a ASA running ASA Release 7.1(1) software is the initial cluster master; then that
device fails. Another device in the cluster takes over automatically as master and applies its own
load-balancing algorithm to determine processor loads within the cluster. A cluster master running ASA
Release 7.1(1) software cannot weight session loads in any way other than what that software provides.