Exam Topics
- F5CAB3
- F5CAB3.01
- Apply appropriate persistence profile
- F5CAB3.01
Introduction
While Source Address Affinity persistence is simple and easy to implement, it also has some important limitations. For example, multiple users sharing the same public IP address (such as users behind a proxy server, NAT device, or VPN) will share the same persistence entry and therefore be directed to the same backend server. This can create load imbalance and reduce the effectiveness of load distribution.
Another limitation is that Source Address Affinity consumes memory on the F5 BIG-IP, since persistence records must be stored locally in the persistence table.
Cookie persistence profiles address these limitations by providing more granular persistence based on HTTP cookies rather than IP addresses. This allows the BIG-IP to uniquely identify individual users even when they share the same source IP address.
Additionally, most of the time the persistence information is stored directly in the client’s cookie rather than in the BIG-IP persistence table. This significantly reduces memory usage on the device while still maintaining session stickiness.
In this section, we will review the different cookie persistence methods, how they work, and when to use each of them.
What is an HTTP Cookie ?
Since cookie persistence relies on HTTP cookies, it is important to first understand what a cookie is.
A cookie is a small piece of data stored by a website in a user’s browser. It contains information related to the user’s session or preferences. Once a cookie is set, the browser automatically includes it in subsequent HTTP requests to the same website.
Technically, when a web server wants to store a cookie on the client, it sends a special HTTP response header called Set-Cookie. This header instructs the browser to save the provided data. On subsequent requests, the browser automatically includes this information in an HTTP request header called Cookie, allowing the server (or intermediary devices like the F5 BIG-IP) to identify the client.
This makes cookies an ideal mechanism for persistence:
- A cookie is tied to a specific user (more precisely, a browser session)
- It can store information, like the backend server to use
Because the F5 BIG-IP sits between the client and the server, it can insert, read, or modify cookies in HTTP traffic. This allows it to use cookies as a reliable method to maintain persistence and ensure that a client is consistently directed to the same backend server.
Since cookie persistence relies on an HTTP mechanism, it can only be applied to Virtual Servers that use an HTTP profile (which enables the BIG-IP to understand and process HTTP logic). Additionally, because the BIG-IP needs to read cookie data, the traffic must either be unencrypted HTTP or decrypted HTTPS.
Cookie Persistence modes
When configuring a Cookie persistence profile, four modes are available, each differing in how persistence is implemented using cookies.
HTTP Cookie Insert
With the HTTP Cookie Insert method, the F5 BIG-IP inserts its own persistence cookie in the first HTTP response by adding a Set-Cookie header. This cookie contains the selected pool member information in an encoded format....

