Standard Options

Force L4

Select this check box to force the Virtual Service to run at Layer 4 and not at Layer 7. This is only required in some special circumstances. If in doubt, leave this option unchecked.

L7 Transparency

When using L7, a connection can be transparent. This means the connection arriving at the Real Server appears to come directly from the client. Alternatively, if the connection is not transparent – connections at the Real Server appear to come from the LoadMaster. We recommend keeping transparency disabled in most configurations.

Enabling transparency makes the Virtual Service transparent (no Network Address Translation (NAT)). However, if the client resides on the same subnet as the Virtual IP and Real Servers, then the Virtual Services will automatically NAT the source IP (enabling non-transparency).

If the Real Servers are local option is enabled, then the Real Servers are NATed (non-transparent), even if L7 Transparency is enabled. This only happens if the Real Server is the originator of the request to the Virtual Service (and not just answering requests from other clients). For further information on the Real Servers are local option, refer to the L7 Configuration section.

For further information on transparency in general, refer to the Transparency Feature Description.

Subnet Originating Requests

If Subnet Originating Requests is enabled, the source addresses for connections to the Real Servers is the interface address of the LoadMaster. If this option is disabled, the source address is the Virtual Service IP address. If transparency is enabled, the source address is the IP address of the client and the Subnet Originating Requests option is ignored.

If the Real Server is on a subnet, and the Subnet Originating Requests option is enabled, then the subnet address of the LoadMaster is used as the source IP address.

The Subnet Originating Requests feature was designed for 'local' Real Servers. It works fine for re-encrypt unless the Real Server is non-local and not on the Default Gateway interface. In this case, you can force the local address by setting it in the Alternate Source Addresses field. This works for both normal and re-encrypted Virtual Services.

This switch allows control of subnet originating requests on a per-Virtual Service basis. If the global switch (Subnet Originating Requests in System Configuration > Miscellaneous Options > Network Options in the main menu) is enabled then it is enabled for all Virtual Services.

For more information about the global option, refer to the Network Options section.

If the global option is not enabled, it can be controlled on a per-Virtual Service basis.

Extra Ports

You may specify a range of ports, sequential or otherwise, starting with the base port already configured for the Virtual Service. The port numbers are inputted to the field and separated with a space, and the maximum range is 510 ports.

You can enter the extra ports either as port ranges or single ports separated by spaces or comma in whatever order you wish, for example, entering the list 8000-8080, 9002, 80, 8050, 9000 will add the ports 80, 8000 to 8080, 9000 and 9002.

Server Initiating Protocols

By default, the LoadMaster will not initiate a connection with a Real Server until it has received some data from a client. This prohibits certain protocols from working as they need to communicate with the Real Server before transmitting data.

If the Virtual Service uses one of these protocols then select the protocol from the drop-down list to enable it to work correctly.

The protocols that can be selected are:

• SMTP
• SSH
• IMAP4
• MySQL
• POP3
• Other Server Initiating Protocols

Persistence Options

Persistence is setup on a per Virtual Service basis. This section allows you to select whether persistence is enabled for this service, to set the type of persistence and the persistence timeout value.

If persistence is enabled it means that a client connection to a particular Real Server using the LoadMaster is persistent, in other words - the same client will subsequently connect to the same Real Server. The timeout value determines for how long this particular connection is remembered.

Source IP Address

The source IP address (of the requesting client) is used as the key for persistency in this case.

Super HTTP

Super HTTP is the recommended method for achieving persistence for HTTP and HTTPS services with the LoadMaster. It creates a unique fingerprint of the client browser and uses that fingerprint to preserve connectivity to the correct Real Server. The fingerprint is based on the values of the User-Agent field, if the User-Agent value does not contain the MSRPC string.

If the User-Agent value contains the MSRPC string, then the value of the Authorization header is used to achieve persistence.

In the case that the Authorization header is not present, and the User Agent value contains the MSRPC string, the persist value will simply be blank with a length of zero.

Server Cookie

The LoadMaster checks the value of a specially set cookie in the HTTP header. Connections with the same cookie will go to the same Real Server.

Server Cookie or Source IP

If cookie persistence fails, it reverts to source IP-based persistence.

Active Cookie

With Active Cookie persistence, the cookies are generated by the LoadMaster, not the server. When a connection comes into a LoadMaster Virtual Service configured with Active Cookie, the LoadMaster looks for a specific cookie. If that cookie is not there, the LoadMaster inserts it into the HTTP stream with a Set-Cookie directive. Existing cookies are not affected. As with the Server Cookie persistence method, the value for the LoadMaster-generated cookie is unique to each user, allowing the LoadMaster to differentiate between users. A benefit of this method is that no cookies need to be managed or generated by the servers, relieving the burden of server configuration. To gain better dispersion per client connection you can enable the Add Port to Active Cookie feature in the L7 configuration. For further information on this option, refer to the L7 Configuration section.With Active Cookie persistence, the cookie is valid for the session or until the persistence time expires. For example, if using Active Cookie persistence with the persistence timeout set to 10 minutes and the client connects at 2pm, then disconnects and reconnects at 2.05pm – this would reset the persistence timeout value. If the client tries to connect to a Virtual Service after the persistence timeout has expired, they would present the old cookie. The LoadMaster will check its persistence table and see that it does not have a valid entry. The LoadMaster would then generate a new cookie for the client and would update its persistence table.

Active Cookie or Source IP

If active cookie persistence fails, it reverts to source-based persistence.

Hash All Cookies

The Hash All Cookies method creates a hash of the values of all cookies in the HTTP stream. Cookies with the same value are sent to the same server for each request. If the values change, then the connection is treated as a new connection and the client is allocated to a server according to the load balancing algorithm.

Hash All Cookies or Source IP

Hash All Cookies or Source IP is identical to Hash All Cookies, with the additional feature that it will fall back to Source IP persistence in the event no cookies are in the HTTP string.

Super HTTP and Source IP Address

This is the same as super HTTP but it also appends the source IP address to the string, thus improving the distribution of the resulting HASH.

URL Hash

With URL Hash persistence, the LoadMaster will send requests with the same URL to the same server.

HTTP Host Header

With HTTP Host Header persistence, the LoadMaster will send all requests that contain the same value in the HTTP Host: header to the same server.

Hash of HTTP Query Item

This method operates in exactly the same manner as Server Persistence, except that the named item being inspected is a Query Item in the Query String of the URL. All queries with the same Query Item value is sent to the same server.

Selected Header

With Selected Header persistence, the LoadMaster will send all requests that contain the same value in the specified header to the same server.

SSL Session ID

Each session over SSL has its own session ID which can be persisted on.

If a Virtual Service is an SSL service and not offloaded, the LoadMaster cannot meaningfully interact with any of the data in the stream at Layer 7. The reason is, the data is encrypted and the LoadMaster has no way of decrypting it.

If, in the above scenario, a persistence mode that is not based off source IP is required, this is the only other option. When an SSL session is started, it generates a session ID for the connection. This session ID can be used to cause the client to persist to the correct server.

There are some downsides to this however, as most modern browsers regenerate the session ID at very short intervals, basically overwriting it, even if there is a longer interval set on the persist timeout.

UDP Session Initiation Protocol (SIP)

This persistence mode is only available in a UDP Virtual Service when Force L4 is enabled. SIP uses request and response transactions, similar to HTTP. An initial INVITE request is sent, which contains a number of header fields. These header fields can be used for persistence.

Timeout

For each persistence method, there is a configurable timeout value that determines how long the persistence for each user is honored, selectable from one minute to seven days.

This timeout clock is started when the initial connection is established. The persistence timeout value is updated if the client reconnects within the timeout period. For example, if the persistence timeout is set to 1 hour and the client starts a connection at 2pm, if the client disconnects and then reconnects before 3pm they will still persist to the same Real Server. Also, the persistence record is updated to reflect this and the persistence countdown timer is reset back to 1 hour for this client.

If a client made connections to the Virtual Service repeatedly within the timeout period, the persistence would be honored indefinitely. For instance, given the following scenario:

• Persistence Timeout is set to 10 minutes
• A user makes several requests in the course of 20 minutes, but the time between connections is always less than 1 minute

The request should be sent to the correct Real Server, as long as it is available (that is, passing health checks).

If the active connection goes idle for 20 minutes, then the next connection is counted as a new session, and may be sent to a different server, depending on scheduling. If the connection is opened for more than 10 minutes and the client disconnects and reconnects, the persistence record would have expired, the LoadMaster will create a new persistence entry for that client and possibly send the client to a new Real Server. This is due to the fact that the persistence countdown starts once a connection is established, not at the closing of the connection.

If you are experiencing persistence issues, this may be due to the fact that the persistence timeout is not long enough. If this is not long enough, then the timeout value should be set for a higher amount. In general, matching this value to your server timeout value is recommended.

Header field name

When UDP Session Initiation Protocol is selected as the persistence mode is selected sin the LoadMaster, a text box called Header field name will appear. The header field that is to be used as the basis for the persistence information should be entered here.

Scheduling Methods

This section allows you to select the method by which the LoadMaster will select a Real Server, for this particular service. The scheduling methods are as follows:

• Round Robin:

Round Robin causes the LoadMaster to assign Real Servers to a session in order, for example the first session connects to Real Server 1, the second to Real Server 2 and so on. There is no bias in the way the Real Servers are assigned.

• Weighted Round Robin:

This method uses the weight property of the Real Servers to determine which Real Servers get preference. The higher the weight a Real Server has, the higher the proportion of connections it will receive.

• Least Connection:

With this method, the current Real Server with the fewest open connections is assigned to the session.

• Weighted Least Connection:

As with Least Connection, but with a bias relative to the weight.

• Resource Based (Adaptive):

Adaptive scheduling means that the load on the Real Servers is periodically monitored and that packets are distributed such that load is approximately equal for all machines.

If the Scheduling Method is set to resource based (adaptive), the adaptive parameters are displayed. By default, the global values configured in Rules & Checking > Check Parameters are used. This is indicated by Use Global and Using Global in the field values. However, you can change these values for each Virtual Service, if needed. For further details on the adaptive parameters, including a description of each of the fields, refer to the following section: Adaptive Parameters.

• Resource Based (SDN Adaptive):

A Virtual Service which is using an adaptive scheduling method (whether using SDN or not) can be viewed as a control system. The intent is to achieve an evenly distributed load over the Real Servers and the controller calculates an error value from this (that describes the deviation from the desired even distribution). It also calculates a set of control values (Real Server weights) that are fed back into the system in a way to decrease the error value.

• Fixed Weighting:
  • All new connections, and connections without a valid persistence entry are forwarded to the highest weighted available server. If multiple Real Servers share the same highest weight, connections are forwarded to the first highest-weighted, available Real Server.
  • Current connections are forwarded to their current server until that connection is terminated
  • Connections with a persistence entry are forwarded to their current server until that connection is terminated and the persistence entry expires. Drain time could also apply in this scenario. For further details on drain time, refer to the Drop at Drain Time End section of the following topic: L7 Configuration.

When fixed weighting is in use, the Real Server with the higher weight is indicated with a green star icon.

• Weighted Response Time:

Every 15 seconds the LoadMaster measures the time it takes for a response to arrive for a health check probe and uses this time to adjust the weights of the Real Servers accordingly, that is, a faster response time relative to the other Real Servers leads to a higher weight which in turn leads to more traffic sent to that server.

• Source IP Hash:

When using the source IP hash scheduling method with Layer 4 (L4) Virtual Services, LoadMaster uses a prepopulated hash table to determine how client traffic is distributed across Real Servers.

For L4 source IP hash scheduling:

• LoadMaster uses a fixed hash table containing 4096 destination slots.
• Each Real Server is assigned a number of slots based on its configured Server weight.
• The weights of all Real Servers associated with the Virtual Service are tallied together to determine how the 4096 slots are distributed.

This prepopulation directly affects how source IP addresses are mapped to Real Servers.

By default, each Real Server is assigned a weight of 1000.

When multiple Real Servers are configured using the default weight, the total combined weight may not evenly divide into 4096.

In such cases, LoadMaster allocates slots sequentially based on Server weight until all 4096 slots are assigned. Any remaining slots are assigned starting again from the first Real Server.

As a result, some Real Servers, particularly those added later, may receive significantly fewer connections or no connections at all.

Example 1: Four Real Servers, weight 1000 each

• rs1: 1000 slots
• rs2: 1000 slots
• rs3: 1000 slots
• rs4: 1000 slots
• rs1: remaining 96 slots

Example 2: Five Real Servers, weight 1000 each

• rs1: 1000 slots
• rs2: 1000 slots
• rs3: 1000 slots
• rs4: 1000 slots
• rs5: 96 slots

In the second example, the fifth Real Server receives a very small share of the hash table, which can lead to minimal or no traffic being forwarded to that Server.

When using source IP hash scheduling, ensure that the sum of all Real Server weights is a factor of 4096.

Users should adjust Real Server weights rather than relying on the default value of 1000 based on the number of configured Servers. This ensures an even distribution of hash slots and prevents traffic imbalance.

• URL Hash:

The URL Hash method works by creating a hash value based on the object referenced in the client request’s URL and the number of Real Servers or SubVSs in the Virtual Service. All requests for a particular URL are sent to the same Real Server/SubVS, unless a Real Server or SubVS is added or removed – in which case all hash values are re-calculated and subsequent traffic is redistributed accordingly. A write always succeeds regardless of any outage (unless everything is down). The URL hash method sends write requests to the next available SubVS when a SubVS is down. For example:

• A Virtual Service has three SubVSs. A write request is received for which there is an existing hash that says to send the write to SubVS 2.

• SubVS 2 is down. The request is sent to SubVS 3.

• If SubVS 3 is down, send to SubVS 1 (in a round-robin fashion).

• When SubVS 2 comes back online, go back to honoring the hash and send future requests to SubVS 2.

Both path style addressing (for example, https://s3.us-west-2.amazonaws.com/mybucket/puppy.jpg) and virtual host style addressing (for example, https://my-bucket.s3.us-west-2.amazonaws.com/puppy.png) are supported.

This scheduling method was developed primarily to support Dell EMC Elastic Cloud Storage (ECS) applications and efficient use of ECS-based resources, but could also be used to support other workloads where storage efficiency is the primary goal. For Dell ECS deployments, the load traffic is distributed across the Virtual Data Centers (VDCs) in the deployment, each of which are represented on LoadMaster as a SubVS. Within each VDC, the traffic is distributed across the Real Servers in the SubVS.

Idle Connection Timeout (Default 660)

The seconds before an idle connection is closed. Setting it to 0 ensures that the default L7 connection timeout is used. Configuring the Idle Connection Timeout in the Standard Options section of a Virtual Service sets the value for the Virtual Service. You can also modify the default Connection Timeout value by going to System Configuration > Miscellaneous Options > Network Options.

Use Address for Server NAT

By default, when the LoadMaster is being used to SNAT Real Servers, the source IP address used on the internet is that of the LoadMaster. The Use Address for Server NAT option allows the Real Servers configured on the Virtual Service to use the Virtual Service as the source IP address instead - if the Real Server makes an outbound request using the same port as the Virtual Service. The LoadMaster does not NAT all outbound ports.

If the Real Servers are configured on more than one Virtual Service that has this option set, the LoadMaster examines the destination port of the server's request and then selects the Virtual Service with a matching port. The LoadMaster then uses this Virtual Service as the source IP address. If no match is found for the port being requested, the IP address of the LoadMaster is used as the source IP address.

Quality of Service

The Quality of Service drop-down sets a Type of Service (ToS) in the IP header of packets that leave the Virtual Service. This means that the next device or service that deals with the packets will know how to treat and prioritise this traffic. Higher priority packets are sent from the LoadMaster before lower priority packets.

The different options are described below:

• Normal-Service: No special priority given to the traffic
• Minimize-Cost: Used when data needs to be transferred over a link that has a lower “cost”
• Maximize-Reliability: Used when data needs to travel to the destination over a reliable link and with little or no retransmission
• Maximize-Throughput: Used when the volume of data transferred during an interval is important, even if the latency over the link is high
• Minimize-Delay: Used when the time required (latency) for the packet to reach the destination must be low. This option has the quickest queue of each of the Quality of Service choices.
• Pass Through: In LoadMaster firmware version 7.2.52, the Pass Through value was introduced. When this is selected, connections that contain the Quality Of Service (QOS) flags are passed through to the Real Server. There are a couple of points to be aware of regarding SubVSs:

• If you select Pass Through as the Quality of Service on the parent Virtual Service, all SubVSs under the parent Virtual Service will use Pass Through. The SubVS will not display the Quality of Service field and you will not be able to change the Quality of Service value using the Application Programming Interface (API).

• If you select any other option apart from Pass Through as the Quality of Service on the parent Virtual Service, no SubVS under that Virtual Service will have the Pass Through option in the Quality of Service drop-down list and you will not be able to set the Quality of Service to Pass Through using the API.

The ToS values for each option are provided in the following table: