top of page

F5 Persistence Cookie Not Sticking: tmsh show ltm persistence When Users Bounce Nodes

  • Aug 15
  • 2 min read
F5 BIG-IP network security troubleshooting lab
F5 BIG-IP · Techclick CLI troubleshooting lab
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.8

How 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

  1. Check persist-records during a test login

  2. Inspect Set-Cookie on the first response

  3. Confirm the next request sends that cookie to the same VIP

  4. Fix redirect hostname or cookie domain

  5. 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


bottom of page