Without persistence, every new connection is load-balanced independently, so a client can land on a different pool member each time. For stateful applications, a shopping cart, a login session, a multi-step form, that means lost state. Persistence solves it by recording which member served a client and returning that client to the same member. BIG-IP provides several methods, and choosing well depends on understanding what each one keys on.
Cookie persistence
Cookie persistence ties a client to a member through an HTTP cookie. It has four modes. Insert adds the cookie to the response and reads it back later, so the mapping lives in the client and no server-side record is needed. Rewrite has the server emit a placeholder that BIG-IP overwrites. Passive has the server set the specially formatted cookie itself, which BIG-IP only reads. Hash load-balances on a hash of a server-set cookie. Because it works at the HTTP layer, cookie persistence needs an HTTP profile, which means the traffic must be HTTP or HTTPS that BIG-IP decrypts. The companion persistence cookie decoder shows what the encoded value inside such a cookie actually contains.
Source and destination address affinity
Source address affinity records the client source IP and sends later connections from that address to the same member. It works for any protocol, but its precision is set by a mask: the default 255.255.255.255 gives each address its own record, while a coarser mask groups a subnet together. Destination address affinity, also called sticky persistence, does the mirror image, keying on the destination address regardless of client, which is mainly useful for load balancing caching servers so the same destination always reaches the same cache.
SSL persistence
SSL persistence keys on the SSL session ID, which the client sends in cleartext during the TLS handshake. Because the session ID survives a change of client IP address, it suits clients behind translated or dynamic addresses, and it works on encrypted traffic that BIG-IP does not decrypt. Its big limitation is protocol version: the session ID mechanism exists only in TLS 1.2 and earlier, so SSL persistence cannot be relied on with TLS 1.3.
Universal and hash persistence
Universal persistence is the flexible option: an iRule expression extracts any value from the traffic, a JSESSIONID, a header, a payload field, and that value becomes the persistence key. Hash persistence is the same idea, except the key is a hash of the chosen value rather than the value itself, which spreads load more evenly at the cost of possible collisions. Both depend on an iRule to define what to key on, and both require BIG-IP to see the value, so encrypted traffic must be terminated first.
The protocol-specific methods
Two methods exist for particular protocols. MSRDP persistence tracks Microsoft Remote Desktop sessions so a reconnecting client returns to the same session host. SIP persistence keys on a SIP header, by default the Call-ID, so all messages in a call reach the same server. Each is meaningful only for its protocol.
Reading them in a config
The persistence-method explainer identifies each persistence profile in a configuration, names its method, and lists the fields that matter. The next step is deciding which method fits a given application, covered in choosing a persistence method, and understanding how a primary and a fallback work together, covered in fallback persistence and match-across.