Configuring the WSM using Device Manager

How SSL session ID-based persistence works

All SSL sessions that present the same session ID (32 random bytes chosen by the SSL server) will be directed to the same real server.

Note: The SSL session ID can only be read by the WSM after the TCP three-way handshake. In order to make a forwarding decision, the WSM must terminate the TCP connection to examine the request.
New sessions are sent to the real server based on the metric selected (hash, roundrobin, leastconns, minmisses, response, and bandwidth).
If no session ID is presented by the client, the WSM picks a real server based on the metric for the real server group and waits until a connection is established with the real server and a session ID is received.
The session ID is stored in a session hash table. Subsequent connections with the same session ID are sent to the same real server. This binding is preserved even if the server changes the session ID mid-stream. A change of session ID in the SSL protocol will cause a full three-way handshake to occur.
Session IDs are kept on the WSM until an idle time equal to the configured server time-out (a default of 10 minutes) for the selected real server has expired.