Applies To:

Show Versions Show Versions

Manual Chapter: Configuration Guide for BIG-IP Local Traffic Management: 7 - Enabling Session Persistence
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


7

Enabling Session Persistence


Introducing session persistence

Using the BIG-IP® local traffic management system, you can configure session persistence. When you configure session persistence, the BIG-IP system 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.

The BIG-IP system 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.

The BIG-IP system 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.

Configuring a persistence profile

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 the BIG-IP system 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.

For more information, see the following chapters of this guide:

Enabling session persistence through 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 the BIG-IP system terminates by performing decryption and re-encryption and by handling SSL certificate authentication. In this type of iRule, you can use an HTTP header insertion iRule command to insert an SSL session ID as a header into an HTTP request.

The remainder of this chapter focuses on enabling persistence using persistence profiles. For information on enabling persistence by writing an iRule, see the F5 Networks DevCentral web site http://devcentral.f5.com, and Chapter 15, Writing iRules .

Persistence types and their profiles

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. For specific procedures on configuring a profile, see Chapter 5, Understanding Profiles .

Types of persistence

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. SIP is a protocol that enables real-time messaging, voice, data, and video.
  • 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, the BIG-IP system 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 the BIG-IP system does not perform the tasks of SSL certificate authentication and encryption/re-encryption. To enable persistence for terminated SSL sessions, see Chapter 9, Managing SSL Traffic , Chapter 15, Writing iRules , and the F5 Networks DevCentral web site http://devcentral.f5.com.
  • 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 iRulesTM, defines some sequence of bytes to use as a session identifier.

Understanding criteria for session persistence

Regardless of the type of persistence you are implementing, you can specify the criteria that the BIG-IP system 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.

Specifying the Match Across Services setting

When you enable the Match Across Services profile setting, the BIG-IP system attempts to send all persistent connection requests received from the same client, within the persistence time limit, to the same pool member 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, the BIG-IP system 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. The BIG-IP system 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), the BIG-IP system 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).

Important

In order for the Match Across Services setting to be effective, virtual servers that use the same virtual address, as well as those that use TCP or SSL persistence, should include the same node addresses in the virtual server mappings.
Note

With respect to Cookie profiles, this setting applies to the Cookie Hash method only.

Specifying the Match Across Virtual Servers setting

You can set the BIG-IP system 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, the BIG-IP system attempts to send all persistent connection requests received from the same client, within the persistence time limit, to the same pool member. Connection requests from the client that do not use persistence are load balanced according to the currently selected load balancing method.

Note

With respect to Cookie profiles, this setting applies to the Cookie Hash method only.
Important

In order for the Match Across Virtual Servers setting to be effective, virtual servers that use pools with TCP or SSL persistence should include the same member addresses in the virtual server mappings.

Specifying the Match Across Pools setting

When you enable the Match Across Pools setting, the BIG-IP system can use any pool that contains a given persistence record. The default is disabled (cleared).

Note

With respect to Cookie profiles, this setting applies to the Cookie Hash method only.

Cookie persistence

You can set up the BIG-IP system 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 the cookie is handled by the BIG-IP system when it is returned to the client.

Understanding Cookie profile settings

To implement cookie persistence, you can either use the default cookie profile, or create a custom profile. Table 7.1 shows the settings and values that make up a Cookie profile.

Table 7.1 Settings of a Cookie persistence profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Persistence Type
Specifies the type of persistence. This setting is required.
Cookie
Cookie Method
Specifies the type of cookie processing that the BIG-IP system is to use. For more information, see Specifying the Cookie Method setting , following.
HTTP Cookie Insert
Cookie Name
Specifies the name of the cookie that the BIG-IP system should look for or insert.
This value is autogenerated based on the pool name.
Expiration
Sets the expiration time of the cookie. Applies to the HTTP Cookie Insert and HTTP Cookie Rewrite methods only. When using the default (checked), the system uses the expiration time specified in the session cookie.
Enabled (Checked)
Hash Offset
With respect to Cookie persistence, this setting applies to the Cookie Hash method only.
0
Hash Length
With respect to Cookie persistence, this setting applies to the Cookie Hash method only.
0
Timeout
With respect to Cookie persistence, this setting applies to the Cookie Hash method only.
0
Mirror Persistence
Specifies, when enabled (checked), that if the active unit goes into the standby mode, the system mirrors any persistence records to its peer. With respect to Cookie profiles, this setting applies to the Cookie Hash method only.
Disabled (Cleared)
Match Across Services
Specifies that all persistent connections from a client IP address that go to the same virtual IP address also go to the same node. With respect to Cookie profiles, this setting applies to the Cookie Hash method only. For more information, see Specifying the Match Across Services setting .
Disabled (Cleared)
Match Across Virtual Servers
Specifies that all persistent connections from the same client IP address go to the same node. With respect to Cookie profiles, this setting applies to the Cookie Hash method only. For more information, see Specifying the Match Across Virtual Servers setting .
Disabled (Cleared)
Match Across Pools
Specifies that the BIG-IP system can use any pool that contains this persistence entry. With respect to Cookie profiles, this setting applies to the Cookie Hash method only. For more information, see Specifying the Match Across Pools setting .
Disabled (Cleared)

 

Specifying the Cookie Method setting

You can configure the Cookie Method setting in a cookie profile to one of four values.

HTTP Cookie Insert method

If you specify HTTP Cookie Insert method within the 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. The cookie is named BIGipServer<pool_name>, and it includes the address and port of the server handling the connection. The expiration date for the cookie is set based on the timeout configured on the BIG-IP system. HTTP Cookie Insert is the default value for the Cookie Method setting.

Note that the profile settings Mirror Persistence, Match Across Services, Match Across Virtual Servers, and Match Across Pools do not apply to the HTTP Cookie Insert method. These settings apply to the Cookie Hash method only.

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.

Important

We recommend that you use this method instead of the HTTP Cookie Passive method whenever possible.

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 the BIG-IP system 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.)

Note

For backward compatibility, the blank cookie can contain only 75 zeros. However, cookies of this size do not allow you to use iRules and persistence together.

Note that the profile settings Mirror Persistence, Match Across Services, Match Across Virtual Servers, and Match Across Pools do not apply to the HTTP Cookie Rewrite method. These settings apply to the Cookie Hash method only.

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.

Important

We recommend that you use the HTTP Cookie Rewrite method instead of the HTTP Cookie Passive method whenever possible.

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 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=/"

Note that the profile settings Mirror Persistence, Match Across Services, Match Across Virtual Servers, and Match Across Pools do not apply to the HTTP Cookie Passive method. These settings apply to the Cookie Hash method only.

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, the BIG-IP system uses the cookie information to return the client to a given node. With this method, the web server must generate the cookie; the BIG-IP system does not create the cookie automatically as it does when you use the HTTP Cookie Insert method.

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.

Understanding Destination Address Affinity profile settings

To implement destination address affinity persistence, you either use the default dest_addr profile or create a custom profile. Table 7.2 shows the settings and their values that make up a Destination Address Affinity profile.

Table 7.2 Settings of a Destination Address Affinity persistence profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Persistence Type
Specifies the type of persistence profile. This setting is required.
Destination Address Affinity
Mirror Persistence
Specifies, when enabled (checked), that if the active unit goes into the standby mode, the system mirrors any persistence records to its peer.
Disabled (Cleared)
Match Across Services
Specifies that all persistent connections from a client IP address that go to the same virtual IP address also go to the same node.
Disabled (Cleared)
Match Across Virtual Servers
Specifies that all persistent connections from the same client IP address go to the same node.
Disabled (Cleared)
Match Across Pools
Specifies that the BIG-IP system can use any pool that contains this persistence entry.
Disabled (Cleared)
Mask
Specifies the mask that the BIG-IP system should use before matching with an existing persistence entry.
255.255.255.255
Timeout
Specifies the duration of the persistence entries. Possible values are:
Specify: Specifies the number of seconds before the persistence entry times out.
Indefinite: Specifies that the persistence entry does not time out.
180

 

Hash persistence

Hash persistence allows you to create a persistence hash based on an existing iRule. When using hash persistence, the value on which the BIG-IP system persists the session (such as a cookie string) is the hash of the data supplied. This is different from universal persistence, where the value used for persistence is the supplied data irself.

For example, if you write an iRule that specifies the strings data1 and data2, then typing the command b persist show all shows that the system uses the hash of strings data1 and data2 (2356372769 and 1996459178, respectively) as the persistence value. Figure 7.1 shows this example of the b persist show all command and its output.

Figure 7.1 Output showing use of hash values for persistence
# b persist show all
PERSISTENT CONNECTIONS --
Mode: hash Value: 2356372769
Virtual: 10.1.1.41:http Node: 10.10.10.190:http Age: 2sec
Mode: hash Value: 1996459178
Virtual: 10.1.1.41:http Node: 10.10.10.180:http Age: 2sec

 

Note that if you use hash persistence and the BIG-IP system 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.

To illustrate using the previous 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).

Understanding Hash profile settings

To implement hash persistence, you either use the default hash profile or create a custom profile. Table 7.3 shows the settings and their values that make up a Hash profile.

Table 7.3 Settings of a Hash persistence profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Persistence Type
Specifies the type of persistence profile. This setting is required.
Hash
Mirror Persistence
Specifies, when enabled (checked), that if the active unit goes into the standby mode, the system mirrors any persistence records to its peer.
Disabled (Cleared)
Match Across Services
Specifies that all persistent connections from a client IP address that go to the same virtual IP address also go to the same node.
Disabled (Cleared)
Match Across Virtual Servers
Specifies that all persistent connections from the same client IP address go to the same node.
Disabled (Cleared)
Match Across Pools
Specifies that the BIG-IP system can use any pool that contains this persistence entry.
Disabled (Cleared)
iRule
Specifies an iRule to run that determines the persistence entry.
None
Timeout
Specifies the duration of the persistence entries. Possible values are:
Specify: Specifies the number of seconds before the persistence entry times out.
Indefinite: Specifies that the persistence entry does not time out.
180

 

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.NET Server 2003, Enterprise Edition, or later, where all members belong to a Windows cluster and participate in a Windows session directory.

Benefits of MSRDP persistence

Without MSRDP persistence, Windows servers, when participating in a session directory, map clients to their appropriate servers, using redirection when necessary. If a client connects to the wrong server in the cluster, the targeted server checks its client-server mapping and performs a redirection to the correct server.

When MSRDP persistence is enabled, however, a Windows server participating in a session directory always redirects the connection to the same virtual server, instead of to another server directly. The BIG-IP system then sends the connection to the correct Windows server. Also, when MSRDP persistence is enabled on a BIG-IP system and the servers in the pool participate in a session directory, the BIG-IP system load balances an RDP connection according to the way that the user has configured the BIG-IP system for load balancing. Thus, the use of Windows servers and the Session Directory service, combined with the MSRDP persistence feature, provides more sophisticated load balancing and more reliable reconnection when servers become disconnected.

Server Platform issues

By default, the BIG-IP system with MSRDP persistence enabled load balances connections according to the way that the user has configured the BIG-IP system for load balancing, as long as Session Directory is configured on each server in the pool. Because Session Directory is a feature that is only available on Windows.NET Server 2003, Enterprise Edition, or later platforms, each server in the pool must therefore be a Windows.NET Server 2003, Enterprise Edition 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.NET Enterprise server or Windows XP system.

If, however, you want to enable MSRDP persistence but your server platforms are running older versions of Windows (on which Session Directory is not available), you can enable MSRDP persistence in non-default mode. This causes the BIG-IP system 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 Directory available on the servers) is less preferable than the default mode, because it provides limited load-balancing and redirection capabilities.

Configuring MSRDP persistence with Session Directory

To enable MSRDP persistence in the default mode, you must configure Session Directory on each Windows server in your load balancing pool. In addition to configuring Session Directory, you must perform other Windows configuration tasks on those servers. However, before you configure your Windows servers, you must configure the BIG-IP system, by performing tasks such as creating a load-balancing pool and designating your Windows servers as members of that pool.

The following two sections describe BIG-IP configuration tasks that are required to enable MSRDP persistence in default mode for a Windows client-sever configuration using RDP.

Configuring MSRDP persistence without Session Directory

When a server has no Session Directory, 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.

Understanding MSRDP profile settings

To implement MSRDP persistence, you either use the default msrdp profile or create a custom profile. Table 7.4 shows the settings and their values that make up an MSRDP profile.

Table 7.4 Settings of an MSRDP persistence profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Persistence Type
Specifies the type of persistence profile. This setting is required.
Microsoft Remote Desktop
Mirror Persistence
Specifies, when enabled (checked), that if the active unit goes into the standby mode, the system mirrors any persistence records to its peer.
Disabled (Cleared)
Match Across Services
Specifies that all persistent connections from a client IP address that go to the same virtual IP address also go to the same node.
Disabled (Cleared)
Match Across Virtual Servers
Specifies that all persistent connections from the same client IP address go to the same node.
Disabled (Cleared)
Match Across Pools
Specifies that the BIG-IP system can use any pool that contains this persistence entry.
Disabled (Cleared)
Timeout
Specifies the duration of the persistence entries. Possible values are:
Specify: Specifies the number of seconds before the persistence entry times out.
Indefinite: Specifies that the persistence entry does not time out.
300
Has Session Directory
Specifies whether the server is running Session Directory.
Enabled (Checked)

 

SIP persistence

Session Initiation Protocol (SIP) is an application-layer protocol that manages sessions consisting of multiple participants, thus enabling real-time messaging, voice, data, and video. With SIP, applications can communicate with one another by exchanging messages through TCP or UDP. Examples of such applications are internet conferencing and telephony, or multimedia distribution.

SIP persistence is a new type of persistence available for server pools. You can configure SIP persistence for proxy servers that receive Session Initiation Protocol (SIP) messages sent through UDP.

Understanding SIP profile settings

To implement SIP persistence, you either use the default sip profile, or create a custom profile. Table 7.5 shows the settings that make up a SIP profile.

Table 7.5 Settings of a SIP persistence profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Persistence Type
Specifies the type of persistence profile. This setting is required.
SIP
Mirror Persistence
Specifies, when enabled (checked), that if the active unit goes into the standby mode, the system mirrors any persistence records to its peer.
Disabled (Cleared)
Match Across Services
Specifies that all persistent connections from a client IP address that go to the same virtual IP address also go to the same node.
Disabled (Cleared)
Match Across Virtual Servers
Specifies that all persistent connections from the same client IP address go to the same node.
Disabled (Cleared)
Match Across Pools
Specifies that the BIG-IP system can use any pool that contains this persistence entry.
Disabled (Cleared)
Timeout
Specifies the duration of the persistence entries. Possible values are:
Specify: Specifies the number of seconds before the persistence entry times out.
Indefinite: Specifies that the persistence entry does not time out.
180

 

Note

The BIG-IP system currently supports persistence for SIP messages sent through UDP only.

The timeout value that you specify allows the BIG-IP system to free up resources associated with old SIP persistence entries, without having to test each inbound packet for one of the different types of SIP final messages. A default timeout value exists, which is 180 seconds. If you change the timeout value, we recommend that the value be no lower than the default.

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, the BIG-IP system 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 may want the BIG-IP system 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, the BIG-IP system 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.

Understanding Source Address Affinity persistence profile settings

To implement source address affinity persistence, you can either use the default source_addr profile or create a custom profile. Table 7.6 shows the settings and values that make up a Source Address Affinity profile.

Table 7.6 Settings of a Source Address Affinity persistence profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Persistence Type
Specifies the type of persistence profile. This setting is required.
Source Address Affinity
Mirror Persistence
Specifies, when enabled (checked), that if the active unit goes into the standby mode, the system mirrors any persistence records to its peer.
Disabled (Cleared)
Match Across Services
Specifies that all persistent connections from a client IP address that go to the same virtual IP address also go to the same node.
Disabled (Cleared)
Match Across Virtual Servers
Specifies that all persistent connections from the same client IP address go to the same node.
Disabled (Cleared)
Match Across Pools
Specifies that the BIG-IP system can use any pool that contains this persistence entry.
Disabled (Cleared)
Timeout
Specifies the duration of the persistence entries. Possible values are:
Specify: Specifies the number of seconds before the persistence entry times out.
Indefinite: Specifies that the persistence entry does not time out.
180
Mask
Specifies the mask that the BIG-IP system should use before matching with an existing persistence entry.
None
Map Proxies
Enables or disables proxy mapping.
Enabled (Checked)

 

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, the BIG-IP system 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 the BIG-IP system 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, the BIG-IP system can successfully return the client to the appropriate node.

Note

The SSL persistence type is only valid for systems that are not performing SSL certificate-based authentication of client requests or server responses. If you are using Client SSL or Server SSL profiles to configure certificate-based authentication, do not configure an SSL persistence profile. Instead, create an iRule to perform SSL session persistence.

The SSL profile

To implement SSL persistence, you either use the default ssl profile or create a custom profile. Table 7.7 shows the settings and their values that make up an SSL profile.

Table 7.7 Settings of an SSL persistence profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Persistence Type
Specifies the type of persistence profile. This setting is required.
SSL
Mirror Persistence
Specifies, when enabled (checked), that if the active unit goes into the standby mode, the system mirrors any persistence records to its peer.
Disabled (Cleared)
Match Across Services
Specifies that all persistent connections from a client IP address that go to the same virtual IP address also go to the same node.
Disabled (Cleared)
Match Across Virtual Servers
Specifies that all persistent connections from the same client IP address go to the same node.
Disabled (Cleared)
Match Across Pools
Specifies that the BIG-IP system can use any pool that contains this persistence entry.
Disabled (Cleared)
Timeout
Specifies the number of seconds before a persistence entry times out. That is, this setting sets the SSL session ID timeout value, which determines how long the BIG-IP system stores a given SSL session ID before removing the ID from the system.
300

 

Universal persistence

Included in the BIG-IP system's 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 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.

Once you have created an iRule and specified the iRule name within a universal profile, you must assign both the iRule and the profile to the appropriate virtual server as resources.

For more information on iRules, see the F5 Networks DevCentral web site http://devcentral.f5.com, and Chapter 15, Writing iRules .

For information on the difference between universal persistence and hash persistence, see Hash persistence .

The universal persistence profile

To implement universal persistence, you can either use the default universal profile or create a custom profile. Table 7.8 shows the settings and values that make up a universal profile.

Table 7.8 Settings of a universal persistence profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Persistence Type
Specifies the type of persistence. This setting is required.
Universal
Mirror Persistence
Specifies, when enabled (checked), that if the active unit goes into the standby mode, the system mirrors any persistence records to its peer.
Disabled (Cleared)
Match Across Services
Specifies that all persistent connections from a client IP address that go to the same virtual IP address also go to the same node.
Disabled (Cleared)
Match Across Virtual Servers
Specifies that all persistent connections from the same client IP address go to the same node.
Disabled (Cleared)
Match Across Pools
Specifies that the BIG-IP system can use any pool that contains this persistence entry.
Disabled (Cleared)
iRule
Specifies the name of an existing iRule that the BIG-IP system should run to determine a persistence entry.
None
Timeout
Specifies the duration of the persistence entries. Possible values are:
Specify: Specifies the number of seconds before the persistence entry times out.
Indefinite: Specifies that the persistence entry does not time out.
180

 




Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)