Applies To:
Show Versions
BIG-IP LTM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
Session Persistence Profiles
Introduction to session persistence profiles
Using BIG-IP® Local Traffic Manager™, you can configure session persistence. When you configure session persistence, Local Traffic Manager tracks and stores session data, such as the specific pool member that serviced a client request. The primary reason for tracking and storing session data is to ensure that client requests are directed to the same pool member throughout the life of a session or during subsequent sessions.
In addition, session persistence can track and store other types of information, such as user preferences or a user name and password.
Local Traffic Manager offers several types of session persistence, each one designed to accommodate a specific type of storage requirement for session data. The type of persistence that you implement depends on where and how you want to store client-specific information, such as items in a shopping cart or airline ticket reservations.
For example, you might store airline ticket reservation information in a back-end database that all servers can access, or on the specific server to which the client originally connected, or in a cookie on the client’s machine. When you enable persistence, returning clients can bypass load balancing and instead connect to the server to which they last connected in order to access their saved information.
Local Traffic Manager keeps session data for a period of time that you specify.
The primary tool for configuring session persistence is to configure a persistence profile and assign it to a virtual server. If you want to enable persistence for specific types of traffic only, as opposed to all traffic passing through the virtual server, you can write an iRule.
A persistence profile is a pre-configured object that automatically enables persistence when you assign the profile to a virtual server. By using a persistence profile, you avoid having to write a program to implement a type of persistence.
Each type of persistence that Local Traffic Manager offers includes a corresponding default persistence profile. These persistence profiles each contain settings and setting values that define the behavior of the BIG-IP system for that type of persistence. You can either use the default profile or create a custom profile based on the default.
Persistence profile types
You can configure persistence profile settings to set up session persistence on the BIG-IP® system. You can configure these settings when you create a profile or after profile creation by modifying the profile’s settings.
The persistence types that you can enable using a persistence profile are:
- Cookie persistence
- Cookie persistence uses an HTTP cookie stored on a client’s computer to allow the client to reconnect to the same server previously visited at a web site.
- Destination address affinity persistence
- Also known as sticky persistence, destination address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the destination IP address of a packet.
- Hash persistence
- Hash persistence allows you to create a persistence hash based on an existing iRule.
- Microsoft® Remote Desktop Protocol persistence
- Microsoft® Remote Desktop Protocol (MSRDP) persistence tracks sessions between clients and servers running the Microsoft® Remote Desktop Protocol (RDP) service.
- SIP persistence
- SIP persistence is a type of persistence used for servers that receive Session Initiation Protocol (SIP) messages sent through UDP, SCTP, or TCP.
- Source address affinity persistence
- Also known as simple persistence, source address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the source IP address of a packet.
- SSL persistence
- SSL persistence is a type of persistence that tracks non-terminated SSL sessions, using the SSL session ID. Even when the client’s IP address changes, Local Traffic Manager™ still recognizes the connection as being persistent based on the session ID. Note that the term non-terminated SSL sessions refers to sessions in which Local Traffic Manager does not perform the tasks of SSL certificate authentication and encryption/re-encryption.
- Universal persistence
- Universal persistence allows you to write an expression that defines what to persist on in a packet. The expression, written using the same expression syntax that you use in iRules®, defines some sequence of bytes to use as a session identifier.
Session persistence and iRules
Instead of configuring a persistence profile, which enables a persistence type for all sessions passing through the virtual server, you can write an iRule, which enables a persistence type for particular requests (for example, for HTTP traffic that includes a certain cookie version only).
You can also use an iRule to enable persistence for SSL-terminated requests, that is, requests that Local Traffic Manager™ terminates by performing decryption and re-encryption and by handling SSL certificate authentication. In iRules® of this type, you can use an HTTP header insertion iRule command to insert an SSL session ID as a header into an HTTP request.
The OneConnect profile and session persistence
When you configure session persistence, Local Traffic Manager™ tracks and stores session data, such as the pool member that serviced a client request. Configuring a persistence profile for a virtual server ensures that client requests are directed to the same pool member throughout the life of a session or during subsequent sessions.
The Request-URI header in an HTTP request stores certain session data. Occasionally, however, for Cookie and Universal persistence types specifically, Local Traffic Manager ignores the session data in this header, and sends requests to an unexpected node. For example, this issue can occur when clients send requests to a virtual server through an internet proxy device. You can prevent this problem by creating a OneConnect™ profile, and assigning both the OneConnect profile and the persistence profile to the virtual server.
HTTP parsing with and without a OneConnect profile
If the virtual server does not reference a OneConnect™ profile, Local Traffic Manager™ performs load balancing for each TCP connection. Once the TCP connection is load balanced, the system sends all requests that are part of the connection to the same pool member.
For example, if the virtual server does not reference a OneConnect profile, and Local Traffic Manager initially sends a client request to node A in pool A, the system inserts a cookie for node A. Then, within the same TCP connection, if Local Traffic Manager receives a subsequent request that contains a cookie for node B in pool B, the system ignores the cookie information and incorrectly sends the request to node S instead.
Using a OneConnect™ type of profile ensures that the BIG-IP system does not ignore session data. If the virtual server references a OneConnect profile, Local Traffic Manager™ can perform load balancing for each request within the TCP connection. That is, when an HTTP client sends multiple requests within a single connection, Local Traffic Manager is able to process each HTTP request individually. Local Traffic Manager sends the HTTP requests to different destination servers if necessary.
For example, if the virtual server references a OneConnect profile and the client request is initially sent to node A in pool A, Local Traffic Manager inserts a cookie for node A. Then, within the same TCP connection, if Local Traffic Manager receives a subsequent request that contains a cookie for node B in pool B, the system uses that cookie information and correctly sends the request to node B.
Criteria for session persistence
Regardless of the type of persistence you are implementing, you can specify the criteria that Local Traffic Manager™ uses to send all requests from a given client to the same pool member. These criteria are based on the virtual server or servers that are hosting the client connection. To specify these criteria, you use the Match Across Services, Match Across Virtual Servers, and Match Across Pools profile settings. Before configuring a persistence profile, it is helpful to understand these settings.
The Match Across Services setting
When you enable the Match Across Services profile setting, Local Traffic Manager™ attempts to send all persistent connection requests received from the same client, within the persistence time limit, to the same node only when the virtual server hosting the connection has the same virtual address as the virtual server hosting the initial persistent connection. Connection requests from the client that go to other virtual servers with different virtual addresses, or those connection requests that do not use persistence, are load balanced according to the load balancing method defined for the pool.
For example, suppose you configure virtual server mappings where the virtual server v1:http has persistence enabled and references the http_pool (containing the nodes n1:http and n2:http), and the virtual server v1:ssl has persistence enabled and references the pool ssl_pool (containing the nodes n1:ssl and n2:ssl).
Suppose the client makes an initial connection to v1:http, and the load balancing algorithm assigned to the pool http_pool chooses n1:http as the node. If the client subsequently connects to v1:ssl, Local Traffic Manager™ uses the persistence session established with the first connection to determine the pool member that should receive the connection request, rather than the load balancing method. Local Traffic Manager should then send the third connection request to n1:ssl, which uses the same node as the n1:http node that currently hosts the client's first connection with which it shares a persistent session.
If the same client then connects to a virtual server with a different virtual address (for example, v2:ssl), Local Traffic Manager starts tracking a new persistence session, using the load balancing method to determine which node should receive the connection request. The system starts a new persistence session because the requested virtual server uses a different virtual address (v2) than the virtual server hosting the first persistent connection request (v1).
The Match Across Virtual Servers setting
You can set Local Traffic Manager™ to maintain persistence for all sessions requested by the same client, regardless of which virtual server hosts each individual connection initiated by the client. When you enable the Match Across Virtual Servers setting, Local Traffic Manager attempts to send all persistent connection requests received from the same client, within the persistence time limit, to the same node. Connection requests from the client that do not use persistence are load balanced according to the currently selected load balancing method.
The Match Across Pools setting
When you enable the Match Across Pools setting, Local Traffic Manager™ can use any pool that contains a given persistence record. The default is disabled (cleared).
With respect to Cookie profiles, this setting applies to the Cookie Hash method only.
Cookie persistence
You can set up Local Traffic Manager™ to use HTTP cookie persistence. Cookie persistence uses an HTTP cookie stored on a client’s computer to allow the client to reconnect to the same pool member previously visited at a web site.
There are four methods of cookie persistence available:
- HTTP Cookie Insert method
- HTTP Cookie Rewrite method
- HTTP Cookie Passive method
- Cookie Hash method
The method you choose to use affects how Local Traffic Manager returns the cookie when returning the cookie to the client.
HTTP Cookie Insert method
If you specify the HTTP Cookie Insert method within the Cookie persistence profile, the information about the server to which the client connects is inserted in the header of the HTTP response from the server as a cookie. By default, the cookie is named BIGipServer<pool_name>, and it includes the encoded address and port of the server handling the connection. The expiration date for the cookie is set based on the Expiration setting in the Cookie persistence profile. HTTP Cookie Insert is the default value for the Cookie Method setting.
HTTP Cookie Rewrite method
If you specify HTTP Cookie Rewrite method, the BIG-IP system intercepts a Set-Cookie header, named BIGipCookie, sent from the server to the client, and overwrites the name and value of the cookie. The new cookie is named BIGipServer<pool_name> and it includes the address and port of the server handling the connection.
The HTTP Cookie Rewrite method requires you to set up the cookie created by the server. For the HTTP Cookie Rewrite method to succeed, there needs to be a blank cookie coming from the web server for Local Traffic Manager to rewrite. With Apache variants, the cookie can be added to every web page header by adding the following entry to the httpd.conf file: Header add Set-Cookie BIGipCookie=0000000000000000000000000...
(The cookie must contain a total of 120 zeros.)
HTTP Cookie Passive method
If you specify the HTTP Cookie Passive method, the BIG-IP® system does not insert or search for blank Set-Cookie headers in the response from the server. This method does not try to set up the cookie. With this method, the server provides the cookie, formatted with the correct server information and timeout.
For the HTTP Cookie Passive method to succeed, there needs to be a cookie coming from the web server with the appropriate server information in the cookie. Using the BIG-IP Configuration utility, you generate a template for the cookie string, with encoding automatically added, and then edit the template to create the actual cookie.
For example, the following string is a generated cookie template with the encoding automatically added, where [pool name] is the name of the pool that contains the server, 336260299 is the encoded server address, and 20480 is the encoded port:
Set-Cookie:BIGipServer[poolname]=336268299.20480.0000; expires=Sat, 01-Jan-2002 00:00:00 GMT; path=/
To create your cookie from this template, type the actual pool name and an expiration date and time. Alternatively, you can perform the encoding using the following equation for address (a.b.c.d): d*(256^3) + c*(256^2) + b*256 +a
The way to encode the port is to take the two bytes that store the port and reverse them. Thus, port 80 becomes 80 * 256 + 0 = 20480. Port 1433 (instead of 5 * 256 + 153) becomes 153 * 256 + 5 = 39173.
With Apache variants, the cookie can be added to every web page header by adding the following entry to the httpd.conf file: Header add Set-Cookie: "BIGipServer my_pool=184658624.20480.000; expires=Sat, 19-Aug-2002 19:35:45 GMT; path=/"
Cookie hash method
If you specify the Cookie Hash method, the hash method consistently maps a cookie value to a specific node. When the client returns to the site, Local Traffic Manager™ uses the cookie information to return the client to a given node. With this method, the web server must generate the cookie; Local Traffic Manager does not create the cookie automatically as it does when you use the HTTP Cookie Insert method.
IPv4 IP address encoding
For HTTP Cookie Insert and HTTP Cookie Rewrite methods only, the BIG-IP system encodes the server address and port specified in an HTTP cookie. To encode an IPv4 server address specified within an HTTP cookie, the BIG-IP system:
- Converts each octet value to the equivalent 1-byte hexadecimal value.
- Reverses the order of the hexadecimal bytes and concatenate to make one 4-byte hexadecimal value.
- Converts the resulting 4-byte hexadecimal value to its decimal equivalent.
For example, if the IP address of the destination server is 10.1.1.100, the BIG-IP system encodes the IP address as follows:
10.1.1.100 = 0x0A . 0x01 . 0x01 . 0x64 Reverse byte order, concatenated = 0x6401010A 0x6401010A = 1677787402
The address encoding algorithm is performed algebraically, as follows, for address a.b.c.d:
a + b*256 + c*(256^2) + d*(256^3)
For example, if the IP address of the destination server is 10.1.1.100, the encoded address is derived as follows:
a=10; b=1; c=1; d=100 10 + 1*256 + 1*(256^2) + 100*(256^3) = 1677787402
The result is that BIG-IP system combines the encoded values for the server and port and inserts them into the persistence cookie. For example, using the IP address and port 10.1.1.100:8080, the persistence value that the BIG-IP LTM system encodes in the cookie is as follows:
1677787402.36895.0000
Note that the field following the port encoding is reserved for future use and always contains four zeros as placeholders.
Port encoding
For HTTP Cookie Insert and HTTP Cookie Rewrite methods only, the BIG-IP system encodes the server address and port specified in an HTTP cookie. To encode a port specified within an HTTP cookie, the BIG-IP system:
- Converts the decimal port value to the equivalent 2-byte hexadecimal value.
- Reverses the order of the two hexadecimal bytes.
- Converts the resulting 2-byte hexadecimal value to its decimal equivalent.
For example, if the port of the destination server is 8080, the BIG-IP system encodes the port as follows:
8080 = 0x1F90 Reverse byte order = 0x901F 0x901F = 36895
If the port value is less than 256, the first byte in step 1 is 0x00. For example, if the port value is 80, the BIG-IP system encodes the port as follows:
80 = 0x0050 Reverse byte order = 0x5000 0x5000 = 20480
The result is that BIG-IP system combines the encoded values for the server and port and inserts them into the persistence cookie. For example, using the IP address and port 10.1.1.100:8080, the persistence value that the BIG-IP LTM system encodes in the cookie is as follows:
1677787402.36895.0000
Note that the field following the port encoding is reserved for future use and always contains four zeros as placeholders.
Destination address affinity persistence
You can optimize your server array with destination address affinity persistence. Destination address affinity persistence, also known as sticky persistence, directs requests for a certain destination IP address to the same server, regardless of which client made the request.
This type of persistence provides the most benefits when load balancing caching servers. A caching server intercepts web requests and returns a cached web page if it is available. In order to improve the efficiency of the cache on these servers, it is necessary to send similar requests to the same server repeatedly. You can use the destination address affinity persistence type to cache a given web page on one server instead of on every server in an array. This saves the other servers from having to duplicate the web page in their cache, wasting memory.
Hash persistence
Hash persistence allows you to create a persistence hash based on an existing iRule that uses the persist iRule command. Using hash persistence is the same as using universal persistence, except that with hash persistence, the resulting persistence key is a hash of the data, rather than the data itself.
An example of a iRule that implements hash persistence:
rule my_persist_irule { when HTTP_REQUEST { persist hash [HTTP::header myheader] } }
Note that if you use hash persistence and Local Traffic Manager™ cannot find an entry in the persistence table for a connection, and the system has not yet chosen a pool member due to fallback persistence, then the system uses the hash value, rather than the specified load balancing method, to select the pool member.
For example, if the persistence table contains no entry for the hash value 2356372769, and the number of active nodes in the pool remains the same, then a session with that hash value for persistence is always persisted to node 10.10.10.190 (assuming that the node is active).
Microsoft Remote Desktop Protocol persistence
MSRDP persistence provides an efficient way of load balancing traffic and maintaining persistent sessions between Windows® clients and servers that are running the Microsoft® Remote Desktop Protocol (RDP) service. The recommended scenario for enabling MSRDP persistence feature is to create a load balancing pool that consists of members running Windows Server 2003 or Windows Server 2008, where all members belong to a Windows cluster and participate in a Windows session directory.
Benefits of Microsoft Remote Desktop Protocol persistence
Normally, Windows servers running Microsoft Terminal Services can use a session broker (known as Terminal Services Session Directory in Windows Server 2003 and TS Session Broker in Windows Server 2008) to ensure that user sessions are assigned to specific servers. If a client initiates a connection request to the wrong terminal server, that server redirects the client to the appropriate server.
When you have a BIG-IP® system, however, the incorrect server needs to redirect the client to the BIG-IP system virtual server, rather than to an individual server in the load balancing pool. To ensure that this happens, you can configure an MSRDP profile. With an MSRDP profile, Local Traffic Manager™ uses a token that the session broker provides to maintain persistence records. If a user initiates a session for which no session broker token exists, Local Traffic Manager makes load balancing decisions according to whichever load balancing method is configured for the pool.
In summary, using Local Traffic Manager with an MSRDP persistence profile, in conjunction with a session broker, allows for higher scalability and a greater range and flexibility of load balancing options than when using a session broker alone.
Microsoft Remote Desktop Protocol persistence server platform issues
By default, Local Traffic Manager™ with MSRDP persistence enabled load balances connections according to the way that the user has configured Local Traffic Manager for load balancing, as long as the session broker is configured on each server in the pool. Terminal Services Session Directory and TS Session Broker are features that are only available on Windows Server 2003 or Windows Server 2008 respectively. Therefore, each server in the pool must be a Windows Server 2003 or Windows Server 2008 server, if you want to use MSRDP persistence in default mode. Also, each client system must be running the remote desktop client software that is included with any Windows Server 2003 or Windows Server 2008 system.
If, however, you want to enable MSRDP persistence but your server platforms are running older versions of Windows (on which Session Directory or TS Session Broker is not available), you can enable MSRDP persistence in non-default mode. This causes Local Traffic Manager to connect a client to the same Windows server by way of the user name that the client provides. Note that enabling MSRDP persistence in non-default mode (that is, with no session broker available on the servers) is less preferable than the default mode, because it provides limited load-balancing and redirection capabilities.
Configuring MSRDP persistence with a session broker
To enable MSRDP persistence in the default mode, you must configure a session broker on each Windows server in your load balancing pool. In addition to configuring a session broker, you must perform other Windows configuration tasks on those servers. However, before you configure your Windows servers, you must configure Local Traffic Manager, by performing tasks such as creating a load-balancing pool and designating your Windows servers as members of that pool.
Configuring MSRDP persistence without a session broker
When a server has no session broker, the server cannot share sessions with other servers, and therefore cannot perform any redirections when a connection to a server becomes disconnected. In lieu of session sharing, Windows clients provide data, in the form of a user name, to the BIG-IP® system to allow the BIG-IP system to consistently connect that client to the same server. Enabling MSRDP persistence to behave in this way is the non-default mode.
SIP persistence
Session Initiation Protocol is an application-layer protocol that manages sessions consisting of multiple participants, thus enabling real-time messaging, voice, data, and video. A session can be a simple two-way telephone call or Instant Message dialogue, or a complex, collaborative, multi-media conference call that includes voice, data, and video. With SIP, applications can communicate with one another by exchanging messages through the SCTP, TCP or UDP protocols.
SIP persistence is a type of persistence available for server pools. You can configure SIP persistence for proxy servers that receive SIP messages sent through the UDP profile. Local Traffic Manager™ currently supports persistence for SIP messages sent through the UDP, TCP, or SCTP protocols.
Source address affinity persistence
Source address affinity persistence, also known as simple persistence, tracks sessions based only on the source IP address. When a client requests a connection to a virtual server that supports source address affinity persistence, Local Traffic Manager™ checks to see if that client previously connected, and if so, returns the client to the same pool member.
You might want to use source address affinity persistence and SSL persistence together. In situations where an SSL session ID times out, or where a returning client does not provide a session ID, you might want Local Traffic Manager to direct the client to the original pool member based on the client’s IP address. As long as the client’s source address affinity persistence record has not timed out, Local Traffic Manager can successfully return the client to the appropriate pool member.
Persistence settings apply to all protocols. When the persistence timer is set to a value greater than 0, persistence is on. When the persistence timer is set to 0, persistence is off.
The persistence mask feature works only for virtual servers that implement source address affinity persistence. By adding a persistence mask, you identify a range of source IP addresses to manage together as a single source address affinity persistent connection when connecting to the pool.
SSL persistence
SSL persistence is a type of persistence that tracks SSL sessions using the SSL session ID, and it is a property of each individual pool. Using SSL persistence can be particularly important if your clients typically have translated IP addresses or dynamic IP addresses, such as those that Internet service providers typically assign. Even when the client’s IP address changes, Local Traffic Manager™ still recognizes the session as being persistent based on the session ID.
You might want to use SSL persistence and source address affinity persistence together. In situations where an SSL session ID times out, or where a returning client does not provide a session ID, you might want Local Traffic Manager to direct the client to the original node based on the client’s IP address. As long as the client’s simple persistence record has not timed out, Local Traffic Manager can successfully return the client to the appropriate node.
Universal persistence
Included in the Local Traffic Manager™ Universal Inspection Engine (UIE) is a set of functions that you can specify within BIG-IP® system iRules® to direct traffic in more granular ways. Using these iRule functions, you can write expressions that direct traffic based on content data, or direct traffic to a specific member of a pool.
Universal persistence takes this iRules feature one step further, by allowing you to use the iRule persist uie command to implement persistence for sessions based on content data, or based on connections to a specific member of a pool. Universal persistence does this by defining some sequence of bytes to use as a session identifier.
To use iRule expressions for persistence, a universal persistence profile includes a setting that specifies the name of the iRule containing the expression.
rule my_persist_irule { when HTTP_REQUEST { persist uie [HTTP::header myheader] } }
Unlike hash persistence, which uses a hash of the data as the persistence key, universal persistence uses the data itself as the persistence key.
