05 Persistence
Persistence — also called stickiness — keeps a client on the same pool member for the duration of its session. Without it, every new connection can land on a different server and break things like logins and shopping carts. Persistence is a profile assigned to the virtual server, and when it applies it overrides the load balancing method.
Why it matters
- Applications that keep session state in the server’s memory need the client to return to that same server.
- Reusing the same member also saves work (session data, caches, SSL sessions).
- Persistence changes the expected traffic path: a returning client goes to “its” member even if the LB method would pick another.
Persistence types
| Type | Based on | Notes |
|---|---|---|
| Source address affinity | Client IP (+ prefix length) | Simple; stores records on BIG-IP. Default timeout 180 s |
| Destination address affinity | Destination IP | Caches and outbound proxies |
| Cookie | HTTP cookie | Needs an HTTP profile (and Client SSL for HTTPS) |
| SSL | SSL session ID | Breaks when browsers renegotiate; rarely used today |
| Universal | Any value extracted by an iRule | Very flexible |
| Hash | Hash of a value (e.g. part of the URL) | With the CARP algorithm no records are stored |
| Microsoft RDP, SIP, Host | Protocol-specific |
180 seconds
180 s is the default timeout of source address persistence (time since the last packet), not a hard limit. If a client returns after the record expired (e.g. after lunch), it’s load balanced again.
Source address affinity
- Can match a network, not just one host: the Prefix Length / Mask groups clients (e.g.
/24→ the whole subnet goes to the same member). - Records can be viewed in Statistics → Persistence Records or with
tmsh show ltm persistence persist-records. - Weakness: many users behind the same NAT/proxy share one IP and all land on one server (“mega-proxy” problem).
Cookie persistence (a family of methods)
| Method | Who manages the cookie |
|---|---|
| HTTP Cookie Insert (default) | BIG-IP inserts its own cookie (BIGipServer<pool>), which encodes the member |
| HTTP Cookie Rewrite | The server sends a blank cookie and BIG-IP rewrites its value |
| HTTP Cookie Passive | The server creates the cookie; BIG-IP only reads it |
| Cookie Hash | BIG-IP hashes a value from a server cookie |
- No persistence records are stored on BIG-IP — the state lives in the client’s cookie.
- Works independent of the client IP (great behind NAT and proxies).
- If the browser rejects cookies, the request is simply load balanced.
- With HTTPS BIG-IP must decrypt to read or insert the cookie — no cookie persistence with SSL pass-through.
- Cookies expire (session cookie by default, or a fixed time).
Persistence options
| Option | Use |
|---|---|
| Fallback Persistence Profile | Used when the default method can’t apply (e.g. cookie rejected → source address) |
| Match Across Services | Same client → same server across different ports of the app (80 and 443) |
| Match Across Virtual Servers / Pools | Share persistence between several VSs or pools |
| Override Connection Limit | Persistent clients can still reach a member that hit its limit |
| Mirror Persistence | Copy records to the HA peer so they survive failover |
| Hash Algorithm: CARP | Compute the member from a hash instead of storing records |
CARP and HA performance
- CARP (Cache Array Routing Protocol) can be selected as the hash algorithm in persistence profiles such as source address.
- The member is calculated, not stored → no records table → much less data mirrored between HA peers.
- Trade-off: when members are added or removed, some clients are remapped to another member.
Multiple persistence profiles and iRules
- A virtual server can have more than one persistence profile (one marked as default), which iRules can choose between.
- An iRule can set persistence dynamically, e.g.
persist source_addronly for a specific host name. The matching persistence profile must exist on the VS.
Troubleshooting persistence
- Is the profile attached to the right VS (Resources → Default Persistence Profile)?
- Records present? Timeout too short?
- Cookie visible in the browser / in a capture?
- Use tcpdump on the server side to confirm the same client always reaches the same member.
- Failover without persistence mirroring, OneConnect without proper persistence, or a member going down can all “break” persistence.
Self-check
Q1 — Persistence is also known as what?
Respuesta
Stickiness.
Q2 — Does source address affinity only match a single client address?
Respuesta
No. With a prefix length/mask it can match a whole network.
Q3 — Which tmsh command shows the persistence records?
Respuesta
tmsh show ltm persistence persist-records
Q4 — With cookie persistence, are persistence records created on BIG-IP?
Respuesta
No. The state is kept in the client’s cookie.
Q5 — The client's browser doesn't accept cookies. What happens?
Respuesta
The connection is load balanced to a member normally.
Q6 — How is persistence configured on BIG-IP?
Respuesta
As a profile assigned to a virtual server.
Q7 — An HA pair using source address persistence mirrors too much data. What reduces it?
Respuesta
Enable CARP as the hash algorithm on the persistence profile.
Q8 — Can a virtual server have more than one persistence type?
Respuesta
Yes (one is marked as default).