A login works until a second request reaches a different application server. Or a reverse proxy sends requests for different users over one connection, and every request seems stuck to the same member. Before changing a persistence timeout, separate three questions: did the browser return the right cookie, did BIG-IP evaluate this request independently, and did the application retain its session?
This F5 BIG-IP LTM cookie persistence troubleshooting guide provides a reusable diagnostic matrix, an HTTP/1.1 test workflow and a change-acceptance checklist. The workflow is an original engineering proposal, not a report of a production incident or an executed BIG-IP lab.
The problem: affinity is not application session storage
BIG-IP persistence directs returning client traffic to a previously selected pool member; a persistence profile is assigned to a virtual server to enable the relevant behavior.[1] Treat that routing decision separately from the application's login cookie, session database and authorization logic. For this investigation, call the application's credential-bearing cookie the application cookie, and the cookie used to select a pool member the affinity cookie. Do not assume they are the same object.
F5 documents another important boundary: without OneConnect, subsequent requests on the same HTTP Keep-Alive connection can continue to the member chosen for that connection, even when later persistence information would suggest another member.[2] A browser making a fresh connection and an upstream proxy reusing an existing connection therefore need separate tests.
Scope: the transport examples below deliberately use HTTP/1.1. Do not apply the OneConnect change proposal to HTTP/2 full-proxy virtual servers: F5 documents that combination as incompatible.[4] Confirm your TMOS release, virtual-server type, client-side and server-side HTTP versions, SSL termination points, iRules and local traffic policies before interpreting a result. The general persistence reference cited here is a legacy 12.1 manual, not a recommendation to deploy that release.[1]
Draw the request path before changing profiles
For an anonymized example, assume two users reach a reverse proxy, then a BIG-IP virtual server, then application members A and B. The application team provides a restricted test endpoint that reports an opaque backend label and a correlation ID. It must not expose internal addresses, software versions or session tokens publicly.
Record these facts in the change ticket:
- Which component terminates each TLS connection, and whether BIG-IP actually sees HTTP.
- Whether the proxy reuses its connection to BIG-IP across requests belonging to different users.
- The exact virtual server, pool, persistence profile and fallback profile in use.
- The affinity cookie's name and intended scope, separately from the application cookie.
- Whether application session data is local to a member or held in a shared store.
- A rollback owner and the previous profile assignments, including any relevant policies or iRules.
Keep this an evidence exercise. Do not enable broad debug logging or export browser cookie stores merely to prove which member served a request.
Cookie persistence troubleshooting matrix
The first column is a symptom, not a diagnosis. The evidence and next-step columns are recommended tests rather than claims that every BIG-IP deployment behaves identically.
| Symptom | Evidence to collect | Next bounded test |
|---|---|---|
| No apparent affinity cookie | Response headers at the browser-facing endpoint; actual profile and method | Identify which component should create the cookie; compare before and after the proxy |
| Cookie arrives but is not returned | Browser storage/rejection details; next request's Cookie header | Compare hostname, path, HTTPS use and browser cookie policy without weakening security controls |
| Cookie returns but a fresh connection reaches another member | Correlated request and backend labels; pool health; persistence policy | Check that the same virtual server and pool handled both requests; inspect policy or iRule overrides |
| Fresh connections behave correctly, reused connections do not | Connection reuse evidence plus request-level cookies | Run the isolated Keep-Alive test below before proposing OneConnect |
| Same member, but login still fails | Application log correlation, application cookie, session-store health | Move investigation to the application/session path; affinity alone is not a success criterion |
| Failure appears only through an upstream proxy | Proxy-to-BIG-IP connection trace; cookie headers on both sides | Compare direct and proxied paths while preserving hostname and certificate validation |
| Apparent imbalance after a profile change | Request counts and latency per member, not just open sockets | Evaluate connection reuse and workload before changing the balancing algorithm |
| Failover breaks an in-progress transaction | Member health timeline and application session recovery | Separate member reselection from application-state recovery; agree expected user impact |
The reused-connection branch follows F5's documented Keep-Alive behavior.[2] The imbalance branch matters because OneConnect reuses idle server connections, and F5 explicitly warns that this can make traffic appear unevenly balanced.[4]
Step 1: collect configuration without changing it
These are unexecuted, read-only example commands for an authorized administrator. Replace the fictional object names and check local tmsh help for your release. Configuration output can contain private infrastructure details; keep it in the approved incident workspace.
tmsh list ltm virtual /Common/example_https all-properties
tmsh list ltm persistence cookie /Common/example_cookie all-properties
tmsh list ltm profile one-connect /Common/example_oneconnect all-properties
tmsh show ltm pool /Common/example_pool members
Only run the OneConnect-profile command if that named profile exists. Check inherited settings as well as the visible custom object. Build a short configuration inventory instead of attaching a complete device export to a public ticket.
Do not use the existence or absence of a generic persistence-table entry as your sole pass/fail condition. For this workflow, require request-level proof: the intended affinity cookie is returned, the selected backend is identifiable, and the application transaction succeeds.
Step 2: test fresh connections with a cookie jar
Use an approved non-destructive endpoint, not a checkout, password-reset or write API. These shell commands are templates, not executed test results. The reserved hostname must be replaced with your authorized test service. Do not add -k; use the correct trust store or an approved --cacert file when necessary.
umask 077
mkdir -p affinity-test
cd affinity-test
curl --http1.1 --silent --show-error --fail-with-body \
--cookie-jar jar.txt --dump-header first.headers \
--output first.body \
https://app.example.invalid/affinity-check
curl --http1.1 --silent --show-error --fail-with-body \
--cookie jar.txt --cookie-jar jar.txt \
--dump-header second.headers --output second.body \
https://app.example.invalid/affinity-check
Run the commands as separate processes, record their timestamps, and correlate the requests with the backend labels. Confirm the affinity cookie was actually saved and returned; headers and backend logs should explain the result, not just a successful HTTP status.
If the endpoint redirects, inspect the destination before adding redirect following. A login flow spanning different hosts deserves its own scope analysis. Use browser developer tools for the real browser case: a curl cookie-jar test is not a substitute for testing browser acceptance rules.
Treat the jar and header files as sensitive. Use a dedicated test identity, restrict access and remove the artifacts according to your incident retention policy. Never paste live authentication cookies into chat or public issue trackers.
Step 3: isolate the Keep-Alive decision boundary
F5 states that attaching an HTTP profile and a OneConnect profile allows the server-side connection to detach after a response, permitting request-level selection rather than keeping all requests bound to the initial selection.[2] OneConnect also manages reuse of idle server-side connections; it is not simply a persistence on/off switch.[4]
Use this proposed lab sequence to distinguish cookie handling from connection-level behavior:
- Prepare two authorized test sessions that are already associated with different backend labels. Confirm each behaves as intended on fresh connections.
- Use an isolated proxy or HTTP/1.1 harness capable of sequentially sending both sessions over one connection to the test virtual server. Keep their cookie jars separate; do not combine unrelated login tokens.
- Prove connection reuse from a filtered trace or proxy connection identifier. A pair of curl processes does not prove this condition.
- Record the first request's cookie and backend, then the second request's cookie and backend. Redact values in the shared report.
- Repeat on a cloned, approved test virtual server with the proposed profile change. Keep pool membership, request order and application state unchanged.
A result consistent with the no-OneConnect condition is that requests stay with the connection's initially selected member.[2] With the applicable HTTP/OneConnect configuration, request-level processing becomes possible, but acceptance still requires the expected backend and successful application behavior.[4]
Do not add OneConnect blindly. F5 advises against its use for encrypted pass-through traffic and warns about complex non-HTTP protocols; NTLM also needs specific consideration.[4] If these conditions apply, stop and review the design rather than copying an HTTP recipe.
Step 4: choose the smallest justified change
| Confirmed finding | Candidate action | Required guardrail |
|---|---|---|
| Browser does not return the affinity cookie | Correct the issuing component's cookie scope or the proxy behavior | Preserve security attributes; retest real login and logout |
| Wrong profile or policy is selected | Correct the intended virtual-server attachment or policy | Compare inherited configuration; preserve a rollback snapshot |
| Reused HTTP/1.1 connection explains the selection | Evaluate HTTP plus OneConnect on a test virtual server | Check protocol compatibility, authentication and source-address expectations |
| Backend choice is correct but session is absent | Repair application state sharing or session handling | Application owner validates recovery and logout behavior |
| Failure is health or reachability related | Resolve the pool or network problem first | Do not conceal it with longer affinity lifetime |
When evaluating OneConnect, its source mask controls connection-reuse eligibility, not the lifetime of an application login.[4] With SNAT or Automap, F5 applies that mask to the translated SNAT address; a host-length mask therefore does not automatically mean isolation by original browser address.[4] Have the security and application owners review server-side identity assumptions before changing this setting.
For adjacent investigations, use the existing SNAT and return-path troubleshooting guide or the pool-member health monitor matrix. Neither problem should be diagnosed solely from a missing or unexpected cookie.
Deployment acceptance checklist
Use this as a reusable change record. Fill in observed result, evidence reference, owner and pass/fail for each item; no test below is claimed to have run here.
- [ ] Fresh connection with no affinity cookie completes the approved application flow.
- [ ] Fresh connection returning an established affinity cookie reaches the expected healthy member.
- [ ] Reused HTTP/1.1 connection is proven and request-level behavior matches the design.
- [ ] Two test users remain isolated; no session information crosses identities.
- [ ] Browser login, refresh, idle return and logout meet application requirements.
- [ ] Proxied and direct test paths behave as documented, or their intentional difference is recorded.
- [ ] A controlled member failure meets the agreed session-recovery objective.
- [ ] Request latency, errors and per-member request counts remain within the agreed baseline envelope.
- [ ] Rollback restores the previous profile assignments and is followed by an application test.
Agree thresholds before the window. A backend label alone cannot demonstrate that a purchase, upload or authenticated API workflow survives the change.
Practical takeaways
Start with the cookie on the wire, then prove the connection boundary, then validate application state. Do not lengthen a timeout to compensate for an unexamined proxy path. Use OneConnect only when the protocol and authentication design support it, and compare request-level evidence rather than open connection counts.
Bookmark the troubleshooting matrix for your next incident, or browse Start Here and the Data Center networking hub for related design and verification guides.
Post a Comment