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.
This document assumes:
You have assigned IP addresses on your VPN 3000 Concentrators (on both public and private interfaces).
IPsec is configured on the VPN 3000 Concentrators for the VPN user. Refer to IPsec with VPN Client to VPN 3000 Concentrator Configuration Example for a sample configuration if IPsec is not configured.
VPN users are able to connect to all the VPN 3000 Concentrators with the use of their individually assigned public IP address.
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.
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
This table defines key words associated with VPN 3000 Concentrators and load-balancing.
|Virtual Cluster||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.|
This table shows public and private addresses for VPN 3000 Concentrators.
|VPN 3000 Concentrator||Private||Public|
|Interface||Subnet Mask||Interface||Subnet Mask|
These restrictions apply to load-balancing on VPN 3000 Concentrators:
Load-balancing can only occur with Cisco Release 3.x (or later) IPsec VPN Clients-to-LAN connections. Earlier VPN Clients can still connect to their target Ethernet2 (public) port IP address within the cluster.
Note: Load balancing can still work if both VPN Concentrators do not have the same software version loaded on them.
VPN virtual cluster IP address, User Datagram Protocol (UDP) port, and shared secret must be identical on every device in the virtual cluster.
All devices in the virtual cluster must be on the same public and private IP subnets.
A filter has to be applied on both public and private interfaces. The defaults are:
private filter on the private interface
public filter on the public interface
Ensure that the IP addresses are configured on the public and private interfaces and you are able to get to the Internet from your VPN 3000 Concentrator.
In order for load-balancing to work properly, you need to add a new rule in your current filters for VCA.
Note: The private filter by default has a "permit any" rule. Therefore, the addition of the VCA-specific rules to this filter might not be necessary).
In order to add this, select Configuration > Policy Management > Traffic Management > Assign Rules to filter.
Then, add VCA in and VCA out in your filter.
In order to configure load-balancing, select Configuration > System > Load Balancing, and configure these parameters:
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.
Reenter the IPsec Shared Secret.
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|
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).
This screen shot is taken from the 172.18.124.130 VPN Concentrator.
This screen shot is taken from the 172.18.124.131 VPN Concentrator.
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.
This screen shot is taken from the 172.18.124.129 VPN Concentrator.
Note: Virtual addresses are not pingable.
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:
32198 10/19/2001 10:08:05.260 SEV=8 LBSSF/25 RPT=42577 LBSSF received KEEPALIVE request from [10.32.1.130] 32199 10/19/2001 10:08:05.260 SEV=8 LBSSF/24 RPT=42573 LBSSF sent KEEPALIVE response to [10.32.1.130] 32200 10/19/2001 10:08:05.890 SEV=8 LBSSF/25 RPT=42578 LBSSF received KEEPALIVE request from [10.32.1.129] 32201 10/19/2001 10:08:05.890 SEV=8 LBSSF/24 RPT=42574 LBSSF sent KEEPALIVE response to [10.32.1.129] 32202 10/19/2001 10:08:06.260 SEV=8 LBSSF/25 RPT=42579 LBSSF received KEEPALIVE request from [10.32.1.130] 32203 10/19/2001 10:08:06.260 SEV=8 LBSSF/24 RPT=42575 LBSSF sent KEEPALIVE response to [10.32.1.130]
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.