Some Typical Mixed Cluster Scenarios; Scenario 1: Mixed Cluster With No Webvpn Connections; Scenario 2: Mixed Cluster Handling Webvpn Connections - Cisco PIX 500 Series Configuration Manual

Understanding Load Balancing

Some Typical 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 security appliance running ASA Release 7.1(1) 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
security appliances 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 WebVPN Connections

In this scenario, the cluster consists of a mixture of security appliances and VPN 3000 Concentrators.
Some of the security appliance 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 WebVPN sessions, but there
are no SSL VPN connections. In this case, all the connections are IPSec, and load balancing works fine.
The two WebVPN 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 WebVPN licenses is on a security appliance 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 WebVPN Connections

Suppose, for example, a security appliance 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. Therefore, it cannot assign a combination of IPSec and WebVPN session loads
properly to ASA devices running earlier versions nor to VPN 3000 Concentrators. Conversely, a VPN
3000 Concentrator acting as the cluster master cannot assign loads properly to an ASA Release 7.1(1)
security appliance. The following scenario illustrates this dilemma.
This scenario is similar to the previous one, in that the cluster consists of a mixture of security appliances
and VPN 3000 Concentrators. Some of the security appliance cluster peers are running ASA Release
7.0,(x) and some are running Release 7.1(1). In this case, however, the cluster is handling SSL VPN
connections as well as IPSec connections.
If a device that is running software earlier than ASA Release 7.1(1) is the cluster master, the master
applies the protocol and logic in effect prior to Release 7.1(1). That is, sessions might be directed to
load-balancing peers that have exceeded their session limit. In that case, the user is denied access.
If the cluster master is a device running ASA Release 7.0(x) software, the old session-weighting
algorithm applies only to the pre-7.1(1) peers in the cluster. No one should be denied access in this case.
Because the pre-7.1(1) peers use the session-weighting algorithm, they are more lightly loaded.
An issue arises, however, because you cannot guarantee that the 7.1(1) peer is always the cluster master.
If the cluster master fails, another peer assumes the role of master. The new master might be any of the
eligible peers. Because of the innately unpredictability of the results, we recommend that you avoid
configuring this type of cluster.
Cisco Security Appliance Command Line Configuration Guide
29-8
Chapter 29 Setting General IPSec VPN Parameters
OL-12172-03