
F5 Persistence Cookie Not Sticking: tmsh show ltm persistence When Users Bounce Nodes
- Aug 15
- 2 min read

Users hop between nodes and lose session. Persistence profile is cookie. Developers blame F5.
This is a live-ticket style lesson from Techclick Infosec. You will isolate the fault with CLI first, then prove the fix with one clean packet or log.
What you will be able to do
Name the first CLI command to run on F5 BIG-IP for this ticket
Separate the layer that is actually broken from the layer people blame
Apply one scoped fix instead of a global disable
Prove the ticket closed with a session, log, or counter
Quick answer
If the cookie is not on the response, or a second VIP strips it, persistence never starts. show ltm persistence persist-records.
Why this ticket shows up
Cookie persistence needs the BIG-IP to insert or learn a cookie and the client to send it back. HTTP redirects to another hostname drop it.
Symptoms operators actually see
Each request hits a random node
No persist records
App redirected to another FQDN
Cookie secure/httponly mismatch
CLI first — copy this block
Run these on the F5 BIG-IP device or console named in the ticket. Do not skip the first show command — it tells you which later command matters.
tmsh show ltm persistence persist-records
tmsh list ltm persistence cookie cookie-web
tmsh show ltm virtual VS-WEB
tmsh list ltm profile http http-web
tcpdump -nni 0.0 -s0 -w /var/tmp/persist.pcap host 10.2.2.8How to read that output
Zero persist records means the cookie never came back. A redirect off the VIP hostname is the usual reason.
Triage order
Check persist-records during a test login
Inspect Set-Cookie on the first response
Confirm the next request sends that cookie to the same VIP
Fix redirect hostname or cookie domain
Only then look at source-hash as a fallback
Classic traps
What you see | Real cause | Fix |
Switch to source persistence | Users behind CGNAT | You will create a mega-node |
Disable SNAT | Cookie is the issue | Wrong lever |
Blame the app session store | Cookie never stuck | Prove persist-records |
Proof the ticket is closed
persist-records show the user
Repeat requests stay on one node
Login stays alive
Say this in an interview
No persist-records means the client never returned the cookie. I fix that before I change algorithms.
Need the full vendor lab, mock interview, and production runbooks? Techclick trains Palo Alto, Zscaler, F5, FortiGate, Check Point, Cisco ISE, Azure and routing with live CLI — start at https://www.techclick.in/



Comments