F5 BIG-IP LTM Load balancer Cookie Persistence

Cookie Persistence

Source address persistence worked properly for external clients. But to add internal clients later and if he was a /24 mask on a persistence profile this will cause dumping all internal clients come from 5 different /24 networks so they will match the same persistence records and therefore be mapped to the same pool members. Using source address persistence in this situation will result in uneven loads of traffic across the 10 different pool members.

Cookie Persistence might help in handling internal clients since their application is http or web based.

Cookie Persistence modes

There are three cookie Persistence modes

1. Insert mode
2. Rewrite mode
3. Passive mode

The name of the cookie persistence mode describes how the BIG-IP processes the http cookie in the response to the client.

1. Insert mode: - BIG-IP inserts a cookie in the servers response prior to sending to it to the client.
2. Rewrite mode: - The pool member inserts a blank cookie and BIG-IP rewrite the cookie with the appropriate BIG-IP information like the pool member.
3. Passive mode: - The pool member inserts the cookie in the correct format and BIG-IP doesn’t change it. Because it is in the correct format. BIG-IP can read the cookie upon the next client connection. All three modes discussed here result in the same cookie being stored on the client. The issue is who creates the cookie? BIG-IP alone (insert) and BIG-IP (rewrite) or the server alone (Passive)

The limitations for all cookies persistence modes are two fold.

1. Cookie persistence only covers the http protocol
2. If users disable the cookies, or the user’s PC date is off then the cookie might not be sent by the client browser to BIG-IP for examination.

State – diagrams shows each step in the communication between the client, BIG-IP and the pool member

Three cookie persistence modes

 Insert mode: -

   BIG-IP LTM inserts special cookies in http response

• Pool name
• Pool member

Rewrite mode: -

• Web server creates a blank cookie
• BIG-IP LTM rewrites to make special cookie

      Passive mode: -

• Web server creates special cookie and
• BIG-IP LTM passively lit it through

Cookie insert mode

Regardless of the cookie method chosen, BIG-IP must establish a TCP connection with the client and examine the request before processing the cookie or selecting a pool member.

For cookie insert mode, the first time the client connects to the virtual server the clients web browsers does not yet have a cookie.

BIG-IP detects that no cookie is present and load balances the client to next appropriate pool member. The member issues its HTTP reply to the client with no BIG-IP cookie.

BIG-IP then inserts a cookie with date time stamp and specific number information.

This time, when a second client connection is sent if its within the time out the web browser inserts a cookie into the HTTP request. BIG-IP reads the cookie and then persists. If the time out had been reached then the client web browser will not insert the cookie into the request and BIG-IP will load balance the client request.

The member issue its HTTP reply to the client, again with no BIG-IP cookie attached.

And, BIG-IP inserts a new cookie with a new date-time stamp.

The advantage of insert mode cookie persistence is that the application remains untouched. A disadvantage is the increased workload for BIG-IP.

Cookie Rewrite Mode

With Rewrite mode cookie Persistence a client connects to the virtual server for the first time, and once again, the client web browser has yet to receive a cookie for this site.

BIG-IP detects that no cookie is present and load balances the client to next appropriate pool member issue its HTTP reply to the client, and includes a blank cookie.

BIG-IP rewrites the cookie with the same information as cookie insert mode.

When the second client request is sent the web browser inserts the cookie into its http request if its still within the timeout period. BIG-IP either load balances or persists the connection to the appropriate pool member based on whether the BIG-IP cookie is present or not.

The member issues the HTTP response, and again includes a blank cookie.

BIG-IP rewrites the cookie with BIG-IP information including the pool member.

The advantage of rewrite mode cookie persistence is to ensure the 4K cookie length boundary is not exceeded. In insert mode the BIG-IP added cookie could result in this error.

The disadvantage is you have to configure the content server to send an additional “blank” cookie.  

 Cookie Passive Mode

Finally, let’s loop at passive mode cookie persistence once again, the first time the client connects to the virtual server, the client web browser has no cookie for the side.

BIG-IP detects that no cookie is present and load balances the client to the next appropriate pool member. The member issues its http reply to the client, which includes a BIG-IP cookie with the appropriate information.

BIG-IP leaves the cookie untouched.

A second client request is sent, this time the web browser inserts the cookie into its HTTP request, if it’s within the time out period. BIG-IP either load balances or persists the connection to the appropriate pool. Member based on whether the BIG-IP cookie is present or not.

The member issues its HTTP reply to the client, which includes the BIG-IP cookie with a new date – time stamp and other BIG-IP information.

Again, BIG-IP leaves the cookie untouched.

The advantage of passive mode cookie persistence is reduced workload on BIG-IP.

The draw back is that each content to server needs to configured to generate a BIG-IP cookie.

Configuring Cookie Persistence

Some profiles are dependent on other profiles. The cookie persistence profile requires. That an HTTP profile also be configured on the virtual server.

BIG-IP’s abilities to examine and the process HTTP fields, like cookies, is enabled via an HTTP profile.

Without an HTTP profile, BIG-IP can’t read the HTTP content and therefore cookie persistence will not work.

To add an HTTP profile to a virtual server, from the virtual server screen, select the properties tab and select http from the HTTP profile drop down menu.

Next, select the Resources tab and select the name of your cookie persistence profile from the Default Persistence Profile drop down menu. Here we are using of the default cookie persistence profile named cookie.