Load-balancing is the ability to have Cisco VPN 3000 Clients shared
across multiple units without user intervention. It ensures that the public IP
address is highly available to users. For example, if the Cisco VPN 3000
Concentrator that services the public IP address fails, another VPN 3000
Concentrator in the cluster assumes the public IP address. It also allows
non-IP Security (PPTP and L2TP) and non-Cisco IPsec clients to connect to the
VPN 3000 Concentrator in the existing manner, although these VPN Clients are
not load-balanced or supported by secure session failover.

Note: Virtual Router Redundancy Protocol (VRRP) and load-balancing are
mutually exclusive of one another. VRRP cannot be enabled while load-balancing
is enabled and vice versa.

The information in this document is based on these software and
hardware versions:

VPN 3000 Software Client Software Releases 3.0 and later

VPN 3000 Concentrator Software Releases 3.0 and later

The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.

In a virtual cluster, VPN 3000 Concentrators work together as a
single entity. The cluster is known by one IP address to the outside VPN Client
space. This virtual IP address is not tied to a specific device in the VPN
cluster but is serviced by the virtual cluster master. The virtual IP address
has to be a routable address.

Virtual Cluster Agent (VCA)

VCA is added to the VPN 3000 code in order to control the
load-balancing on the VPN 3000 Concentrators. Minimal changes were made to the
IPsec code in order to handle the virtual cluster IP address.

Load Information

The master maintains the load information from all secondary
VPN 3000 Concentrators in the cluster. Each secondary sends load information in
the Keep Alive message exchange to the master. Load is calculated as a
percentage of current active sessions divided by the configured maximum-allowed
connections.

Enter the single IP address that represents the entire virtual cluster.
Choose an IP address that is within the public subnet address range shared by
all the VPN 3000 Concentrators in the virtual cluster. In this example,
172.18.124.254 is used as the virtual address. Make sure that you use the same
virtual address on all VPN 3000 Concentrators.

The VPN virtual cluster UDP port is the UDP port number that VCA uses
for its communication between VPN 3000 Concentrators. If another application
uses this port, enter the UDP destination port number you want to use for
load-balancing. The default port is 9023. Make sure that you use the same UDP
port on all the VPN 3000 Concentrators.

You can encrypt VCA communication in the load-balancing environment.
The VPN 3000 Concentrators in the virtual cluster can communicate via
LAN-to-LAN tunnels with the use of IPsec. In order to ensure that all
load-balancing information communicated between the VPN 3000 Concentrators is
encrypted, check Encryption. Note that this parameter is
optional. However, if enabled, it improves the load-balancing on the VPN 3000
Concentrators. If you use this option, ensure that all VPN 3000 Concentrators
use Encryption in your environment.

The IPsec Shared Secret option is available only if you check the
Encryption option. Enter the IPsec Shared Secret for the virtual cluster. The
Shared Secret is a common password that authenticates members of the virtual
cluster. IPsec uses the Shared Secret as a pre-shared key in order to establish
secure tunnels between virtual cluster peers. In the example in this document,
"cisco123" is used as the pre-shared key. Make sure that you enter the same key
on all the VPN 3000 Concentrators.

Check the Load-Balancing Enable box to include the VPN
3000 Concentrator in the virtual cluster. If you disable this parameter, then
load-balancing is disabled on this particular VPN 3000 Concentrator.

Enter a priority for the VPN 3000 Concentrator within the virtual
cluster. The priority is a number from 1 to 10 that indicates the likelihood of
this device becoming the virtual cluster master either at startup or if an
existing master fails. The higher you set the priority (10), the more likely
this device becomes the virtual cluster master. If your virtual cluster
includes different models of VPN 3000 Concentrators, it is recommended that you
choose the device with the greatest load capacity to be the virtual cluster
master. For this reason, priority defaults are hardware dependent (see this
table).

VPN Concentrator Model

Priority

3005

1

3015

3

3030

5

3060

7

3080

9

If your virtual cluster is made up of identical devices (for example,
if all the devices in the virtual cluster are VPN Concentrator 3060s), set the
priority of every device to 10. When all identical devices are
set to the highest priority, it shortens the length of time you need in order
to select the virtual cluster master.

If the devices in the virtual cluster are powered up at different
times, the first device to be powered up assumes the role of virtual cluster
master. Because every virtual cluster requires a master, each device in the
virtual cluster checks at power-up in order to ensure that the cluster has a
virtual master. If none exists, that device takes on the role. Devices powered
up and added to the cluster later become secondary devices.

If all the devices in the virtual cluster are powered up
simultaneously, the device with the highest priority setting becomes the
virtual cluster master. If two or more devices in the virtual cluster are
powered up simultaneously and both have the highest priority setting, the one
with the lowest IP address becomes the virtual cluster master.

Once the virtual cluster is established and operates, if the VPN 3000
Concentrator that holds the role of the virtual cluster master fails, the
secondary device with the highest priority setting takes over. If two or more
devices in the virtual cluster both have the highest priority setting, the one
with the lowest IP address becomes the virtual cluster master.

If the VPN 3000 Concentrators are behind a firewall that uses Network
Address Translation (NAT), then specify the NAT IP address here. In this
example, the VPN 3000 Concentrators are not behind any NAT device. If this is
the case, then enter 0.0.0.0. (default setting).

In order to monitor the load-balancing feature on the VPN 3000
Concentrator side, select Monitoring >
Statistics > Load Balancing, and make sure
that all the participating VPN 3000 Concentrators are listed as peers. On the
172.18.124.129 VPN Concentrator, you see 172.18.124.130 and 172.18.124.131 as
the peers. Note that 172.18.124.131 is the master VPN Concentrator.

On the 172.18.124.130 VPN Concentrator, you see 172.18.124.129 and
172.18.124.131 as the peers.

On the 172.18.124.131 VPN Concentrator, you see 172.18.124.129 and
172.18.124.130 as the peers. Role is listed as Master for the 172.18.124.131
VPN Concentrator.

If you enable Encryption under the Load Balancing
configuration window, you see the VCA/IPsec tunnels with your peer when you
select Monitoring > Sessions.

The master always attempts to have the least load as it is burdened
with an additional, inherent load. The master maintains all of the
administrative LAN-to-LAN sessions, calculates all other cluster member
loading, and handles all VPN Client redirects.

In a freshly configured, functioning cluster, the master has about a 1
percent load before any connections are established. Therefore, the master
redirects connections to backup VPN 3000 Concentrators until their percentage
of load is higher than the percentage of load on the master. For example, if
you have two 3030 devices in an "idle" state, the master has a 1 percent load,
and the secondary is given 30 connections (2 percent percent load) before the
master accepts connections.

In order to verify that the master accepts connections, you can lower
the maximum number of connections (Configuration >
System > General >
Sessions) to an artificially low number in order to quickly
increase the load placed on the backup VPN 3000 Concentrator.

In order to test the load-balancing feature, configure the VPN Client
to connect to the virtual IP address (172.18.124.254 in this case). The master
diverts the IPsec tunnel to one of the secondary VPN 3000 Concentrators that it
knows about. If you monitor the Session on the 172.18.124.129 VPN Concentrator,
it has accepted the VPN Client tunnel.

This screen shot is taken from the 172.18.124.129 VPN Concentrator. The
load on this VPN 3000 Concentrator is 1 percent (current connections/maximum
connection = 1/100 = 1%).

In this screen shot, the load on the master VPN Concentrator
(172.18.124.131) is 0 percent, the load on 172.18.124.129 is 1 percent, and the
load for 172.18.124.130 is 0 percent.

Encryption is enabled, but you do not see anything under
Monitoring > Sessions for IPsec/VCA
tunnels.

Make sure that Encryption is enabled on all
the VPN 3000 Concentrators that participate in load-balancing. Also make sure
that IPsec shared secret is correct on all the VPN 3000 Concentrators.

Load-balancing is enabled, but you do not see any peers under
Monitoring > Statistics >
Load-Balancing.

Ensure you can ping the other VPN 3000 Concentrators (public
and private interfaces). If you are able to ping, check your filters and make
sure that VCA in and VCA out rules are
enabled on the filters. In order to verify that, if you enable the
LBSSF class on the VPN 3000 Concentrator with severity to log
set to 1-8, you should see these messages in your logs: