Guest

Cisco VPN 3000 Series Concentrators

Configuring Load-Balancing on VPN 3000 Concentrators

Document ID: 7602

Updated: Feb 02, 2006

   Print

Introduction

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.

Prerequisites

Requirements

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.

Components Used

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.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

Key Definitions

This table defines key words associated with VPN 3000 Concentrators and load-balancing.

Key Word Definition
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.

Network Diagram

lb_bl_vpn3000_7602_a.gif

Addresses

This table shows public and private addresses for VPN 3000 Concentrators.

VPN 3000 Concentrator Private Public
Interface Subnet Mask Interface Subnet Mask
3005 10.32.1.129 255.255.128.0 172.18.124.129 255.255.255.0
3030 10.32.1.130 255.255.128.0 172.18.124.130 255.255.255.0
3060 10.32.1.131 255.255.128.0 172.18.124.131 255.255.255.0

Restrictions

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

Configuration

IP Address Assignment

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.

Filter Configuration

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.

lb_bl_vpn3000_7602_b.gif

Then, add VCA in and VCA out in your filter.

lb_bl_vpn3000_7602_c.gif

Cluster Configuration

In order to configure load-balancing, select Configuration > System > Load Balancing, and configure these parameters:

lb_bl_vpn3000_7602_d.gif

VPN Virtual Cluster IP Address

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.

VPN Virtual Cluster UDP Port

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.

Encryption

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.

IPsec Shared Secret

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.

Verify Shared Secret

Reenter the IPsec Shared Secret.

Load-Balancing Enable

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.

Priority

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.

NAT Assigned IP Address

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.

lb_bl_vpn3000_7602_e.gif

This screen shot is taken from the 172.18.124.131 VPN Concentrator.

lb_bl_vpn3000_7602_f.gif

Monitoring

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.

lb_bl_vpn3000_7602_g.gif

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

lb_bl_vpn3000_7602_h.gif

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.

lb_bl_vpn3000_7602_i.gif

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.

lb_bl_vpn3000_7602_j.gif

lb_bl_vpn3000_7602_k.gif

lb_bl_vpn3000_7602_l.gif

Test the Load-Balancing Feature

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.

lb_bl_vpn3000_7602_m.gif

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%).

lb_bl_vpn3000_7602_n.gif

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.

lb_bl_vpn3000_7602_o.gif

Troubleshoot

Problem Solution
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]

Related Information

Updated: Feb 02, 2006
Document ID: 7602