Configuring IKEv2 Load Balancer
Download this chapter
Configuring IKEv2 Load BalancerConfiguring IKEv2 Load Balancer
 Feedback

Contents

Configuring IKEv2 Load Balancer

Last Updated: September 26, 2012

The IKEv2 Load Balancer feature provides support for enabling clusters of FlexVPN gateways and distributes incoming IKEv2 connection requests among FlexVPN gateways. It redirects the incoming FlexVPN or AnyConnect client requests to a least loaded FlexVPN gateway based on the system and crypto load factors.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for IKEv2 Load Balancer

  • For the server-side configuration, the Hot Standby Router Protocol (HSRP) and FlexVPN server (IKEv2 profile) must be configured.
  • For the client-side configuration, the FlexVPN client must be configured.

Information About IKEv2 Load Balancer

Overview of IKEv2 Load Balancer

The IKEv2 Load Balancer Support feature provides a Cluster Load Balancing (CLB) solution by redirecting requests from remote access clients to the Least Loaded Gateway (LLG) in the Hot Standby Router Protocol (HSRP) group or cluster. An HSRP cluster is a group of gateways or FlexVPN servers in a LAN or in an enterprise network. The CLB solution works with the IKEv2 redirect mechanism defined in RFC 5685 by redirecting requests to the LLG in the HSRP cluster.

The figure below shows the working of the Internet Key Exchange Version 2 (IKEv2) cluster load balancing solution.

Figure 1IKEv2 Cluster Load Balancing Solution


  1. An active HSRP gateway is elected as a "master" in the HSRP group and takes ownership of the Virtual IP address (VIP) for the group. The master maintains a list of gateways in the cluster, keeps track of the load on each gateway, and redirects the FlexVPN client requests to the LLG.
  2. The remaining gateways, termed as "slaves," send load updates to the master at periodic intervals.
  3. When an IKEv2 client connects to the HSRP VIP, the request first reaches the master, which in turn, redirects the request to the LLG in the cluster.

The components of the CLB solution are as follows:

  • HSRP
  • CLB master
  • CLB slave
  • CLB communication
  • IKEv2 redirects mechanism

Hot Standby Router Protocol

Hot Standby Router Protocol (HSRP) is used to elect the HSRP master or Active Router (AR). For HSRP to elect a designated device, you must configure the VIP for one device in the group. This address is learned by other devices in the group. The IP address that is assigned to the master is used as the VIP for the group. The HSRP active router (also called CLB master) receives the ikev2 requests and redirects these requests to the LLG in the cluster. The redirection is performed at the IKEv2 protocol level. This achieves the following:

  • All requests from the FlexVPN client reach the HSRP master as the VIP is configured on the FlexVPN clients. The configuration of FlexVPN clients is minimized because the FlexVPN clients must know the VIP of the HSRP cluster only.
  • The CLB master is run on the same gateway as the HSRP master, thereby maintaining the load information of all CLB slaves. The CLB master enables effective redirection and avoids multiple redirects and loops.

CLB Master

A CLB master runs on the HSRP master or "Active Router" (AR). The master receives updates from CLB slaves and sorts them based on their load condition to calculate the least loaded gateway (LLG). The master sends the IP address of the LLG to IKEv2 (on the FlexVPN server). The IP address is sent to the initiator (FlexVPN client), which initiates an IKEv2 session with the LLG. The master redirects incoming IKEv2 client connections towards the LLG. For more information, see section "IKEv2 Redirects Mechanism."


Note
"CLB nodes" are used where both a CLB master and CLB slave must be specified.

CLB Slave

A CLB slave runs on all devices in an HSRP group except on the Active Router (AR). The slaves are responsible for sending periodic load updates to the server. A CLB slave is a fully functional IKEv2 gateway which supplies information to the CLB master. Apart from updates, CLB slaves send messages for aliveness assurance to the CLB master.

CLB Load Management Mechanism

The CLB Load Management Mechanism is a TCP based protocol running between the CLB master and the CLB slaves. The CLB load management mechanism informs the CLB master about the load on the CLB slaves. Based on this information, the CLB master selects the LLG to handle the session on each new incoming IKEv2 connection.

Benefits of IKEv2 Load Balancer

  • The IKEv2 Load Balancer Support feature easy to configure and cost-effective.
  • A FlexVPN client need not know the IP addresses of all the gateways in the cluster. The client need only know the virtual IP address of the cluster.
  • The entire crypto session is redirected to a node in the cluster.

IKEv2 Redirect Mechanism

The IKEv2 redirect mechanism enables a VPN gateway to redirect a FlexVPN client request to another VPN gateway based on load condition and maintenance requirements.

The IKEv2 redirect mechanism is performed in the following scenarios:

  • On security association (SA) initialization (IKE_SA_INIT)
  • On SA authentication (IKE_AUTH)

Redirect During IKEv2 Initial Exchange (SA Initialization)

A FlexVPN client, an AnyConnect client indicates that it supports the IKEv2 redirect mechanism by including a REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT request. Use the crypto ikev2 redirect client command to enable the redirect mechanism on a client. Use the crypto ikev2 redirect gateway init command to enable redirect at SA_INIT on the gateway.

To redirect an IKEv2 request to another new gateway, the gateway that receives the IKE_SA_INIT request selects the IP address or the fully qualified domain name (FQDN) of the new gateway (in this case, the LLG) with help of crypto load balancer (CLB) module. The gateway replies with an IKE_SA_INIT response containing a REDIRECT notification message. The notification includes information such as the new gateway and the nonce value from the payload in the IKE_SA_INIT request. When a client receives the IKE_SA_INIT response, it verifies the nonce value sent in the IKE_SA_INIT request and the gateway information provided in the redirect notification and confirms whether the redirect notification is as per the configuration.


Note
If the nonce value does not match, the client discards the response and waits for another response, thereby preventing denial of service (DoS) attacks on the initiator. DoS attacks could be caused by an attacker injecting incorrect redirect payloads in IKE_SA_INIT responses.

In the IKE_SA_INIT exchange with the new gateway, the client message contains the REDIRECTED_FROM notification payload. The REDIRECTED_FROM notification payload consists of the IP address of the original VPN gateway that redirected the client. The IKEv2 exchange then proceeds as it would have proceeded with the original gateway.


Note
The client may be redirected again by the new gateway if the new gateway also cannot serve the client. The client does not include the REDIRECT_SUPPORTED payload again in the IKE_SA_INIT exchange with the new gateway after the redirect. The presence of the REDIRECTED_FROM notification payload in the IKE_SA_INIT exchange with the new gateway indicates to the new gateway that the client supports the IKEv2 redirects mechanism.

Redirect During IKE_AUTH Exchange (SA Authentication)

A thorough security analysis shows that redirect during IKE_AUTH is neither more nor less secure than redirect during IKE_INIT. However, for performance and scalability reasons, we recommend redirect during IKE_INIT. Use the crypto ikev2 redirect gateway auth command to enable the redirect mechanism on the gateway. Use the redirect gateway auth command to enable redirect on authentication for selected IKEv2 profiles.

In this method, the client authorization payload is verified before sending the redirect notification payload. A client also verifies the gateway authorization payload before acting on the redirect notification. As the authorization payload is exchanged and successfully verified, the IKEv2 security association (SA) is validated successfully and the INITIAL_CONTACT is processed to decide on redirecting the request. If there is a redirect, the gateway creates the IKE SA and sends the IKE_AUTH response with the redirect notification.

A child SA is not created in this method. The IKE_AUTH does not contain a payload pertaining to a child SA. When the client receives the IKE_AUTH response, the client verifies the gateway authentication payload and deletes the IKEv2 SA with the gateway by sending a delete notification. The client acts on the redirect notification payload to establish connection with the new gateway. The client does not wait for an acknowledgment for the delete notification before establishing a connection with the new gateway. If the IKE_AUTH exchange involves Extensible Authentication Protocol (EAP) authentication, the gateway has the choice of sending the redirect payload in the first or last IKE_AUTH response. The EAP authentication is included in the first IKE_AUTH response because it is not necessary to provide credentials for each redirect.

Compatibility and Interoperability

The IKEv2 redirect mechanism is based on RFC 5685. The gateway (IKEv2 responder) is compatible with clients (IKEv2 initiator) that implement the standard. Similarly, the client (initiator) implementation must be compatible with third party servers (responder) implementing the standard. The load management mechanism is Cisco proprietary and is only supported on Cisco IOS devices.

Handling Redirect Loops

A client request could be redirected multiple times in a sequence because of either an incorrect configuration or a denial of service (DoS) attack. In some cases, a client could enter a loop with two or more gateways redirecting the client to the other gateway. This could deny service to the client. To prevent this, a client can be configured, using the crypto ikev2 redirect client command with the max-redirects number keyword argument pair, to not accept more than a specific number of redirects for a particular IKEv2 security association (SA) setup.

How to Configure IKEv2 Load Balancer

Configuring the Server Cluster

Configuring an HSRP Group for Load Balancing

Perform this task to configure a single Hot Standby Router Protocol (HSRP) group for a cluster.

HSRP is used to elect the HSRP master or Active Router (AR). For HSRP to elect a designated device, you must configure the Virtual IP address (VIP) for one device in the group. This address is learned by other devices in the group. The IP address that is assigned to the master is used as the VIP for the group. The HSRP master receives the traffic that is addressed to the virtual IP address and routes and forwards the traffic to the Least Loaded Gateway (LLG) in the cluster. This achieves the following:

  • All requests from the FlexVPN client reach the HSRP master because the VIP is configured to the FlexVPN clients. The configuration of FlexVPN clients is minimized because the FlexVPN clients must know the VIP of the HSRP cluster only.
  • The Cluster Load Balancing (CLB) master is run on the same gateway as the HSRP master, thereby maintaining the load information of all CLB slaves. The CLB master enables effective redirection and avoids multiple redirects and loops.

Note
This task describes the minimum commands required to configure an HSRP group for load balancing.
SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ip address ip-address mask [secondary]

5.    standby [group-number] priority priority

6.    standby group-name

7.    exit

8.    Repeat Steps 3 to 7 on another device.


DETAILED STEPS
 Command or ActionPurpose
Step 1
enable


Example:

Device> enable

 

Enables privileged EXEC mode.

  • Enter your password if prompted.
 
Step 2
configure terminal


Example:

Device# configure terminal

 

Enters global configuration mode.

 
Step 3
interface type number


Example:

Device(config)# interface GigabitEthernet 0/0/0

 

Configures an interface type and enters interface configuration mode.

 
Step 4
ip address ip-address mask [secondary]


Example:

Device(config-if)# ip address 10.0.0.1 255.255.255.0

 

Specifies a primary or secondary IP address for an interface.

 
Step 5
standby [group-number] priority priority


Example:

Device(config-if)# standby 1 priority 110

 

Configures the HSRP priority.

 
Step 6
standby group-name


Example:

Device(config-if)# standby group1

 

Specifies the name of the HSRP standby group.

 
Step 7
exit


Example:

Device(config-if)# exit

 

Exits to global configuration mode.

 
Step 8
Repeat Steps 3 to 7 on another device.  

--

 

Configuring the Load Management Mechanism

SUMMARY STEPS

1.    enable

2.   configure terminal

3.   crypto ikev2 cluster

4.   holdtime milliseconds

5.   master {overload-limit percent | weight {crypto-load weight-number | system-load weight-number}}

6.   port port-number

7.   slave {hello milliseconds | max-session number | priority number | update milliseconds}

8.   standby-group group-name

9.   shutdown

10.    end


DETAILED STEPS
 Command or ActionPurpose
Step 1
enable


Example:

Device> enable

 

Enables privileged EXEC mode.

  • Enter your password if prompted.
 
Step 2
configure terminal


Example:

Device# configure terminal

 

Enters global configuration mode.

 
Step 3
crypto ikev2 cluster


Example:

Device(config)# crypto ikev2 cluster

 

Defines an IKEv2 cluster policy and enters IKEv2 cluster configuration mode.

 
Step 4
holdtime milliseconds


Example:

Device(config-ikev2-cluster)# holdtime 10000

 

(Optional) Specifies the time, in milliseconds, to receive messages from a peer.

  • If no messages are received within the configured time, the peer is declared "dead."
 
Step 5
master {overload-limit percent | weight {crypto-load weight-number | system-load weight-number}}


Example:

Device(config-ikev2-cluster)# master weight crypto-load 10

 

Specifies settings for the master in the HSRP cluster.

  • overload-limit percent--The threshold load of the cluster. The load limit to decide when a device is busy and to ignore it when redirecting it for requests.
  • weight--Specifies the weight of a load attribute. Range: 0 to 100. Default: 100.
  • crypto-load weight-number--The IKE and IPsec security association (SA) load.
  • system-load weight-number--The system and memory load.
 
Step 6
port port-number


Example:

Device(config-ikev2-cluster)# port 2000

 

(Optional) Specifies the cluster master listen port.

 
Step 7
slave {hello milliseconds | max-session number | priority number | update milliseconds}


Example:

Device(config-ikev2-cluster)# slave max-session 90

 

Specifies settings for slave gateways in the HSRP group.

  • hello milliseconds--The hello interval, in milliseconds, for a slave gateway.
  • max-session number--The maximum number of SAs allowed on a slave. This keyword is mandatory and cannot be skipped.
  • priority number--The slave priority.
  • update milliseconds--The interval, in milliseconds, between two update messages for a slave gateway.
 
Step 8
standby-group group-name


Example:

Device(config-ikev2-cluster)# standby-group group1

 

Defines the HSRP group containing the slaves.

  • group-name--The group name is derived from the group-name argument specified in the standby name command.
 
Step 9
shutdown


Example:

Device(config-ikev2-cluster)# shutdown

 

(Optional) Disables the IKEv2 cluster policy.

 
Step 10
end


Example:

Device(config-ikev2-cluster)# end

 

Exits IKEv2 cluster configuration mode and returns to privileged EXEC mode.

 

Activating the IKEv2 Redirect Mechanism on the Server

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    crypto ikev2 redirect gateway init

4.    end


DETAILED STEPS
 Command or ActionPurpose
Step 1
enable


Example:

Device> enable

 

Enables privileged EXEC mode.

  • Enter your password if prompted.
 
Step 2
configure terminal


Example:

Device# configure terminal

 

Enters global configuration mode.

 
Step 3
crypto ikev2 redirect gateway init


Example:

Device(config)# crypto ikev2 redirect gateway init

 

Enables the IKEv2 redirect mechanism on the gateway during SA initiation.

 
Step 4
end


Example:

Device(config)# end

 

Exits global configuration mode and returns to privileged EXEC mode.

 

Activating the IKEv2 Redirect Mechanism on the Client

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    crypto ikev2 redirect client [max-redirects number]

4.    end


DETAILED STEPS
 Command or ActionPurpose
Step 1
enable


Example:

Device> enable

 

Enables privileged EXEC mode.

  • Enter your password if prompted.
 
Step 2
configure terminal


Example:

Device# configure terminal

 

Enters global configuration mode.

 
Step 3
crypto ikev2 redirect client [max-redirects number]


Example:

Device(config)# crypto ikev2 redirect client max-redirects 15

 

Enables the IKEv2 redirect mechanism on the FlexVPN client.

  • max-redirects number--(Optional) Specifies the maximum number of redirects that can be configured on the FlexVPN client for redirect loop detection.
 
Step 4
end


Example:

Device(config)# end

 

Exits global configuration mode and returns to privileged EXEC mode.

 

Configuration Examples for IKEv2 Load Balancer

Example: Configuring an HSRP Group for Load Balancing

The following example shows RouterA configured as the active router for an Hot Standby Router Protocol (HSRP) group with a priority of 110. The default priority level is 100. This HSRP group is assigned the group name of group1. The group name is referred in the cluster policy. 

Device(config)# hostname RouterA
Device(config)# interface GigabitEthernet 0/0/0
Device(config-if)# ip address 10.0.0.1 255.255.255.0
Device(config-if)# standby 1 priority 110
Device(config-if)# standby group1
Device(config-if)# end

Example: Configuring the Load Management Mechanism

The following example shows how to configure the load management mechanism in IKEv2: 

Device> enable
Device# configure terminal
Device(config)# crypto ikev2 cluster
Device(config-ikev2-cluster)# holdtime 10000
Device(config-ikev2-cluster)# master crypto-load 10
Device(config-ikev2-cluster)# port 2000
Device(config-ikev2-cluster)# slave priority 90
Device(config-ikev2-cluster)# standby-group group1
Device(config-ikev2-cluster)# shutdown
Device(config-ikev2-cluster)# end

Example: Configuring the Redirect Mechanism

The following example shows how to enable the redirect mechanism on a client and during initiation on a gateway: 

Device> enable
Device# configure terminal
Device(config)# crypto ikev2 redirect client
Device(config)# crypto ikev2 redirect gateway init
Device(config)# end

Additional References

Related Documents

Related Topic Document Title

Cisco IOS commands

Master Command List, All Releases

Security commands

HSRP configuration

Configuring HSRP

HSRP commands

Cisco IOS First Hop Redundancy Protocols Command Reference

Standards and RFCs

Standard/RFC Title

RFC 5685

Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)

Technical Assistance

Description Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for IKEv2 Load Balancer

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 1Feature Information for IKEv2 Load Balancer Support
Feature Name Releases Feature Information

IKEv2 Load Balancer Support

15.2(4)M

The IKEv2 Load Balancer Support feature distributes incoming IKEv2 requests from FlexVPN clients among IKEv2 FlexVPN servers or gateways by redirecting requests to the least loaded gateway.

The following commands were introduced or modified: crypto ikev2 cluster, crypto ikev2 redirect, holdtime, master (IKEv2), port (IKEv2), redirect gateway, slave (IKEv2), standby-group, show crypto ikev2 cluster, show crypto ikev2 sa.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2012 Cisco Systems, Inc. All rights reserved.