Applies To:

Show Versions Show Versions

Archived Manual Chapter: BIG-IP Administrator guide v3.0: Working with Advanced Persistence Options
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.



5

Working with Advanced Persistence Options



Introducing advanced persistence options

In addition to the simple persistence and SSL persistence options provided by the BIG/ip Controller, several advanced persistence options are available. These options include:

  • HTTP Cookie persistence
  • Destination Address Affinity (Sticky persistence)
  • Persist masking
  • Maintaining persistence across virtual servers with the same address
  • Maintaining persistence across all virtual servers

Note: This chapter describes advanced peristence options. For more information about SSL persistence and simple persistence, see the BIG/ip Controller Getting Started Guide, Configuring persistence for e-commerce and other dynamic content sites, page 3-36.

Using HTTP cookie persistence

You can set up the BIG/ip Controller to use HTTP cookie persistence. This method of 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. This method of persistence can be used only with unencrypted HTTP 1.0 or 1.1 communication. This means cookie persistence does not work with SSL traffic.

There are four types of cookie persistence available: Hash mode, Insert mode, Rewrite mode, and Passive mode. The mode you choose affects how the cookie is handled by the BIG/ip Controller when it is returned to the client.

Hash mode

If you specify Hash mode, the hash mode consistently maps a cookie value to a specific node. When the client returns to the site, the BIG/ip Controller uses the cookie information to return the client to a given node. With this mode, the web server must generate the cookie. The BIG/ip Controller does not create the cookie automatically like it does with Insert mode.

To configure the hash cookie persistence option from the command line

Use the following syntax to configure the hash cookie persistence option:

  bigpipe vip <vip:port> define <pool_or_nodes> special cookie hash 
<CookieName> <Offset> <Length>

The <CookieName>, <Offset>, and <Length> values are described in Table 5.1:

The cookie hash mode values

Hash mode values Description

<CookieName>

This is the name of an HTTP cookie being set by a Web site.

<Offset>

This is the number of bytes in the cookie to skip before calculating the hash value.

<Length>

This is the number of bytes to use when calculating the hash value.

To configure the cookie persistence hash option in the F5 Configuration utility

Before you follow this procedure, you must configure at least one virtual server.

  1. In the navigation pane, click Virtual Servers.
    The Virtual Servers screen opens.
  2. In the virtual server list, click the virtual server for which you want to set up hash mode persistence.
    The properties screen for the virtual server you clicked opens.
  3. In the Application Persistence box, click None. The Application Persistence screen opens.
  4. Click the HTTP Cookie Persistence button.
    Set the following values:

    · Method Click the list and select Hash.

    · Timeout The timeout value is not used with hash mode.

    · Cookie Name (Hash Method) Type in the name of an HTTP cookie being set by the Web site. This could be something like Apache or SSLSESSIONID. It depends on the type of web server your site is running.

    · Hash Values The Offset is the number of bytes in the cookie to skip before calculating the hash value. The Length is the number of bytes to use when calculating the hash value.

  5. Click the Apply button.

Insert mode

If you specify Insert mode, the information about the server to which the client connects is written in the header of the HTTP response from the server. This mode creates a cookie, named BIGipServer, and inserts it in the HTTP response from the server that contains the information about the chosen server. The expiration date for the cookie is set based on the time-out configured on the BIG/ip Controller.

Rewrite mode

If you specify Rewrite mode, the BIG/ip Controller intercepts a cookie, named BIGipCookie, sent from the server to the client and rewrites the name of the cookie to BIGipServer. When the BIG/ip Controller rewrites the cookie, the server information and time-out value are reset.

Rewrite mode requires you to set up the cookie created by the server. In order for Rewrite mode to work, there needs to be a blank cookie coming from the web server for BIG/ip to rewrite. With Apache variants, the cookie can be added to every web page header by adding an entry in the httpd.conf file:

  Header add Set-Cookie 
BIGipCookie=0000000000000000000000000000000000
00000000...

(The cookie should contain a total of 75 zeros.)

Passive mode

If you specify Passive mode, the BIG/ip Controller does not insert or search for existing cookies in the response from the server. It does not try to set up the cookie. In this mode, it is assumed that the server provides the cookie formatted with the correct node information and time-out.

In order for Passive mode to work, there needs to be a cookie coming from the web server with the appropriate node information in the cookie. With Apache variants, the cookie can be added to every web page header by adding an entry in the httpd.conf file:

  Header add Set-Cookie: 
BIGipServer=184658624.20480.000; expires=Sat,
19-Aug-2000 19:35:45 GMT; path=/

In this example, 184658624 is the encoded node address and 20480 is the encoded port.

The equation for an address (a.b.c.d) is:

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. So, port 80 becomes 80 * 256 + 0 = 20480. Port 1433 (instead of 5 * 256 + 153) becomes 153 * 256 + 5 = 39173.

To activate Insert, Rewrite, or Passive HTTP cookie persistence in the F5 Configuration utility

  1. In the navigation pane, click Virtual Servers.
    The Virtual Servers Properties screen opens.
  2. In the Application Persistence box, click None. The Application Persistence screen opens.
  3. Select HTTP Cookie Persistence.
  4. Select the mode you want to use: Hash, Insert, Rewrite, or Passive. Each mode handles the cookie in a different manner (see the explanations preceding).
  5. Select the time-out value in days, hours, minutes, and seconds. This value determines how long the cookie lives on the client computer before it expires.
  6. Click Apply.

To activate Insert, Rewrite, or Passive HTTP cookie persistence from the command line

To activate HTTP cookie persistence from the command line, use the following syntax:

  bigpipe vip <virt addr>:<service> define <node addr>:<service> 
[...<node addr>:<service>] special cookie <mode name> <timeout>

For the <mode name>, type Insert, Rewrite, Passive, or Hash. The <timeout> value applies only for Insert and Rewrite modes. The <timeout> value for the cookie is written using the following format:

  <days>d hh:mm:ss

Using destination address affinity (sticky persistence)

You can optimize your proxy server array with destination address affinity (also called sticky persistence). Address affinity directs requests for a certain destination to the same proxy server, regardless of which client the request comes from.

This enhancement provides the most benefits when load balancing caching proxy servers. A caching proxy 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 proxies, it is necessary to send similar requests to the same proxy server repeatedly. Destination address affinity can be used to cache a given web page on one proxy server instead of on every proxy server in an array. This saves the other proxies from having to duplicate the web page in their cache, wasting memory.

Warning: In order to prevent sticky entries from clumping on one server, use a static load balancing mode, such as Round Robin.

To activate destination address affinity in the F5 Configuration utility

You can only activate destination address affinity on wildcard virtual servers. For information on setting up a wildcard virtual server, see the BIG/ip Getting Started Guide, Defining wildcard virtual servers, on page 3-8. Follow these steps to configure destination address affinity:

  1. In the navigation pane, click Virtual Servers.
    The Virtual Servers screen opens.
  2. Click the wildcard virtual server you want to configure.
    The Virtual Server Properties screen opens.
  3. Click the Destination Address Affinity Enable box to enable destination address affinity.
  4. In Destination Address Affinity Mask box, type in the mask you want to apply to sticky persistence entries.
  5. Click the Apply button.

To activate sticky persistence from the command line

Use the following command to enable sticky persistence for the virtual server:

  bigpipe vip 0.0.0.0:<port> sticky enable

Use the following command to disable sticky persistence for the virtual server:

  bigpipe vip 0.0.0.0:<port> sticky disable

Use the following command to show whether the sticky persistence is enabled or disabled for the virtual server:

  bigpipe vip 0.0.0.0:<port> sticky show

Use the following command to list sticky persistence entries for the specified virtual server.

  bigpipe vip 0.0.0.0:<port> sticky dump

Use the following command to delete sticky entries for the specified virtual server:

  bigpipe vip 0.0.0.0:<port> sticky clear

Use the following command to define the sticky mask for the virtual server:

  bigpipe vip 0.0.0.0:<port> sticky mask <mask>

For example <mask> could be 255.255.255.0. To remove the sticky mask for the virtual server:

  bigpipe vip 0.0.0.0:<port> sticky mask none

To show the sticky mask for the virtual server:

  bigpipe vip 0.0.0.0:<port> sticky mask show

To clear all sticky connections on a BIG/ip Controller, issue the following bigpipe command:

  bigpipe vip sticky clear

Using persist mask on a virtual server

The persist mask feature works only on virtual servers that implement simple persistence. By adding a persist mask, you identify a range of client IP addresses to manage together as a single simple persistent connection when connecting to a virtual server.

Note: You cannot use persist masks on virtual servers that use rules.

Applying a persist mask

The complete syntax for the bigpipe vip persist mask command is:

  bigpipe vip <virt addr>:<port> persist mask <ip> | none | show

Use the following syntax to specify a range of IP addresses to be included in persistence of the specified virtual port. The command adds a persist mask to a port:

  bigpipe vip <virt addr>:<port> persist mask <ip>

For example, the following command would keep persistence information together for all clients within a C class network that connect to the virtual server 10.10.10.90:80:

  bigpipe vip 10.10.10.90:80 persist mask 255.255.255.0

You can turn off a persist mask on a virtual server by using the none option in place of the ip mask. To turn off the persist mask that you set in the preceding example, use the following command:

  bigpipe vip 10.10.10.90:80 persist mask none

To display all persist masks, use the show option:

  bigpipe vip 10.10.10.90:80 persist mask show

Maintaining persistence across virtual servers that use the same virtual addresses

The BIG/ip Controller platform provides a similar persistence mode that is less granular. The BIG/ip Controller can maintain persistence for all connections requested by the same client, as long as the virtual server hosting each request uses the same virtual address. When this mode is turned on, the BIG/ip Controller 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 currently selected load balancing mode.

Using the preceding example, if a BIG/ip Controller configuration includes the following virtual server mappings, where each virtual server uses persistence:

  bigpipe vip v1:http define n1:http n2:http
  bigpipe vip v1:ssl  define n1:ssl  n2:ssl

For example, a client makes an initial connection to v1:http and the BIG/ip Controller's load balancing mechanism chooses n1:http as the node. If the same client then connects to v1:ssl, the BIG/ip Controller starts tracking a new persistence session, and it uses the load balancing mode to determine which node should receive the connection request because the requested virtual server uses a different virtual address (v1) than the virtual server hosting the first persistent connection request (v1). However, if the client subsequently connects to v1:ssl, the BIG/ip Controller uses the persistence session established with the first connection to determine the node that should receive the connection request, rather than the load balancing mode. The BIG/ip Controller should send the third connection request to n1:ssl, which uses the same node address as the n1:http node that currently hosts the client's first connection with which it shares a persistent session.

Warning: In order for this mode 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.

The system control variable bigip.persist_on_any_port_same_vip turns this mode on and off. To activate the persistence mode, type:

  sysctl -w bigip.persist_on_any_port_same_vip=1

To deactivate the persistence mode, type:

  sysctl -w bigip.persist_on_any_port_same_vip=0

Maintaining persistence across all virtual servers

You can set the BIG/ip Controller to maintain persistence for all connections requested by the same client, regardless of which virtual server hosts each individual connection initiated by the client. When this mode is turned on, the BIG/ip Controller 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 mode.

For example, if a BIG/ip Controller configuration includes the following virtual server mappings, where each virtual server uses persistence:

  bigpipe vip v1:http define n1:http n2:http
  bigpipe vip v1:ssl define n1:ssl  n2:ssl
  bigpipe vip v2:http define n1:http n2:http
  bigpipe vip v2:ssl  define n1:ssl  n2:ssl

Say that a client makes an initial connection to v1:http and the BIG/ip Controller's load balancing mechanism chooses n1:http as the node. If the same client subsequently connects to v1:ssl, the BIG/ip Controller would send the client's request to n1:ssl, which uses the same node address as the n1:http node that currently hosts the client's initial connection.

Warning: In order for this mode to be effective, virtual servers that use TCP or SSL persistence should include the same node addresses in the virtual server mappings.

The system control variable bigip.persist_on_any_vip turns this mode on and off. To activate the persistence mode, type:

  sysctl -w bigip.persist_on_any_vip=1

To deactivate the persistence mode, type:

  sysctl -w bigip.persist_on_any_vip=0
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)