I85PREP
⌘ K
F5 301B BIG-IP LTM study materials
F5 301B BIG-IP LTM study resources

F5 301B BIG-IP LTM: Persistence and session management

F5 301B BIG-IP LTM · Work through your exam, one topic at a time.

All guide sections

Persistence and session management

Domain 4 tests persistence: which method fits which protocol, how records are created and expired, and how persistence interacts with load balancing, SNAT and member failure. Expect scenario questions about a user landing on a different server mid-session.

Methods

  • Layer 4: Source Address (the netmask decides grouping), Destination Address, SSL session ID.
  • Layer 7: Cookie in four modes - Insert (BIG-IP writes BIGipServer<pool>), Rewrite (the server's own cookie is rewritten), Passive (an existing cookie is read), Hash (the cookie value is hashed).
  • Universal persistence uses an iRule-supplied key; Hash persistence hashes a URI or address field.
  • A persistence profile lives on the virtual server or in an iRule (persist). With no matching record, load balancing applies normally.

Scope, timeout and failover

  • An expired record sends the next request back through the load balancing method.
  • Match Across Pools / Services lets one record apply beyond the original pool or port.
  • Persistence records can be mirrored to a standby device for failover.
  • When the persisted member is down, BIG-IP selects a new member and rewrites the record.

Worked example

Users of an HTTPS application with Source Address persistence keep landing on one server, and application logs show every client with the same address. Reasoning: the virtual server uses Source Address Translation Auto Map, so every backend connection originates from the egress self IP; with the default netmask of 255.255.255.255, all clients hash to a single member. Fixes: switch to cookie persistence (the traffic is HTTP after termination), or keep source address persistence and enable X-Forwarded-For handling with the Map Proxies option on the persistence profile, which reads the header instead of the socket address.

Traps

  • Forgetting the default /32 netmask when upstream NAT makes many clients look identical.
  • Applying cookie insert to a non-HTTP virtual server.
  • Assuming persistence survives a member disable; new connections follow the method.
  • Expecting SSL session ID persistence to work when clients reconnect with a fresh TLS session.
  • Setting a very short persistence timeout and blaming load balancing for re-logins.