Altocumulus
AltocumulusThank you very much for the reply. It would be good to use oneconnect if possible, but I am not sure how to make that happen yet 😊
The lab setup I tried (please feel free to rubbish this setup and suggest any better alternatives) uses 1 pool per FQDN/HTTP combination. For example if I describe using just two pools for simplicity:
- {www.test.com with Header X = A} maps to Pool A
- {www.test.com with Header X = B} maps to Pool B
I then used a traffic policy to forward traffic to the appropriate pool based on this FQDN/HTTP combination.
Other than name, each pool is 100% the same – same single member (IP & port). The only reason I used different pools was to give different ‘targets’ to load balance to (very welcome to suggestions which only require 1 pool).
I then used an iRule to pick up LB_SELECTED events and assign the appropriate Server SSL profile based on the name of the pool chosen, with the profile actually being attached and used in the subsequent SERVER_CONNECTED event.
This appears to work OK, with a traffic profile along the lines of:
- {www.test.com with Header X = A}
first HTTP request received – create new server connection using server SSL profile A
- {www.test.com with Header X = A}
Any number of subsequent HTTP requests received with same FQDN/HTTP combination –LB_SELECTED doesn’t even trigger, traffic just goes across existing server connection OK
- {www.test.com with Header X = B}
HTTP request received with diff FQDN/HTTP combination – existing server connection closed (TCP FIN) and new connection established to same server but using server SSL profile B
- {www.test.com with Header X = B}
Again connection remains constant while subsequent HTTP requests present with the same FQDN/HTTP combination
- {www.test.com with Header X = A}
Cycle repeats…….
At the TCP level the two server connections (A & B) will be the same, i.e. client addr/port & server add/port will be the same. However the key difference is that each will have used a different server SSL profile, i.e.
Pool A connections use server SSL profile A
Pool B connections use server SSL profile B
Is the oneconnect TCP reuse pool aligned per LTM pool, or is it ‘global’? What is the relationship between TCP and SSL with regard to the idle connections in the reuse pool – i.e. are they purely TCP connections or do they also have active SSL sessions?
I did try enabling oneconnect but results were inconsistent, although usually it just kept all traffic going across the first connection established. I therefore assumed the oneconnect reuse pool was global rather than being a separate reuse pool per LTM pool. I also assume SSL remains established per TCP connection.
If you could help me understand how to amend the setup (happy to scrap what I have and go with something completely different) so as to leverage the power of oneconnect, but while still maintaining the key goal of ensuring the traffic is sent across a pipe which has used the correct server SSL profile it would be very much appreciated 😊
Basically the ideal goal would be traffic switching between two different ‘SSL pipes’ to the same server, similar to that listed above, but with each connection remaining up rather than only one being activated at a time. I know the objective of oneconnect is to keep connections active like that, but I need to understand more about what a oneconnect idle connection actually represents and how the F5 makes a decision on which one to choose – e.g. if it is purely on IP/port info, or if there is some way I can align this to account for the different server SSL profiles used as well.
EmployeeEssentially the oneconnect profile is used IN ADDITION to what you have already configured in your irule/LTM profile. Without a oneconnect profile, your only option is to create a brand new serverside connection every time your header changes. With a oneconnect profile, you can have persistent serverside connections to your two destinations "kept open" and then, depending on the header in the client request, it will just send it to an available connection instead of creating a new one.
That said, oneconnect is not going to pipeline multiple clients to a single server connection, it'll only use an existing connection if that connection is IDLE. If there are no IDLE serverside connections, it'll create a new one, similarly, if you don't meet the mask (for example a /32 mask means clients can only reuse their own connections, whereas a /24 you could let clients with source ips in the same subnet share connections with each other) criteria, it'll also create a new connection (even if there is an idle one for a different mask). The interaction of all this various logic probably explains what you observed as "inconsistent".
It is definitely one of the stranger profiles to understand and tune, but it sounds to me like if you keep your current setup and just add a /32 oneconnect, and it has a timeout that is, say, about twice as long as what you would estimate as the average time between user requests with headers for DIFFERENT destinations, you'd probably see some performance gain.
On the other hand, you can just create new connections every time like you are now, if you have the memory to spare. As long as your tcp idle timeout is reasonable and connections get culled regularly, the impact on the box isn't serious (although your users will obviously experience the delay of a tcp + tls handshake every time the headers switch)