Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
Persistence is enabled, but my users still end up on different servers; why?
Short answer
The cause is one of the following: the selected Persistence method is not applied (a self-persistent algorithm is selected, or there is a single server in the list where SAM is used), the client does not send the cookie back (API client, Secure cookie accessed over HTTP, SameSite restriction), the durations expire, the pinned server falls into the Error status in the health check or is put into Maintenance Mode, the service is restarted and the Hash or SAM table is emptied, or the request goes to a different Conditional Backend Services set or to the other device in the cluster. The cause is found with the cookies in the browser and the Backend Service column on the vService's HTTP Logs screen.
Possible Causes
| Cause | Description | What is done |
|---|---|---|
| Self-persistent algorithm | If Source, URI, URL Param or HDR (RDP Cookie on L7 TCP) is selected, the Persistence field is hidden and the method there is not applied; distribution is done according to the algorithm's hash (e.g. with Source, if the client's IP changes, the server also changes) | The algorithm and the Persistence setting are reviewed together |
| Single server in the list with SAM | SAM is not applied to a list if there are fewer than two servers in the Default Backend Services list or in the conditional set | A second Backend Service is added to the list |
| First two requests (SAM, TR7 Generates) | The first request arrives without a cookie and is distributed by the algorithm; the mapping is established on the request in which the cookie comes back | This is the expected behavior |
| Cookie does not come back | API clients and some mobile apps do not store cookies | Header-based Hash or the HDR algorithm is used |
| Secure flag + HTTP | While Secure (HTTPS only) is on in the SAM Security Flags (default), if the site is opened over HTTP, the browser does not send the cookie | The site is accessed over HTTPS or the flag is reviewed |
| SameSite = Strict | The cookie is not sent in navigations coming from another site; a new session starts | The SameSite value is selected according to the application |
| Durations expired | New cookie: Cookie max-idle / max-life · SAM: Max idle / Max life · Hash: Hash Key Expire Time | The durations are set according to the application's session duration |
| Server down or in maintenance | If the pinned server becomes Error in the health check or is put into Maintenance mode, the requests go to another server | The server's health history is examined from the Health Checks tab in the Backend Service preview |
| Service reloaded | Reload in the vService menu empties the SAM and Hash tables; the Hash table is also rebuilt on an ordinary save | See Does saving a configuration change reset the persistence tables? |
| Cluster | The SAM and Hash tables are separate on each device; if the request goes to the other device (e.g. when the VIP moves to the peer device), the record is not found. New cookie and Current cookie are not affected by this | It is checked whether the traffic is handled on a single device |
| Conditional Backend Services | Each conditional set has its own servers and its own table; if the request changes set, it goes to a different server | The conditions and the sets are reviewed |
| Current cookie setting | If the cookie name is not exactly the same as the application's, or if the application does not set the cookie, pinning is not established | The cookie name is checked in the browser |
| Cookie name or server address changed | Old cookies do not match | A temporary wait is expected after the change |
Diagnosis Steps
- Browser developer tools: It is checked whether the persistence cookie (
TR-C,TR7SIDor the application's cookie) is set in the response and whether it is sent in subsequent requests; the Secure and SameSite flags are examined. - HTTP Logs: It is found to which servers the same user's requests went in the Backend Service column and when the switch happened.
- Health status: It is checked whether the server was in Error or in maintenance at the moment of the switch.
- SAM tab: If SAM is used, the session counts are examined on the vService's Session Affinity Manager (SAM) tab; if there are fewer than two servers in the list, the tab shows this with a warning.
Common Misconceptions
- "Persistence keeps the user on the same server even if the server goes down." Requests are not sent to an unavailable server.
- "SAM pins from the first request on." The mapping is established on the request in which the cookie comes back.
- "Reload preserves the tables." Reload in the vService menu empties the SAM and Hash tables.
- "The tables are shared in the cluster." Each device keeps its own table.
How it is done in the documentation
