Here's the question I cannot find definitive answer to: does F5 LTM distribute incoming TCP connections - or HTTP requests arriving via these connections, making load balancing decision for each request independently, regardless to the connection it arrives through and to whether it was the first request to arrive via this connection or not?
Let me explain the rationale: some CDN systems, like Incapsula, multiplex requests from multiple clients over the same TCP connection towards a backend (in our case, load balancer). This can be problematic for the load balancer. For instance, when we used FortiGate, this caused session persistence to break - because FortiGate distributes connections, not requests, even though it checks the session stickiness cookie in the first request. So all requests multiplexed into such connection ended hitting the same webserver, regardless of their own session stickiness cookie value.
How does LTM handle such connections? If cookies are used for session persistence - will it inspect such cookie only for the first request arriving via new connection (and then forward all the following requests to the same node selected for the first one)? Or will it decide for each HTTP request, which node to deliver it to, based on the session cookie of this specific request, or on absence of such cookie?
Is its default behavior customizable?
Solved! Go to Solution.
When you use a standard virtual server with a HTTP profile the BIG-IP will load balance HTTP requests. It will inspect every request, if there is no persistence cookie LTM will load balance this request to the next available pool member (based on your LB algoritme) HTTP request with a persistence cookie will be load balanced to the backend server that is in the cookie value.
This is the default behaviour of a standard virtual server with a HTTP and cookie persist profile.
But I just found this article:
and it claims that this happens only when both HTTP profile and OneConnect profile are applied:
If no OneConnect profile is associated with the virtual server, the BIG-IP system selects a pool member once, when the client-side connection is first established. After a pool member is selected, and the TCP connection is load balanced, all subsequent requests on the same Keep-Alive connection are sent to the same pool member.
For example, if a OneConnect profile is not associated with the virtual server, and the client request is initially sent to node A in pool A, the BIG-IP system inserts a cookie for node A. Then, the BIG-IP system receives a subsequent request within the same TCP connection that contains a cookie for node B in pool B. The BIG-IP system sends the request to node A.
Is this true, in your experience?