# Persistence-method explainer > Paste BIG-IP persistence profiles and virtual servers and get the method behind each, its failure modes, and the primary-to-fallback chain, all in your browser. - Tool: https://ronutz.com/en/tools/f5-persistence-method-explainer - Family: Networking --- ## What it does Paste BIG-IP persistence profiles and virtual servers as a tmsh snippet and the tool explains the persistence behind each: which method it is, what it keys on, how it behaves, the fields that matter, and the ways it fails in practice. For each virtual server it also lays out the persistence chain, the primary method and the fallback used when the primary produces no record. It parses the configuration in your browser and contacts no device. ## What persistence is, and why the method matters Persistence, also called session affinity, keeps a client pinned to the same pool member across multiple connections, which stateful applications need so that a session started on one server continues on that server. BIG-IP offers several methods, and the important thing is that each one keys on something different, so each one has its own failure mode. Choosing a method is really choosing what to key on and accepting how that key can break. ## The common methods and how they fail - **Source-address** persistence keys on the client's IP address. Its classic failure is many clients arriving from behind a single NAT or proxy: they share one address, so they all pin to one pool member and the load skews. It also breaks if a client's address changes mid-session. - **Cookie** persistence keys on an HTTP cookie the BIG-IP manages, in modes that insert, rewrite, or passively read it. It is precise, but it requires HTTP and a client that accepts cookies, so it does not apply to non-HTTP traffic. - **SSL** persistence keys on the TLS session ID. It fails when clients rotate or renegotiate session IDs, or when session IDs are short-lived, which is why it is so often paired with a fallback. - **Universal** persistence keys on a value an iRule extracts from the traffic, which lets you persist on almost anything (a token, a header, a field) at the cost of writing the rule. Settings such as match-across-services, match-across-virtuals, and match-across-pools widen the scope over which a persistence record applies, and the tool reads these where they are set. ## The primary and fallback chain A virtual server can name a primary persistence profile and a fallback one. When the primary method finds no existing record for a connection, BIG-IP uses the fallback to place it. A well-known pairing is SSL session-ID persistence with source-address as the fallback, so that a client whose session ID is not yet known is still pinned by IP. The tool shows this chain per virtual server so you can see what actually decides a member. For the bytes inside a persistence cookie specifically, the BIG-IP persistence cookie decoder is the companion tool; this one explains the method around it. ## Using it Paste persistence profiles, virtual servers, or both, and read the method, keying, fields, and failure modes for each, plus the primary-to-fallback chain per virtual server. The parse is deterministic and local. ## Standards and references - [F5 K26898044: Persistence methods available in BIG-IP](https://my.f5.com/manage/s/article/K26898044) - the supported persistence methods and what each keys on - [F5 LTM Profiles Reference: Session Persistence Profiles](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-profiles-reference-13-0-0/4.html) - match-across settings, cookie modes, and universal persistence - [F5 SSL Administration: SSL Persistence](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-11-5-0/5.html) - SSL session-ID persistence and pairing it with source-address fallback ## Related reading - [BIG-IP Persistence Methods, and What Each Keys On](https://ronutz.com/en/learn/ltm-persistence-methods.md): BIG-IP offers several persistence methods, and the only thing they have in common is the goal: send a returning client to the same pool member. What they key on, cookie, source address, SSL session ID, or an iRule-extracted value, decides where each one fits and where each one breaks. - [Choosing a Persistence Method (and Its Failure Modes)](https://ronutz.com/en/learn/choosing-a-persistence-method.md): Most persistence requirements are met by source address affinity or cookie persistence, but both have well-known failure modes: source affinity collapses behind NAT, and cookies need HTTP. Knowing where each method breaks is what turns a default choice into a deliberate one. - [Fallback Persistence and the Match-Across Settings](https://ronutz.com/en/learn/fallback-persistence-and-match-across.md): A virtual server can carry two persistence methods, a primary and a fallback used when the primary finds no record, and three match-across settings that decide how widely a persistence record is shared. Both are easy to misconfigure in ways that only show up under load. - [Persistence Mirroring Across an HA Pair](https://ronutz.com/en/learn/persistence-mirroring-and-ha.md): Persistence records live in memory on the active BIG-IP. On failover, the standby takes over connections, but unless persistence has been mirrored to it, it does not know the existing client-to-member mappings, and clients can be rebalanced mid-session. Mirroring trades a little overhead for sticky sessions that survive failover. - [Source-Address Persistence and the Mega-Proxy Problem](https://ronutz.com/en/learn/source-address-persistence-and-mega-proxy.md): Source-address persistence pins a client to a pool member by its IP, which is simple and protocol-agnostic but fragile on the modern internet. Large NATs make many clients look like one, and mobile clients change address mid-session. Both break the assumption the method depends on.