Why Sessions Stick to the Same
Server (Support Engineer’s View)
When learning F5 BIG-IP LTM, one
of the most confusing questions is:
“Why is the same user always
hitting the same backend server?”
The answer is Persistence.
In this Document , I’ll explain what
persistence is, why it exists, how it works internally, and how to troubleshoot
common persistence-related issues, from a Technical Support Engineer’s
perspective.
What Is Persistence in F5 LTM?
Persistence ensures that multiple
requests from the same client are sent to the same backend server for a
specific duration.
Without persistence:
- Each request can go to a different server
- Many applications will break
With persistence:
- Session data remains consistent
- Applications behave correctly
Why Persistence Is Required
(Real-World Examples)
Persistence is critical for applications that:
- Store session data locally on the server
- Don’t share session state across servers
Examples:
- Login-based applications
- Shopping carts
- Banking portals
- Legacy web apps without centralized session storage
Without persistence, users may see:
- Random logouts
- Session resets
- “Invalid session” errors
Where Persistence Fits in
Traffic Flow
Traffic flow with persistence
looks like this:
Client → VIP → Persistence Lookup → Pool Member → Server
At a high level:
1. Client sends request to VIP
2. F5 checks if a persistence record already exists
3. If yes → send traffic to the same server
4. If no → select a server and create a persistence entry
Common Types of Persistence in
F5 BIG-IP
1️. Source Address Persistence
- Based on client IP address
- Common for non-HTTP traffic
- Simple but not ideal for NATed users
Example:
Client IP → Server A
Issue:
- Multiple
users behind the same NAT may stick to one server
2️. Cookie Persistence (Most Common)
- Used for HTTP/HTTPS applications
- F5 inserts a cookie to identify the server
Types:
- Cookie Insert (F5-managed)
- Cookie Passive (Application-managed)
This is the most widely used
persistence method in LTM.
3️. SSL Persistence
- Uses SSL session ID
- Useful when cookies are not available
- Less common in modern deployments
4️. Universal Persistence (Advanced)
- Custom persistence using iRules
- Used for complex or non-standard applications
Example:
- Persist based on header value, token, or custom logic
Persistence Profile – Where It
Is Configured
Persistence is configured using a Persistence Profile, which is then attached to:
- A Virtual Server
- Or sometimes a Traffic Policy
Key things inside a persistence profile:
- Timeout value
- Cookie settings
- Match criteria
- Fallback options
Important Concept: Persistence
vs Load Balancing
This is often misunderstood.
- Load balancing decides which server gets the first request
- Persistence decides where subsequent requests go
Once persistence is in effect:
- Load balancing is bypassed for that session
Persistence Records (Behind the
Scenes)
F5 stores persistence entries in
memory, similar to connection entries.
Each record maps:
Client identifier → Pool member
This is why persistence issues can often be fixed by:
- Clearing persistence records
- Adjusting timeout values
Final Thoughts
Persistence is not just a feature — it’s a critical
application requirement.
Many F5 issues that look complex become simple once you understand:
- Why persistence exists
- How F5 enforces it
- How long persistence entries live
Technical Discussion
Comments
Post a Comment