Hi Hui,
OneConnect works by enforcing a HTTP 1.1 keep-alive behavior between the BIG-IP and the pool member(s), and then aggregating client HTTP requests (1.0 or 1.1) down idle TCP connections that exist on the server-side of the operation. In order to be efficient, OneConnect will often reuse a client socket (IP:port) from a previous connection on behalf of a new client connection.
Another important function of OneConnect is to perform "layer 7 load balancing", meaning that each HTTP request is considered for load balancing, as opposed to the TCP connection underneath. Thus, without persistence, if I have 3 pool members, and recieve 6 HTTP requests, using round-robin, each pool member would service 2 requests. The BIG-IP always processes load balancing first, then handles idle sockets second. If a pool member is selected but has no idle sockets, OneConnect will initiate a new connection, possibly using a socket from a previous connection from the connection pool.
For example, here is a hypothetical connflow entry for Client A to a Virtual Server listening on 10.10.1.100:80
10.10.1.10:5001 :: 10.10.1.100:80 (Client :: Virtual Server, aka client-side)
10.10.1.10:5001 :: 172.16.20.1:80 (BIG-IP :: Pool Member, aka server-side)
Sometime later, Client A closes the connection. Assuming the pool member's web app does not signal "connection:close" in the HTTP response, OneConnect will then detatch the server-side flow from the client-side flow mark it as eligable for reuse, meaning this server-side connection is idle.
Some time later, Client B connects and then by process of selection, is load balanced to the same pool member. So now we have:
192.168.20.1:35000 :: 10.10.1.100:80 (client-side)
10.10.1.10:5001 :: 172.16.20.1:80 (server-side)
Some time later still, Client C connects, and is sent to a new pool member. This pool member does not have any idle sockets. So OneConnect creates a new one, but is free to use Client A's socket because it is still in the pool. So we get:
16.20.1.5:9051 :: 10.10.1.100:80 (client-side)
10.10.1.10:5001 :: 172.16.20.2:80 (server-side)
Note how 10.10.1.10:5001 suddenly appears, as if out of nowhere, to open a connection to a new pool member, 172.160.20.2. As long as a client entry is valid in the conn pool, OneConnect can use it to represent any other client.
If you don't like this behavior, you can control the selection of which client IP can be reused by another by altering the mask setting in the OneConnect profile. Another solution is to enable SNAT. Then the only element that will shift between the BIG-IP and the pool members will be the proxied source port.
In addition to SNAT, it should be possible to contrain the range of source ports used betwen the BIG-IP and the pool members with an iRule. This should be approached with caution, however, due to ephemeral port exhaustion.
Cheers,
Dr. W
Nimbostratus
