How does the NetScaler 12.0 56.20 load balancing virtual server handle persistence when the primary persistence type is set to SSLSESSION with SourceIP Backup Persistence?
There are seven potential scenarios to consider:
Scenario – 1: SSL session is not set (Session-ID is 0). SESSIONID and SOURCEIP persistence entries do not exist.

• This occurs when a client request is received for the first time.
• With no backup SRCIP entry available, the load balancing decision is made and a source IP entry is created in the persistence table.
• On the response path after parsing the server Hello, a SESSID entry is created.

 
Scenario – 2: SSL session is not set (Session-ID is 0). SOURCEIP entry exists.

• This occurs when the client sends a new request but doesn’t want to reuse the previous SSL session.
• Since there is a backup persistence entry, no load balancing takes place. The NetScaler uses the backup Source IP session entry to forward the request to backend servers.
• On the response path after parsing server Hello, a SESSID entry is created.

 
Scenario – 3: SSL session is re-used (Session-ID is valid). SESSID and SRCIP entries exists. Both entries point to the same server.

• This occurs when the client sends a new request and decides to reuse the already negotiated SSL session.
• No load balancing decision is made and the last activity on both persistence entries is updated.

 
Scenario – 4: SSL session is re-used. SRCIP entry exists and SESSID entry does not exist.

• This occurs when the client sends a request with a valid SSL session ID, but either the SESSID entry timed-out or an entry was never created for that session ID on NetScaler.

• Since there is a backup persistence entry, no load balancing decision is made. NetScaler uses the backup Source IP session entry to forward the request to backend servers.
• On the response path after parsing server Hello, a SESSID entry is created.

 
Scenario – 5: SSL session is re-used. SRCIP and SESSID entries do not exists.

• This occurs when the client sends a requests with a valid SSL session ID, but either both the session on entries on NetScaler are timed-out or an entry was never created for this client.
• A load balancing decision is made and a SRCIP entry is created.
• On the response path after parsing server Hello, a SESSID entry is created.

 
Scenario – 6: SSL session is re-used. SESSID exists and SRCIP does not exist.

• This occurs when the client sends a request with a valid SSL session ID, but the client’s source IP changed due to NATing.
• No load balancing decision is made and the SESSID entry is used to direct the request to the backend server.
• SRCIP entry is created and populated with same value/server as SESSID entry.

 
Scenario – 7: SSL session is re-used. SESSID and SRCIP entries exists, but both entries point to different servers.

• This occurs when the client sends a request with a valid SSL session ID, but the client’s source IP changed due to NATing. NetScaler already created a SRCIP entry for the new source IP, possibly due to having received another client’s request behind the same NAT.
• Since SESSID is present, no load balancing decision is made and the request is forwarded to the corresponding server.
• No changes are made on the SRCIP entry but the last activity on the entry is updated.
• The SESSID entry is allowed to gracefully time-out.

In all the scenarios, preference is given to SRCIP entry over SESSID entry to update the last activity. This in turn results in SRCIP entry expiring after the SESSID entry.
 

CTX230557  How to Configure Backup Persistence for SSL Session-ID.