Forum Discussion
Kevin_Stewart
Nov 19, 2012Employee
Per the guide:
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 clients IP address changes, Local Traffic Manager still recognizes the session as being persistent based on the session ID.
The SSL session ID is accessible both when and when not terminating the SSL on the BIG-IP, and is a valid persistence method in some instances. The guide goes on to say,
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 clients IP address. As long as the clients simple persistence record has not timed out, Local Traffic Manager can successfully return the client to the appropriate node.
Translation: browser clients or servers can (and likely will) re-negotiate the SSL session during the application session, at which time the SSL session ID will change. Every browser does it differently, but most modern browsers will usually go a few hours before re-negotiating. In any case, re-negotiation is inevitable the longer the session is open, so it's a good idea to have a secondary persistence mechanism in place (ie. Source Address).
To see the persistence records for SSL (terminated or non-terminated SSL), you can look at the statistics in the browser or type the following from the shell:
tmsh show ltm persistence persist-records
Ultimately though, HTTP cookies are the most reliable browser-based persistence type, and have the added benefit of putting the burden of persistence tracking back on the client.