F5 LTM VE – Configuring Persistence

One of the main problems with load balancing is persistence.  Some web applications require that the external user return to the same web server each time, or at least each time within a given window of time.  That being said, there needs to be a mechanism in which we can determine if the external user has connected before, and if so, to what server he was balanced to.

Persistence is a configuration option of the virtual server.  There are two settings for persistence.  The first being the default persistence profile.  Default persistence is the main persistence mode used for the virtual server.  The second option, fallback persistence, is used when the first method of persistence fails.  For example, if the default persistence is set to ‘cookie’ but the client isn’t accepting cookies, you could fallback to source persistence.  There are 8 different persistence profiles, let’s walk through them one at a time with some examples along the way.

Source Address Persistence
This is a pretty common type of persistence.  The LTM tracks the source of the incoming packet and redirects any connections coming from that IP to the same pool member.  When this is configured on our test virtual server we see a return like this…

Destination address Persistence
Persistence based on the destination address is much like source address persistence.  Except that the F5 examines the destination of the packet rather than the source.   Now, you might ask yourself, when would this actually be useful?  Think of a setup where an LTM is load balancing a set of proxy servers that are doing caching.  Clients would be forced through the proxies to the external site (read destination) and the proxy would cache that site.  Going forward, it would make sense to balance clients going to the same destination to the same proxy since that particular proxy already has the website cached.

Cookie Persistence
Cookie persistence is another common load balancing type.  Cookie persistence requires that a HTTP profile be associated with the virtual server. We’ll talk more about profiles in another blog entry.  When using cookies the F5 will examine the incoming request and determine if the appropriate cookie is part of the request.  If it is, the F5 will balance the client to the same member based on the cookie.  There are 4 different methods of cookie persistence.  These can be set under the cookie persistence profile…

The default method is ‘Cookie Insert’.  In this mode the F5 writes a cookie called ‘BIGIPServer’ into the response from the web server as it passes through the F5 on its return path to the client.  This method require no additional configuration on the web servers.

In ‘Cookie Passive’ mode the web servers must control the insert and updates of the BIGIPServer cookie.  The F5 only looks at the Cookie to determine which server the request should go to.

In ‘Cookie Rewrite’ mode the web server must send a cookie formatted in a particular order to the F5.  The F5 will then rewrites the cookie to the BIGIPServer cookie, updates it with the member information, and sends it back to the client.

In the last mode ‘Cookie Hash’ the LTM examines the cookie inserted by the web server on a previous connection and makes a load balancing decsion based on the hash in the cookie.  While the LTM is still making the load balancing decision, its making it based off of the cookie set by the web server.  This effectively moves the brains of the load balancing decision to the web server(s) that calculate the hash to insert into the original cookie.

To see the cookie on the client, you’ll need to change the cookie persistence profile from ‘Session Cookie’ to an set expiration cookie.  Session cookies are only good for that particular session and are stored in memory so they are never written to disk.  The expiration date of the cookie is updated each time the client hits the F5 so its sort of a rolling expiration.  At any rate, set it for at least an hour, and then hit the VIP with your browser. I used a app called ‘IECookiesView’ to read the cookie…

 
Hard to see there, but the cookie is on the system at this point.

Hash Persistence
By now you should be seeing that things including the hash function on the F5 are the more advanced custom like features.  I’ve never used this but I imagine you could use an iRule to examine the hash and make decision based on that.

Microsoft Remote Desktop (msrdp)
Tracks sessions between the RDP server and client

SIP (sip_info)
Persistence based on servers that receive and process SIP traffic

SSL
Keeps track of the sessions using the SSL Session ID

Universal
Allows for persistence based on custom expressions that you can write yourself.

Well that covers all of the different types.  You can probably tell that I went into greater detail on some of the more common ones.  The last few I at least haven’t dealt much with, so I don’t have a ton of info on yet.  If and when I get more info, I’ll update the post.