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.
→ Real IP address of Client1 and Client2 does not matter as we'll be focusing on connection between BIG-IP1 and BIG-IP2
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.