Question on using OneConnect (as referenced in contained article/link)

Dunno if this answers your questions but Ill make an attempt ;-)

 

 

1) You can for "action on service down" in the pool settings set it to "reject" to have the LTM send a RST back to the client if the current server the client is being connected to goes offline for some reason (either automatic by monitoring failing or manually if you disable the current server in your pool like for maintenance) no matter if you are using Oneconnect or HTTP profile.

 

 

I for example prefer to lock each client ip through persistence profile (I also dont use the SNAT automap thingy) instead of doing stuff with cookies which gives that the client will hit the same server until the persistence timesout (lets say 1 hour or whatever you prefer) or until the server goes offline (which will result in a RST back to the client which in turn often means that the client reconnects and when reconnected the LTM will take a new loadbalancing decision and so on).

 

 

2) As I understand the point of using Oneconnect (specially if you set it to a 255.255.255.255 mask) is to serialize connections that passes through the LTM.

 

 

So lets say you setup a VSERVER to act as forward-http proxy (it will forward the traffic to a real forward http-proxy) - there is a good chance (or high risk :P) that the clients will try to issue multiple requests towards this virtual ip forward http-proxy.

 

 

Either you can change the client settings... OR you can fix this in the F5 with Oneconnect instead.

 

 

What Oneconnect in this case will do is to take lets say the client 10 concurrent sessions and make them into a single session which is being sent through the forward http-proxy. So client <-> F5 will be 10 concurrent sessions but F5 <-> forward http-proxy will be just 1 concurrent session (per client).

 

 

The good thing here is that with lets say 1.000 concurrent users instead of having 10.000 concurrent sessions through the forward http-proxy the Oneconnect (when using 255.255.255.255 as mask) will make this into just 1.000 concurrent sessions (one session per client ip).

 

 

I guess you have already looked at http://www.f5.com/pdf/deployment-guides/oneconnect-tuning-dg.pdf for ideas on how oneconnect could optimize the flows?