Global Settings for HTTP Farm Profile

An HTTP farm profile is a configuration setting that manages content switching at the application layer (layer 7) for both HTTP and HTTPS traffic.

When a request is received by the Farm, the HTTP(S) Profile automatically sets the HTTP header X-Forwarded-For to the client IP address. Each HTTP(S) farm can manage multiple Services like a reverse proxy, so a single HTTP Virtual IP and Port pair can handle multiple load-balanced web services.

Each HTTP(S) service uses a combination of regular expressions (for virtual host and URL pattern) to manage all incoming connections whose HTTP header matches both.

Within the Global Settings for each configured farm, there are 2 types of settings:

1. Basic
2. Advanced

Basic Settings

Basic HTTP/S farm profile parameters include:

Name: A descriptive name for the farm profile.
Virtual IP and Port: The IP address and port that the farm profile will listen on.
Listener: The protocol that the farm profile will manage at layer 7 for content switching.

• HTTP: The virtual service will only understand plain HTTP content.
• HTTPS: The virtual service will understand Secure HTTP content, manage SSL handshakes, handle secure cipher configurations, SSL certificates (wildcard or SNI), etc., to perform SSL offload and relieve the real application servers from these heavy tasks.

HTTPS Parameters

When you select the secure HTTPS profile for your farm, it includes the following fields.

Disable SSLV2, Disable SSLV3, Disable TLSV1, Disable TLSV1.1, Disable TLSV1.2: You can choose to disable the insecure protocols SSLV2, SSLV3, TLSv1, TLSv1.1, and TLSv1.2 by selecting the corresponding buttons.
Ciphers: This field is used to specify a list of ciphers that your website will accept when using SSL connections. Ciphers are cryptographic algorithms that are used to encrypt and decrypt data. It is important to choose a strong set of ciphers to protect your website from attack.

HTTPS Cipher Options

All: Allows all ciphers to be managed by the HTTPS listener. This is the default setting.

High security: Enables the following ciphers:

• kEECDH+ECDSA+AES128
• kEECDH+ECDSA+AES256
• kEECDH+AES128
• kEECDH+AES256
• kEDH+AES128
• kEDH+AES256
• DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED
  These ciphers are sufficient to achieve an A+ rating in SSL Labs

Custom security: Allows you to choose which ciphers your website will accept when using SSL connections. You can do this by entering a list of ciphers in the Custom ciphers field.

Custom ciphers: Allows you to specify which ciphers are allowed or forbidden to be used by your website’s SSL connection. You must enter a list of ciphers in the same format as used by OpenSSL. This option is only available if Custom security is enabled.

Advanced Settings

This section includes additional settings you could include on the farm. These settings include:

Rewrite Location headers: This feature allows the load balancer to modify the Location and Content-Location headers in response to clients. If the headers contain the value of the backend server itself or the VIP but with a different protocol, the response will be modified to show the virtual host in the request.

If the toggle button enabled and compare backends is enabled, only the backend IP address will be compared. This is essential for redirecting a request to an HTTPS listener on the same server as the HTTP listener.

If the Rewrite Location headers directive is configured in the service section, then this directive will be ignored for that service.

HTTP verbs accepted: This field specifies which HTTP methods will be accepted by the load balancer. If a client makes a request using a method that is not allowed, the load balancer will return an error.

• Standard HTTP requests: These are the most common HTTP methods, such as GET, POST, and HEAD.
• Extended HTTP requests: These are HTTP methods that are used for more specialized tasks, such as PUT, DELETE, and OPTIONS.
• Standard WebDAV verbs: WebDAV (Web-based Distributed Authoring and Versioning) is a set of extensions to the HTTP protocol that allow users to collaborate on and manage files on a remote server. The WebDAV verbs include LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, OPTIONS, TRACE, MKACTIVITY, CHECKOUT, MERGE, and REPORT.
• MS extensions WebDAV verbs: These are extensions to the WebDAV protocol that were developed by Microsoft. The MS extensions WebDAV verbs include SUBSCRIBE, UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, and CONNECT.
• MS RPC extensions verbs: MS RPC (Remote Procedure Call) is a protocol that allows programs to call procedures on remote computers. The MS RPC extensions verbs are used to support RPC over HTTP.

Backend connection timeout: The amount of time the load balancer will wait for a connection to a backend server to be established. The default value is 20 seconds. If the connection is not established within this time period, the load balancer will mark the backend server as unavailable and will not send any traffic to it.

Frequency to check resurrected backends: The interval at which the load balancer will check to see if a backend server that was previously marked as unavailable is now reachable. The default value is 10 seconds. If the backend server is reachable, the load balancer will mark it as available and will start sending traffic to it again.

Backend response timeout: The amount of time the load balancer will wait for a response from a backend server to a client request. The default value is 45 seconds. If the response is not received within this time period, the load balancer will mark the backend server as unavailable and will return an error message to the client.

Client request timeout: The amount of time the load balancer will wait for a client to send a complete request. The default value is 30 seconds. If the complete request is not received within this time period, the load balancer will close the connection.

HTTP error messages

Personalized error messages: When a web code error is detected from the real servers, the farm service will display a custom message on your site. This is done by displaying a personalized HTML page for error codes 414, 500, 501, and 503.

Here’s a breakdown of the personalized error messages that are supported:

• 414: Request-URI Too Long: This error occurs when the length of the request URI exceeds the maximum allowed number of characters. To fix this, try shortening the URL or removing any unnecessary parameters.
• 500: Internal Server Error: This error occurs when the backend server encounters an unexpected error. This can be caused by a variety of factors, such as a problem with the backend server code or a database error. If you’re seeing this error, try reloading the page or contacting the website administrator.
• 501: Not Implemented: This error occurs when the backend server does not support the requested HTTP method. This can be caused by a problem with the backend server code or by a misconfiguration. If you’re seeing this error, try using a different HTTP method or contact the website administrator.
• 503: Service Unavailable: This error occurs when the load balancer cannot find an available backend server to handle the request. This can happen when all of the backend servers are down or when there is a problem with the load balancer configuration. If you’re seeing this error, try refreshing the page or coming back later.
• WAF 403: Forbidden: This error occurs when the web application firewall (WAF) is enabled and the WAF engine blocks the request. This can happen because the request is malicious or because it violates the WAF rules. If you’re seeing this error, try contacting the website administrator.

Headers

Global request and response headers allow you to manage headers for all of your configured services at once. You can add, modify, or delete headers, and any changes you make here will be applied to all of your services. If a header is already configured for a specific service, the global configuration will be ignored.

Use the following actions in this section:

• Create rule: Create a new global header.
• Delete: Remove an existing global header.

You can add, modify, or create header requests and responses in the section below.

Type: The type of HTTP header action to perform. This can be one of the following:

• Request: remove header: Removes a header from the client HTTP request.
• Request: modify header: Modifies a header in the client HTTP request.
• Request: add header: Adds a header to the client HTTP request.
• Response: remove header: Removes a header from the backend HTTP response.
• Response: modify header: Modifies a header in the backend HTTP response.
• Response: add header: Adds a header to the backend HTTP response.

Services Settings

LSLB farms with an HTTP profile allow you to deliver multiple web services and applications through the same virtual IP and port. This helps you to:

• Unify web applications through a single domain
• Manage virtual hosts
• Manage URLs
• Configure redirects
• Configure persistence and backends per service

Each service within an LSLB farm has different properties, health checks, persistence, header management, and a backend list. You can use regular expressions to match conditions that will specify the service to be used per request.

The HTTP farm profile core checks each service match condition in priority mode (which can be changed if needed). If no service is matched, the farm core returns an error (HTTP error 503). This is why specific multiple-service definitions are allowed.

If the URL and Host fields are not defined, all requests will match. The HTTP service conditions will be determined by a virtual host and/or a URL pattern.

You must create at least one service before you can add a backend. Once the new service is applied, the HTTP services will be evaluated from top to bottom in the list order. The first service to match in the Host and/or URL field will process the request.

Those service conditions are determined by URL or Host patterns.

Service conditions
Service conditions determine which service in an LSLB farm should handle a given request. Two common service conditions are:

• Virtual host: The domain name that must be present in the request for the service to match. To disable this condition, leave the field empty. Regular expressions are supported in PCRE format.
• URL pattern: The URL that must be present in the request for the service to match. To disable this condition, leave the field empty. Regular expressions are supported in PCRE format.
• Virtual Host and URL pattern: Both conditions must match for the service to be selected. If either condition does not match, the next service in the list will be checked. It is recommended to use at least one of these conditions, even if it is just as a default catch-all.

Rewrite Location headers: If the headers contain the value of the backend itself or the VIP (but with a different protocol), the response will be modified to show the virtual host in the request.

If the Enabled and Compare backends toggle button is enabled, then only the backend IP address will be compared. This is useful for redirecting requests to an HTTPS listener on the same server as the HTTP listener.

When Enable and Compare backends is selected, a flag called Enable path for Rewrite location Headers will be available. Enable this flag if you are working with Rewrite URLs. This value will force the service to check the URL responses and will change the response to the original if a rule is configured in Rewrite URLs. If this field is enabled, it will override the same directive in the global section.

Redirect

If a service has the redirect option enabled, the load balancer will redirect all requests to a specified URL, instead of sending them to a backend server.

Redirect type: There are two redirect types:

• Default: The URL is taken as an absolute host and path to redirect to.
• Append: The original request path is appended to the host and path you specified.

Redirect URL: This parameter controls where the client will be redirected after a request is answered. The client request is answered automatically by redirecting to a new URL. If you configure a redirect value, you should not configure backends for this service.

Redirect code: Several redirect HTTP codes can be used:

• 301 (Moved Permanently): This code tells the client that the requested resource has been permanently moved to the new URL.
• 302 (Moved Temporarily): This code tells the client that the requested resource has been temporarily moved to the new URL.
• 307 (Temporary Redirect): This code is similar to the 302 code, but it is recommended for use when the redirect is the result of an HTTP POST method.

Persistence

Persistence allows the load balancer to maintain a client’s session across multiple requests. This can be useful for applications that need to track the client’s state, such as shopping carts or login sessions.

No persistence: The load balancer will not control the client sessions. Requests will be delivered to backend servers randomly.

IP: Client address: The load balancer will use the client IP address to keep the client sessions open through the real servers.

BASIC: Basic authentication: The load balancer will use the HTTP basic authentication header to control the client sessions. For example, when a web page requests basic authentication from the client, an HTTP header will contain a string like the following:

HTTP/1.1 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2011 10:18:15 GMT
WWW-Authenticate: Basic realm="Secure Area"
Content-Type: text/HTML
Content-Length: 31

Then the client will answer with the header:

GET /private/index.html HTTP/1.1
Host: localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

This basic authentication string is used as an ID for the session to identify the client session.

PARM: A URI parameter: The load balancer will use a URI parameter to identify the client session. The URI parameter will be separated from the rest of the URL by a semicolon character. For example, in the URL http://www.example.com/private.php;EFD4Y7, the parameter EFD4Y7 will be used as the session identifier.

URL: A request parameter: The load balancer will use a request parameter to identify the client session. The request parameter will be sent through a GET parameter in the URL. For example, a client request like http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 should be configured with the parameter Persistence Session Identifier (sid value in this example) and the persistence session time to life (TTL).

COOKIE: The load balancer will use an HTTP cookie variable to identify the client session. The cookie name will be configured in the persistence session identifier field. For example:

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: sessionidexample=75HRSd4356SDBfrte

Additionally, the persistence session Time To Life (TTL) should be configured. This value manages the time that the load balancer saves when the client and the backend go without any activity.

HEADER: a request header: The load balancer will use an HTTP header custom field to identify the client session. The persistence session time to life and persistence session identifier is required to be configured. For example:

GET /index.html HTTP/1.1
Host: www.example.org
X-sess: 75HRSd4356SDBfrte

Farmguardian

HTTP farms provide a basic health check for backend servers. However, the Farmguardian configuration is recommended for more sophisticated health checks that can ensure that applications are healthy.

Some built-in or customized advanced health checks can be assigned to this service from the already created Farmguardian checks.

For more information on Farmguardian, see the Monitoring > Farmguardian section.

Note that once you select a Farmguardian check, it will be automatically applied to the farm.

HTTPS Backends: This toggle button indicates to the farm that the backend servers defined in the current service are using the HTTPS protocol, so the data will be encrypted before being sent.

Backends

All backend servers in an HTTP farm must use the same IP version (IPv4 or IPv6) as the farm VIP.

In other words, you cannot mix IPv4 and IPv6 backend servers in the same HTTP farm. This is because the load balancer needs to know the IP version of the backend servers in order to route traffic to them correctly.

Actions: You can use the following actions to manage existing backend servers:

• Create Backend: Opens the form to create and add backends.
• Enable Maintenance: This action puts a backend server in maintenance mode. This means that no new connections will be routed to the server, but existing connections will be allowed to continue. There are two ways to enable maintenance mode:
  1. Drain Mode: This mode keeps established connections and persistence (if enabled), but will not accept new connections.
  2. Cut Mode: This mode drops all active connections to the backend server.
• Disable Maintenance: This action takes a backend server out of maintenance mode. This allows new connections to be routed to the server again.
• Delete: This action removes a backend server from the configuration.

The following fields must be filled when you click the Create backend button.

• IP: The IP address of the backend server.
• Port: The port number of the backend server.
• Timeout: The amount of time that the load balancer will wait for a response from the backend server before marking it as unhealthy. This value overrides the global backend connection timeout, but it is limited to the selected farm.
• Weight: The weight of the backend server. A higher weight means that the load balancer will send more traffic to that server. The default weight is 1. Valid values are from 1 to 9.
• Priority: The priority of the backend server. A lower priority means that the load balancer will send traffic to that server first. The default service priority is 1. When a backend server fails, its priority is increased by 1. When the backend server becomes healthy again, its priority is decreased by 1. Active backend servers have priorities that are less than or equal to the service priority.
• Connection limit: The maximum number of concurrent connections that the backend server will handle. If this value is reached, new connections to the backend server will be blocked and the client will receive an HTTP 503 error.

Once you have configured the backend parameters, you can click the Apply button to create the backend.

Next Article: LSLB | Farms | Update | L4xNAT Profile