Fortinet black logo

CLI Reference

config load-balance pool

config load-balance pool

Use this command to configure real server pool settings.

A server pool is a group of the real servers that host the applications that you load balance.

To configure a server pool:

  1. Create a server pool object.
  2. Add members.

Before you begin:

  • You must have a good understanding and knowledge of the backend server boot behavior, for example, how many seconds it takes to “warm up” after a restart before it can process traffic.
  • You must know the IP address and port of the applications.
  • You must have already created real server SSL profiles if you want to specify them in the real server configuration.
  • You must have read-write permission for load balancing settings.

After you have configured a real server pool, you can select it in the virtual server configuration.

Syntax

config load-balance pool

edit <name>

set addr-type {ipv4|ipv6}

set health-check-ctrl {enable|disable}

set health-check-list {<datasource> ...}

set health-check-relation {AND|OR}

set real-server-profile <datasource>

config pool_member

edit <No.>

set backup {enable|disable}

set connection-limit <integer>

set connection-rate-limit <integer>

set health-check-inherit {enable|disable}

set health-check-ctrl {enable|disable}

set health-check-list {<datasource> ...}

set health-check-relation {AND|OR}

set ip <class_ip>

set ip6 <class_ip>

set pool_member_cookie <string>

set pool_member_server_name <string>

set pool_member_service_port <integer>

set pool_member_weight <integer>

set recover <integer>

set rs-profile-inherit {enable|disable}

set real-server-profile <datasource>

set ssl {enable|disable}

set status {enable|disable|maintain}

set warm-rate <integer>

set warm-up <integer>

next

end

next

end

addr-type

  • IPv4
  • IPv6

health-check-ctrl

Enable health checking for the pool. The health check settings at this configuration level are the parent configuration. When you configure the pool members, you can specify whether to inherit or override the parent configuration.

health-check-list

Specify one or more health check configuration objects.

health-check-relation

  • AND—All of the specified health checks must pass for the server to be considered available.
  • OR—One of the specified health checks must pass for the server to be considered available.

real-server-profile

Specify a real server profile. Real server profiles determine settings for communication between FortiADC and the backend real servers.

config pool_member

backup

Server that the ADC directs traffic to only when other servers in the pool are down. The backup server receives connections when all the other pool members fail the health check or you have manually disabled them, for example.

Note: Not applicable for SIP servers.

connection-limit

Maximum number of concurrent connections to the backend server. The default is 0 (disabled). The valid range is 1 to 1,048,576 concurrent connections.

Note: Connection Limit is not supported for FTP or SIP servers.

connection-rate-limit

Limit the number of new connections per second to this server. The default is 0 (disabled). The valid range is 1 to 86,400 connections per second.

In Layer 4 deployments, you can apply a connection rate limit per real server and per virtual server. Both limits are enforced.

Note: The connection rate limit applies only when the real servers belong to a Layer 4 virtual server. If you add a real server pool with this setting configured to a Layer 7 virtual server, for example, the setting is ignored.

Note: Connection Rate Limit is not supported for FTP or SIP servers.

health-check-inherit

Enable to inherit the health check settings from the parent configuration. Disable to specify health check settings in this member configuration.

health-check-ctrl

Enable health checking for the pool.

health-check-list

Specify one or more health check configuration objects.

health-check-relation

  • AND—All of the selected health checks must pass for the server to the considered available.
  • OR—One of the selected health checks must pass for the server to be considered available.

ip

Backend server IP address.

In a Layer 2 virtual server deployment, specify the IP address of the next hop to the destination server. Configure a pseudo default gateway in the static route since Layer 2 virtual servers need to use this default route internally to match all the destinations that the client wants to access. However, this default gateway is not used because the next hop is the pool member and not the pseudo gateway. In a Layer 2 virtual server deployment, ensure the backend servers have been configured to route responses through the FortiADC IP address.

ip6

Backend server IP address.

In a Layer 2 virtual server deployment, specify the IP address of the next hop to the destination server. Configure a pseudo default gateway in the static route since Layer 2 virtual servers need to use this default route internally to match all the destinations that the client wants to access. However, this default gateway is not used because the next hop is the pool member and not the pseudo gateway. In a Layer 2 virtual server deployment, ensure the backend servers have been configured to route responses through the FortiADC IP address.

pool_member_cookie

Cookie name to be used when cookie-based Layer 7 session persistence is enabled. The cookie is used to create a FortiADC session ID, which enables the system to forward subsequent related requests to the same backend server.

If you do not specify a cookie name, it is set to the pool member server name string.

Note: Not applicable for SIP servers.

pool_member_server_name

Real server member configuration name to appear in logs and reports. Alphabetic, numeric, underscore (_), and hyphen (-) characters are allowed.

The setting is required.

pool_member_service_port

Backend server listening port number. Usually HTTP is 80, HTTPS is 443, FTP is 21, SMTP is 25, DNS is 53, POP3 is 110, IMAP4 is 143, RADIUS is 1812, and SNMP is 161.

Tip: The system handles port 0 as a “wildcard” port. When configured to use port 0, the system uses the destination port from the client request. For example, if you specify 0, and the destination port in the client request is 50000, the traffic is forwarded to port 50000.

pool_member_weight

Assigns relative preference among members—higher values are more preferred and are assigned connections more frequently. The default is 1. The valid range is 1 to 256.

All load balancing methods consider weight. Servers are dispatched requests proportional to their weight, relative to the sum of all weights.

The following example shows the effect of weight on Round Robin:

  • Sever A, Weight 2; Server B, Weight 1: Requests are sent AABAAB.
  • Sever A, Weight 3; Server B, Weight 2: Requests are sent AABAB.

For other methods, weight functions as a tie-breaker. For example, with the Least Connection algorithm, requests are sent to the server with the least connections. If the number of connections is equal, the request is sent to the server with the greater weight. For example:

  • Server A, Weight 1, 1 connection
  • Server B, Weight 2, 1 connection

The next request is sent to Server B.

recover

Seconds to postpone forwarding traffic after downtime, when a health check indicates that this server has become available again. The default is 0 (disabled). The valid range is 1 to 86,400 seconds.

After the recovery period elapses, the FortiADC assigns connections at the warm rate.

Examples of when the server experiences a recovery and warm-up period:

  • A server is coming back online after the health check monitor detected it was down.
  • A network service is brought up before other daemons have finished initializing and therefore the server is using more CPU and memory resources than when startup is complete.

To avoid connection problems, specify the separate warm-up rate, recovery rate, or both.

Tip: During scheduled maintenance, you can also manually apply these limits by setting Status to Maintenance instead of Enable.

Note: Not applicable for SIP servers.

rs-profile-inherit

Enable to inherit the real server profile from the pool configuration. Disable to specify the real server profile in this member configuration.

real-server-profile

If not configured to inherit the pool setting, specify a real server profile. Real server profiles determine settings for communication between FortiADC and the backend real servers.

status

  • enable—The server can receive new sessions.
  • disable—The server does not receive new sessions and closes any current sessions as soon as possible.
  • maintain—The server does not receive new sessions but maintains any current connections.

warm-rate

Maximum connection rate while the server is starting up. The default is 100 connections per second. The valid range is 1 to 86,400 connections per second.

The warm up calibration is useful with servers that have the network service brought up before other daemons have finished initializing. As the servers are brought online, CPU and memory are more utilized than they are during normal operation. For these servers, you define separate rates based on warm-up and recovery behavior.

For example, if Warm Up is 5 and Warm Rate is 2, the number of allowed new connections increases at the following rate:

  • 1st second—Total of 2 new connections allowed (0+2).
  • 2nd second—2 new connections added for a total of 4 new connections allowed (2+2).
  • 3rd second—2 new connections added for a total of 6 new connections allowed (4+2).
  • 4th second—2 new connections added for a total of 8 new connections allowed (6+2).
  • 5th second—2 new connections added for a total of 10 new connections allowed (8+2).

Note: Not applicable for SIP servers.

warm-up

If the server cannot initially handle full connection load when it begins to respond to health checks (for example, if it begins to respond when startup is not fully complete), indicate how long to forward traffic at a lesser rate. The default is 0 (disabled). The valid range is 1 to 86,400 seconds.

Note: Not applicable for SIP servers.

Example

FortiADC-VM # config load-balance pool

FortiADC-VM (pool) # edit lb-pool

Add new entry 'lb-pool' for node 1705

FortiADC-VM (lb-pool) # get

addr-type : ipv4

health-check-ctrl : disable

FortiADC-VM (lb-pool) # set health-check-ctrl enable

FortiADC-VM (lb-pool) # set ?

addr-type address type

health-check-ctrl health check control

*health-check-list health check list

health-check-relation health check relationship

FortiADC-VM (lb-pool) # set health-check-list lb-health-check

FortiADC-VM (lb-pool) # config pool_member

FortiADC-VM (pool_member) # edit 1

Add new entry '1' for node 1710

FortiADC-VM (1) # get

health-check-inherit: enable

status : enable

ssl : disable

backup : disable

ip : 0.0.0.0

ip6 :

pool_member_service_port: 80

pool_member_weight : 1

connection-limit : 0

recover : 0

warm-up : 0

warm-rate : 10

connection-rate-limit: 0

pool_member_cookie : cookie

FortiADC-VM (1) # set ip 192.168.100.1

FortiADC-VM (1) # end

FortiADC-VM (lb-pool) # end

config load-balance pool

Use this command to configure real server pool settings.

A server pool is a group of the real servers that host the applications that you load balance.

To configure a server pool:

  1. Create a server pool object.
  2. Add members.

Before you begin:

  • You must have a good understanding and knowledge of the backend server boot behavior, for example, how many seconds it takes to “warm up” after a restart before it can process traffic.
  • You must know the IP address and port of the applications.
  • You must have already created real server SSL profiles if you want to specify them in the real server configuration.
  • You must have read-write permission for load balancing settings.

After you have configured a real server pool, you can select it in the virtual server configuration.

Syntax

config load-balance pool

edit <name>

set addr-type {ipv4|ipv6}

set health-check-ctrl {enable|disable}

set health-check-list {<datasource> ...}

set health-check-relation {AND|OR}

set real-server-profile <datasource>

config pool_member

edit <No.>

set backup {enable|disable}

set connection-limit <integer>

set connection-rate-limit <integer>

set health-check-inherit {enable|disable}

set health-check-ctrl {enable|disable}

set health-check-list {<datasource> ...}

set health-check-relation {AND|OR}

set ip <class_ip>

set ip6 <class_ip>

set pool_member_cookie <string>

set pool_member_server_name <string>

set pool_member_service_port <integer>

set pool_member_weight <integer>

set recover <integer>

set rs-profile-inherit {enable|disable}

set real-server-profile <datasource>

set ssl {enable|disable}

set status {enable|disable|maintain}

set warm-rate <integer>

set warm-up <integer>

next

end

next

end

addr-type

  • IPv4
  • IPv6

health-check-ctrl

Enable health checking for the pool. The health check settings at this configuration level are the parent configuration. When you configure the pool members, you can specify whether to inherit or override the parent configuration.

health-check-list

Specify one or more health check configuration objects.

health-check-relation

  • AND—All of the specified health checks must pass for the server to be considered available.
  • OR—One of the specified health checks must pass for the server to be considered available.

real-server-profile

Specify a real server profile. Real server profiles determine settings for communication between FortiADC and the backend real servers.

config pool_member

backup

Server that the ADC directs traffic to only when other servers in the pool are down. The backup server receives connections when all the other pool members fail the health check or you have manually disabled them, for example.

Note: Not applicable for SIP servers.

connection-limit

Maximum number of concurrent connections to the backend server. The default is 0 (disabled). The valid range is 1 to 1,048,576 concurrent connections.

Note: Connection Limit is not supported for FTP or SIP servers.

connection-rate-limit

Limit the number of new connections per second to this server. The default is 0 (disabled). The valid range is 1 to 86,400 connections per second.

In Layer 4 deployments, you can apply a connection rate limit per real server and per virtual server. Both limits are enforced.

Note: The connection rate limit applies only when the real servers belong to a Layer 4 virtual server. If you add a real server pool with this setting configured to a Layer 7 virtual server, for example, the setting is ignored.

Note: Connection Rate Limit is not supported for FTP or SIP servers.

health-check-inherit

Enable to inherit the health check settings from the parent configuration. Disable to specify health check settings in this member configuration.

health-check-ctrl

Enable health checking for the pool.

health-check-list

Specify one or more health check configuration objects.

health-check-relation

  • AND—All of the selected health checks must pass for the server to the considered available.
  • OR—One of the selected health checks must pass for the server to be considered available.

ip

Backend server IP address.

In a Layer 2 virtual server deployment, specify the IP address of the next hop to the destination server. Configure a pseudo default gateway in the static route since Layer 2 virtual servers need to use this default route internally to match all the destinations that the client wants to access. However, this default gateway is not used because the next hop is the pool member and not the pseudo gateway. In a Layer 2 virtual server deployment, ensure the backend servers have been configured to route responses through the FortiADC IP address.

ip6

Backend server IP address.

In a Layer 2 virtual server deployment, specify the IP address of the next hop to the destination server. Configure a pseudo default gateway in the static route since Layer 2 virtual servers need to use this default route internally to match all the destinations that the client wants to access. However, this default gateway is not used because the next hop is the pool member and not the pseudo gateway. In a Layer 2 virtual server deployment, ensure the backend servers have been configured to route responses through the FortiADC IP address.

pool_member_cookie

Cookie name to be used when cookie-based Layer 7 session persistence is enabled. The cookie is used to create a FortiADC session ID, which enables the system to forward subsequent related requests to the same backend server.

If you do not specify a cookie name, it is set to the pool member server name string.

Note: Not applicable for SIP servers.

pool_member_server_name

Real server member configuration name to appear in logs and reports. Alphabetic, numeric, underscore (_), and hyphen (-) characters are allowed.

The setting is required.

pool_member_service_port

Backend server listening port number. Usually HTTP is 80, HTTPS is 443, FTP is 21, SMTP is 25, DNS is 53, POP3 is 110, IMAP4 is 143, RADIUS is 1812, and SNMP is 161.

Tip: The system handles port 0 as a “wildcard” port. When configured to use port 0, the system uses the destination port from the client request. For example, if you specify 0, and the destination port in the client request is 50000, the traffic is forwarded to port 50000.

pool_member_weight

Assigns relative preference among members—higher values are more preferred and are assigned connections more frequently. The default is 1. The valid range is 1 to 256.

All load balancing methods consider weight. Servers are dispatched requests proportional to their weight, relative to the sum of all weights.

The following example shows the effect of weight on Round Robin:

  • Sever A, Weight 2; Server B, Weight 1: Requests are sent AABAAB.
  • Sever A, Weight 3; Server B, Weight 2: Requests are sent AABAB.

For other methods, weight functions as a tie-breaker. For example, with the Least Connection algorithm, requests are sent to the server with the least connections. If the number of connections is equal, the request is sent to the server with the greater weight. For example:

  • Server A, Weight 1, 1 connection
  • Server B, Weight 2, 1 connection

The next request is sent to Server B.

recover

Seconds to postpone forwarding traffic after downtime, when a health check indicates that this server has become available again. The default is 0 (disabled). The valid range is 1 to 86,400 seconds.

After the recovery period elapses, the FortiADC assigns connections at the warm rate.

Examples of when the server experiences a recovery and warm-up period:

  • A server is coming back online after the health check monitor detected it was down.
  • A network service is brought up before other daemons have finished initializing and therefore the server is using more CPU and memory resources than when startup is complete.

To avoid connection problems, specify the separate warm-up rate, recovery rate, or both.

Tip: During scheduled maintenance, you can also manually apply these limits by setting Status to Maintenance instead of Enable.

Note: Not applicable for SIP servers.

rs-profile-inherit

Enable to inherit the real server profile from the pool configuration. Disable to specify the real server profile in this member configuration.

real-server-profile

If not configured to inherit the pool setting, specify a real server profile. Real server profiles determine settings for communication between FortiADC and the backend real servers.

status

  • enable—The server can receive new sessions.
  • disable—The server does not receive new sessions and closes any current sessions as soon as possible.
  • maintain—The server does not receive new sessions but maintains any current connections.

warm-rate

Maximum connection rate while the server is starting up. The default is 100 connections per second. The valid range is 1 to 86,400 connections per second.

The warm up calibration is useful with servers that have the network service brought up before other daemons have finished initializing. As the servers are brought online, CPU and memory are more utilized than they are during normal operation. For these servers, you define separate rates based on warm-up and recovery behavior.

For example, if Warm Up is 5 and Warm Rate is 2, the number of allowed new connections increases at the following rate:

  • 1st second—Total of 2 new connections allowed (0+2).
  • 2nd second—2 new connections added for a total of 4 new connections allowed (2+2).
  • 3rd second—2 new connections added for a total of 6 new connections allowed (4+2).
  • 4th second—2 new connections added for a total of 8 new connections allowed (6+2).
  • 5th second—2 new connections added for a total of 10 new connections allowed (8+2).

Note: Not applicable for SIP servers.

warm-up

If the server cannot initially handle full connection load when it begins to respond to health checks (for example, if it begins to respond when startup is not fully complete), indicate how long to forward traffic at a lesser rate. The default is 0 (disabled). The valid range is 1 to 86,400 seconds.

Note: Not applicable for SIP servers.

Example

FortiADC-VM # config load-balance pool

FortiADC-VM (pool) # edit lb-pool

Add new entry 'lb-pool' for node 1705

FortiADC-VM (lb-pool) # get

addr-type : ipv4

health-check-ctrl : disable

FortiADC-VM (lb-pool) # set health-check-ctrl enable

FortiADC-VM (lb-pool) # set ?

addr-type address type

health-check-ctrl health check control

*health-check-list health check list

health-check-relation health check relationship

FortiADC-VM (lb-pool) # set health-check-list lb-health-check

FortiADC-VM (lb-pool) # config pool_member

FortiADC-VM (pool_member) # edit 1

Add new entry '1' for node 1710

FortiADC-VM (1) # get

health-check-inherit: enable

status : enable

ssl : disable

backup : disable

ip : 0.0.0.0

ip6 :

pool_member_service_port: 80

pool_member_weight : 1

connection-limit : 0

recover : 0

warm-up : 0

warm-rate : 10

connection-rate-limit: 0

pool_member_cookie : cookie

FortiADC-VM (1) # set ip 192.168.100.1

FortiADC-VM (1) # end

FortiADC-VM (lb-pool) # end