1. Kemp Support
2. Knowledge Base
3. Content Delivery

Layer 7 persistence methods

Updated: July 14, 2023 20:25

For a description of what persistence is, refer to the following article: What is Persistence?

There are a number of Layer 7 persistence methods available to select in the Virtual Services modify screen. These methods look beyond the IP address and port and provide a range of options to achieve layer 7 persistence. The various methods are described in the sections below.

Server Cookie Persistence
The Server Cookie option is a Layer 7 feature that uses existing cookies generated from the server to determine which server to send users to. This method is sometimes referred to as “passive cookie”, as the LoadMaster does not generate or manage the cookie, it only observes the cookie in the HTTP stream.

With Server Cookie persistence, you will need to configure the Cookie Name option so the LoadMaster knows which cookie to refer to. For Server Cookie persistence to work best, the cookie generated by the server should have a unique value for each individual user.

Active Cookie Persistence
The Active Cookie method is a Layer 7 feature that uses cookies like the pervious method, but with Active Cookie 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.

Server Cookie or Source IP Persistence
The Server Cookie or Source IP setting is identical to the Server Cookie setting, but with the additional fall-back method of source IP address. If, for any reason, the expected cookies aren't present (this can happen when a client browser is configured to refuse cookies), then the source IP address will be used to determine persistence.

Active Cookie or Source IP Persistence
The Active Cookie or Source IP setting is identical to the Active Cookie Persistence. If, for any reason, the expected cookies are not present, then the source IP address will be used to determine persistence.

All things being equal, if you are going to use Layer 7 persistence, this is the recommended method. It requires no configuration on the servers, the LoadMaster manages all persistence-related cookies, and it falls back onto source IP address in cases where cookies are rejected by the client.

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

Hash All Cookies or Source IP Persistence
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 that no cookies are in the HTTP string.

Source IP Address Persistence
Source IP Address persistence uses the source IP address of the incoming request to differentiate between users. This is the simplest method of persistence, and works for all TCP protocols, including those that are not HTTP related.

Source IP Address persistence is the only persistence option that can be used in conjunction with Content Switching or Direct Server Return deployments.

There are situations where Source IP persistence may be undesirable or even ineffective in properly keeping persistence. These situations include:
• When many (or all) users appear to come from a single IP address
• When a user switches IP addresses

The first case is often encountered when a significant number of user requests traverse a single proxy, and thus appear to come from a single IP. With Source IP persistence, this would mean that all of those users would appear as a single user.

Another way this might occur is when all of the client requests come over the Internet from a single office. Office routers typically NAT all office systems to one IP address, so again, all users and all requests would appear to be a single user. This can result in uneven load balancing, since new user sessions arriving would all be directed to the same Real Server, without being balanced.

The second case is a largely historical concern, having to do with proxy servers at some of the mega-Internet Service Providers (ISPs), for example AOL and Earthlink. In some cases, proxy configuration or any number of networking issues, might switch IP addresses from time to time. When the IP address changes, the user appears as a different user to SRC persistence.

In each of these cases, Layer 7 persistence would solve the issue, regardless of what IP they came from. However, this only works for the HTTP protocol (and HTTPS/SSL when the session is terminated at the LoadMaster).

Super HTTP
Super HTTP is a method for achieving persistence for HTTP and HTTPS services with the LoadMaster. It functions by creating 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.

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 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 will be 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
SSL Session ID is a persistence method that may be used with SSL services even if they are not offloaded. This relies on the client maintaining the same SSL Session ID for a complete user session.
Browser support of this is spotty. As a result, this is not recommended for use with HTTPS services. In order to utilize this persistence method, the Service Type must be set to Generic.

UDP Session Initiation Protocol (SIP)
This persistence mode is only available in a UDP Virtual Service when Force L7 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. When this mode is selected in 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.

---

Comments

---

---

---

---