How OneConnect Profile works with Cookie Persistence

1. Preliminary Information

This is a hands-on test based on what K7964 explains regarding interaction between OneConnect® profile and Cookie persistence on Keep-Alive connections.

OneConnect® changes the default behaviour of making a load balancing decision based on TCP connection to one based on HTTP requests. The fact that back-end server connection can potentially be kept alive and reused for different client requests can cause issues for those who don't completely understand OneConnect®.

Whilst working for F5 Support, most cases I had were related to Keep-alive connections, in particular when used with Cookie Persistence.

I hope to clarify OneConnect® behaviour with Cookie Persistence in this article in a practical hands-on way.

2. Scenario

→ Real IP address of Client1 and Client2 does not matter as we'll be focusing on connection between BIG-IP1 and BIG-IP2

Note: BIG-IP is using Cookie persistence (insert) in our example. If you don't understand cookie persistence please refer to K83419154: Overview of cookie persistence first.

For all tests below, 1st request (from Client1) always create new TCP connection between BIG-IP1 and BIG-IP2 and then 2nd request (from Client2) goes through same TCP connection! Keep this in mind while reading, please!

3. Lab test Results

  • Cookie Persistence only (without OneConnect®)
  • BIG-IP only reads cookie persistence entry once for TCP connection (at first HTTP request)
  • If no cookie is sent to BIG-IP, BIG-IP creates one and hands back to client for first request only over a TCP connection
  • BIG-IP also ignores subsequent cookie persistence entries in subsequent HTTP requests and do not hand further cookies over same TCP connection
  • OneConnect® + Cookie persistence
  • BIG-IP reads cookie persistence entry for every HTTP request over same TCP connection
  • If no cookie is sent (e.g. new request), BIG-IP takes new load balancing decision and hands cookie back to client every time
  • If cookie is sent BIG-IP persists based on cookie information for every request over same TCP connection

4. OneConnect® and Cookie Persistence over the same TCP connection

4.1 New requests

BIG-IP takes load balancing decision after each new HTTP request over same TCP connection:

4.2 Subsequent requests

BIG-IP reads cookie persistence entry for each HTTP request and persists:

5. Cookie Persistence ONLY (without OneConnect®) over the same TCP connection

5.1 New requests

BIG-IP creates cookie persistence entry and hands to client after 1st HTTP request and no longer creates further entries for subsequent requests:

BIG-IP also creates one cookie record for the TCP connection and hands it back to Client1.

New request from Client2 goes to Server2 as no new load balancing decision is taken.

5.2 Subsequent requests

BIG-IP only reads cookie persistence entry once for TCP connection (at first HTTP request) but ignores entries for subsequent requests:

If there were multiple clients with different cookie persistence records pointing to other servers, they would all be ignored and BIG-IP would keep sending requests to Server2 as part of first persistence decision when TCP connection was first established.

Published May 05, 2020
Version 1.0

Was this article helpful?


  • For all test scenarios, we work with assumption, that both client1 and​ client2 take the same TCP connection between bigip1 and bigip2. My understanding is that this will only happen if bigip1 is also configured with oneconnect. Otherwise it should not reuse server-side connections and would create new server-side connection for each client, thus the problem with cookie persistence without oneconnect on the bigip2 is no more.

  • Enabling oneconnect between bigip1 and bigip2 makes it easy to simulate a single client sending HTTP requests with differing persistence information over a single TCP connection.

  • Peter, in this article, OneConnect is enabled between BIG-IP1 <-> BIG-IP2 the whole time. Some of our customers do this to avoid opening too many TCP connections. With that in mind, in this particular test, client will be using the same TCP connection between BIG-IP1 <-> BIG-IP2. Now, the lab tests were performed when Cookie Persistence is enabled only on BIG-IP2 regardless. These things I mentioned were fixed in my configuration. Now, what I'm showing here is when we enable/disable OneConnect on BIG-IP 2. When we disable OneConnect on BIG-IP2, no other load balancing decision is taken and some of our customers created support ticket to complain that Cookie Persistence was not working on BIG-IP2 and that is not the case. Why? Because BIG-IP makes load balancing decision per TCP connection. Therefore, the solution would be to enable OneConnect which would ultimately allow BIG-IP to change its load balancing decision to be based on HTTP requests rather than TCP connection. So once a load balancing decision is taken, BIG-IP reads persistence records so Cookie Persistence works every time with OneConnect.

  • Rodrigo,that is quite clear to me.Although it might be a good idea to mention the oneconnect setup on bigip1 so that everyone understands the full picture.Someone with less experience/knowledge​ might get impression that 'multiplexing' TCP connections is a default behavior.

  • Hey Peter, Based on your feedback, I've changed the topology from Section 2. Could you please let me know if it's ok now? Cheers.

  • Thanks for sharing with the capture. But the question is why F5 ignores the persistence record for multiple HTTP request in single TCP connection. so does it mean, F5 records the source address perist to server internally somewhre when there is a single TCP connection although if cookie is present? or it may be the behaviour of F5.  In that case oneconnect provide benefits of having the connection to be opened to server and make it re-use and as well looking at l7 http request for cookie to make load balancing decision or to send traffic to persisted connection.