|
LED
|
Meaning
|
|
?
|
Connected
|
|
?
|
Not Monitored
|
|
?
|
Draining
|
|
?
|
Offline
|
|
?
|
Standby
|
|
?
|
Not Connected
|
|
?
|
Finding Status
|
|
?
|
Not licensed or licensed Real Servers exceeded
|
|
Option
|
Description
|
|
Online
|
All Real Servers assigned Online will receive traffic according to the load balancing policy set within the Basic tab.
|
|
Drain
|
All Real Servers assigned as Drain will continue to serve existing connections but will not accept any new connections. The Status light will flash green/blue while the drain is in process. Once the existing connections have closed naturally, the Real Servers will go offline, and the Status light will be solid blue. You can also view these connections by navigating to the Navigation > Monitor > Status section.
The Drain Behaviour can be changed in the Advanced setting tab.
|
|
Offline
|
All Real Servers set as Offline will immediately be taken offline and will not receive any traffic.
|
|
Standby
|
All Real Servers set as Standby will remain offline until ALL the Online group servers fail their Server Health Monitor checks. Traffic is received by the Standby group as per the load balancing policy when this happens. If one server in the Online group passes the Server Health Monitor check, this Online server will receive all the traffic, and the Standby group will stop receiving traffic.
|
|
Option
|
Description
|
|
Least Connections
|
The load balancer will keep track of the number of current connections to each Real Server. The Real Server with the least number of connections receives the subsequent new request.
|
|
Fastest
|
The Fastest load balancing policy automatically calculates the response time for all requests per server smoothed over time. The Calculated Weight column contains the automatically calculated value. Manual entry is only possible when using this load balancing policy.
|
|
Persistent Cookie
|
Layer 7 Session Affinity/Persistence
The IP list-based load balancing mode is used for each first request. The ADC inserts a cookie into the headers of the first HTTP response. After that, the ADC uses the client cookie to route traffic to the same back-end server. This cookie is used for persistence when the client must go to the same back-end server each time. The cookie will expire after 2 hours, and the connection will be load balanced according to an IP List Based algorithm. This expiry time is configurable using a jetPACK.
|
|
Round Robin
|
Round Robin is commonly used in firewalls and basic load balancers and is the simplest method. Each Real Server receives a new request in sequence. This method is only proper when you need to load balance requests to servers evenly; an example would be look-up web servers. However, when you need to load balance based on application load or the server load, or even ensure that you use the same server for the session, the Round Robin method is inappropriate.
|
|
IP Bound
|
Layer 3 Session Affinity/Persistence Cookie.
In this mode, the client's IP address forms the basis to select which Real Server will receive the request. This action provides persistence. HTTP and Layer 4 protocols can use this mode. This method is helpful for internal networks where the network topology is known, and you can be confident that there are no "super proxies" upstream. With Layer 4 and proxies, all the requests can look as if they are coming from one client, and as such, the load would not be even. With HTTP, the header (X-Forwarder—For) information is used when present to cope with proxies.
|
|
IP List Based
|
The connection to the Real Server initiates using "Least connections" then, session affinity is achieved based on the client's IP address. A list is maintained for 2 hours by default, but this can be changed using a jetPACK.
|
|
Shared IP List Based
|
This service type is only available when the Connectivity Mode is set to Direct Server Return. It has been primarily added for support with VMware load balancing.
|
|
Persistent Cookie
|
Layer 7 Session Affinity/Persistence
The IP list-based load balancing mode is used for each first request. The ADC inserts a cookie into the headers of the first HTTP response. After that, the ADC uses the client cookie to route traffic to the same back-end server. This cookie is used for persistence when the client must go to the same back-end server each time. The cookie will expire after 2 hours, and the connection will be load balanced according to an IP List Based algorithm. This expiry time is configurable using a jetPACK.
|
|
Classic ASP Session Cookie
|
Active Server Pages (ASP) is a Microsoft server-side technology. With this option selected, the ADC will maintain session persistence to the same server if an ASP cookie is detected and found in its known cookies list. On detection of a new ASP cookie, it will be load balanced using the Least Connections algorithm.
|
|
ASP.NET Session Cookie
|
This mode applies to ASP.net. With this mode selected, the ADC will maintain session persistence to the same server if an ASP.NET cookie is detected and found in its list of known cookies. On detection of a new ASP cookie, it will be load balanced using the Least Connections algorithm.
|
|
JSP Session Cookie
|
Java Server Pages (JSP) is an Oracle server-side technology. With this mode selected, the ADC will maintain session persistence to the same server if a JSP cookie is detected and found in its known cookies list. On detection of a new JSP cookie, it will be load balanced using the Least Connections algorithm.
|
|
JAX-WS Session Cookie
|
Java web services (JAX-WS) is an Oracle server-side technology. With this mode selected, the ADC will maintain session persistence to the same server if a JAX-WS cookie is detected and found in its list of known cookies. On detection of a new JAX-WS cookie, it will load balanced using the Least Connections algorithm.
|
|
PHP Session Cookie
|
Personal Home Page (PHP) is an open-source server-side technology. With this mode selected, the ADC will maintain session persistence to the same server when a PHP cookie is detected.
|
|
RDP Cookie Persistence
|
This load balancing method uses the Microsoft-created RDP Cookie based on username/domain to provide persistence to a server. The advantage of this method means maintaining a connection to a server is possible even if the IP address of the client changes.
|
|
Cookie-ID Based
|
A new method very much like "PhpCookieBased" and other load-balancing methods, but using CookieIDBased and cookie RegEx h=[^;]+
This method will use the value set in the Real Server’s notes field "ID=X;" as the cookie value to identify the server. This, therefore, means it is a similar methodology as CookieListBased but uses a different cookie name and stores a unique cookie value, not the scrambled IP, but the ID from the Real Server (read in at load-time.)
The Default value is CookieIDName="h"; however, if there is an override value in the virtual server’s advanced settings configuration, use this instead. NOTE: We overwrite the cookie expression above to replace h= with the new value if this value is set.
The last bit is that if an unknown cookie value arrives and matches one of the Real Server IDs, it should select that server; otherwise, use the next method (delegate.)
|
|
Option
|
Description
|
|
None
|
In this mode, the Real Server is not monitored and is always up and running correctly. The None setting is helpful for situations where monitoring upsets a server and for services that should not join in the fail-over action of the ADC. It is a route to host unreliable or legacy systems that are not primary to H/A operations. Use this monitoring method with any service type.
|
|
Ping/ICMP Echo
|
In this mode, the ADC sends an ICMP echo request to the IP of the content server. If a valid echo response is received, the ADC deems the Real Server up and running, and traffic throughput to the server continues. It will also keep the service available on a H/A pair. This monitoring method is usable with any service type.
|
|
TCP Connection
|
A TCP connection is made to the Real Server and immediately broken without sending any data in this mode. If the connection succeeds, the ADC deems the Real Server to be up and running. This monitoring method is usable with any service type, and UDP services are currently not appropriate for TCP Connection monitoring.
|
|
ICMP Unreachable
|
The ADC will send a UDP health check to the server and mark the Real Server as unavailable if it receives an ICMP port unreachable message. This method can be helpful when you need to check if a UDP service port is available on a server, such as DNS port 53.
|
|
RDP
|
In this mode, a TCP connection initializes as explained in the ICMP Unreachable method. After the connection initializes, a Layer 7 RDP connection is requested. If the link is confirmed, the ADC deems the Real Server to be up and running. This monitoring method is usable with any Microsoft terminal server.
|
|
200 OK
|
In this method, a TCP connection initializes to the Real Server. After the connection succeeds, the ADC sends the Real Server an HTTP request. An HTTP response is waited for and checked for the "200 OK" response code. The ADC deems the Real Server up and running if the "200 OK" response code is received. If the ADC does not receive a "200 OK" response code for any reason, including timeouts, failure to connect, and other reasons, the ADC marks the Real Server unavailable. This monitoring method is only valid for use with HTTP and accelerated HTTP service types. If a Layer 4 Service type is used for an HTTP server, it is useable if SSL is not in use on the Real Server or handled appropriately by the "Content SSL" facility.
|
|
DICOM
|
A TCP connection initializes to the Real Server in DICOM mode, and an Echoscu "Associate Request" is made to the Real Server on connection. A conversation that includes an "Associate Accept" from the content server, a transfer of a small amount of data followed by a "Release Request," then "Release Response" successfully concludes the monitor. If the monitor does not complete successfully, then the Real Server is regarded as down for any reason.
|
|
User Defined
|
Any monitor configured in the Real Server Monitoring section will appear in the list.
|
|
Option
|
Description
|
|
By Host
|
Caching per host is based on application per hostname. A separate Cache will exist for each domain/hostname. This mode is ideal for web servers that can serve multiple websites depending on the domain.
|
|
By Virtual Service
|
Caching per virtual service is available when you choose this option. Only one Cache will exist for all domain/hostnames that pass through the virtual service. This option is a specialist setting for use with multiple clones of a single site.
|
|
Option
|
Description
|
|
Off
|
Turn compression off for the Virtual Service
|
|
Compression
|
When selected, this option turns on the compression for the selected Virtual Service. The ADC dynamically compresses the data stream to the client upon request. This process only applies to objects that contain the content-encoding: gzip header. Example content includes HTML, CSS, or JavaScript. You can also exclude certain content types using the Global Exclusions section.
|
|
Option
|
Description
|
|
No SSL
|
Traffic from the source to the ADC is not encrypted.
|
|
All
|
Loads all available certificates for use
|
|
Default
|
This option results in applying a locally created certificate called "Default" to the browser side of the channel. Use this option to test SSL when one hasn't been created or imported.
|
|
Option
|
Description
|
|
No SSL
|
Traffic from the ADC to the Real Server is not encrypted. The selection of a certificate on the browser side means "No SSL" can be chosen client-side to provide what is known as "SSL Offload."
|
|
Any
|
The ADC acts as a client and will accept any certificate the Real Server presents. Traffic from the ADC to the Real Server is encrypted when this option is selected. Use the "Any" option when a certificate is specified on the Virtual Service side, providing what is known as "SSL Bridging" or "SSL Re-Encryption."
|
|
SNI
|
SNI, or Server Name Indication is an extension to the TLS networking protocol using which the client indicates what hostname it is attempting to connect to at the start of the handshaking process. This setting allows the ADC to present multiple certificates on the same virtual IP address and TCP port.
|
|
Default
|
Any self-signed certificates that you have generated appear here.
|
|
Option
|
Description
|
|
Reverse Proxy
|
Reverse Proxy is the default value and uses compression and caching when used with Layer 7. At Layer 4, reverse proxy works without caching or compression. In this mode, your ADC acts as a reverse proxy and becomes the source address seen by the Real Servers.
|
|
Direct Server Return
|
Direct Server Return or DSR also known DR – Direct Routing, allows the server behind the load balancer to respond directly to the client bypassing the ADC on the response. DSR is only suitable for use with Layer 4 load balancing. Therefore, Caching and Compression are not available with this option chosen.
This mode can only be used with TCP, UDP, and TCP/UDP service types.
Load balancing persistence policies are also restricted to Least Connections, Shared IP List Based, Round Robin and IP List Based.
 Using DSR also requires Real Server changes to be done. Please refer to the Real Server Changes section.
|
|
NAT
|
By default, the ADC uses the IP address of the ADC as the Source IP address, and the Real Servers then send the response back to the ADC for return to the Client. This is fine in almost all circumstances, but there are scenarios when the Real Server needs to see the Source IP address of the Client and not the ADC.
When NAT mode is applied, the ADC receives the incoming request, and then sends it to the Real Server after it changes the Source IP address back to that of the Virtual Service (VIP address).
This mode can only be used with the following Load Balancing Policies:
 |
|
Gateway
|
Gateway mode allows you to route all traffic through the ADC, allowing the Real Servers to be routed via the ADC to other networks via the ADC virtual services or hardware interfaces. Using the device as a gateway device for Real Servers is ideal when running in multi-interface mode.
Load balancing persistence policies are also restricted to Least Connections, Shared IP List Based, Round Robin and IP List Based.
This method requires that the Real Server sets its default gateway to the ADC's local interface address (eth0, eth1, etc.). Please refer to the Real Server Changes section.
Please note that Gateway mode does not support failover in a cluster environment.
|
|
Option
|
Description
|
|
None
|
When there is no Proxy header, or its not supported in the current Service type
|
|
Remove
|
Removes the Proxy header from the TCP packet
|
|
Forward
|
Forwards the Proxy header to the server
|
|
Option
|
Description
|
|
Version 1
|
Text-based format, easy to implement and debug.
Provides basic information about the client's connection, including source IP, destination IP, source port, and destination port.
The protocol line is added to the start of the TCP connection, making it human-readable but slightly less efficient in terms of performance compared to binary formats.
|
|
Version 2
|
Binary format, designed for enhanced performance and efficiency.
Extends the information that can be relayed about the connection, supporting additional data like address family and protocol-specific information.
Ensures better compatibility with modern network protocols and features, including support for IPv6 and transport protocols beyond TCP.
|
|
Option
|
Description
|
|
Base IP (Default)
|
Uses the eth0, or Base IP address of the ADC as the Source IP of the request.
|
|
Virtual IP
|
Uses the Virtual IP of the service.
|
|
<IP Address>
|
Allows you to specify an IP address that is part of the ADC. This could be a different network interface or a different VIP.
|
|
Option
|
Description
|
|
Persistence Driven
|
This is the default selection.
Whenever the user visits using the persistence session, it is extended.
With 24-hour usage, it is possible that the drain would never happen.
However, if the number of connections to the real server ever reaches 0, drain ends, persistence sessions are deleted, and all visitors get re-balanced on the next connection they make.
|
|
Migrate Visitors
|
Persistent session ignored on re-connect - (legacy behavior before 2022)
New TCP connections (whether part of an existing session or not) are always made to an online real server.
If the persistence session was to a draining real server, it is overwritten.
The Virtual Service will effectively ignore persistence on any new connections, and they will be load balanced to a new server.
|
|
Retire Sessions
|
Persistent sessions not extended.
Incoming user connections will be allocated to their desired server, but their persistence session is not extended. So, after the persistence session time is exceed, they will be treated as new connection and moved to a different server.
|
