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?

Nice summary Mikand. To add one comment:

 

 

Lastly - I still don't quite get why OneConnect is recommended for L7 persistence configurations. Can you please help explain this further? I wasn't able to glean this information from the article.

 

 

Basically you should use OneConnect to ensure TMM evaluates persistence and/or pool selection on each HTTP request instead of once per client to virtual server TCP connection. See Deb's article on OneConnect with HTTP for more info:

 

 

OneConnect? For my iRule?

 

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=114

 

 

Aaron

 

Good input guys.

 

 

I've had a chance to read the http://www.f5.com/pdf/deployment-guides/oneconnect-tuning-dg.pdf article. Nice.

 

1. Can someone explain where I'd set the "Pool Member Connection Limit" on a non-CMP device?

 

 

2. Also everytime I read the OneConnect article, F5 or someone else would keep mentioning client source IPs as if they get 'mingled' with OneConect on.

 

Eg. SOL 5911: "Note: Using a broad source mask may skew server-side statistical data. For example, when using the mask 0.0.0.0, request from multiple clients may appear as though they are originating from a single IP address." So what? Is that a hint for 'watchout? I've heard a case where the customer had different users seeing other users mailboxes randmly in exchange and I wonder if I'd have to question this? We are using OneConnect on Exchange VS as well.

 

 

3. I had this question at the back of my head as well about OneConnection with Load Balancing. And F5 is tracking the Least Connections option under CR120223 - what about other algorithms though (either way one connection would send request to same member!!!). I for one thought the loadbalancing algorithm is somehow ignored with OneConnect on for existing server-side connections. Deb Allen mentioned that load balancing is done at connection level not request level????? Again I must admit that F5 mention that (SOL 7208) "Because the OneConnect profile re-uses idle connections, it may appear that the BIG-IP system is not load balancing traffic evenly across pool members."

 

 

Above all I think the OneConnect is such a feature. I still need to fgure out where to intercept for connections that I want to reset etc. There is LB::detach, OneConnect::enable & OneConnect::detach.

 

Awesome.

 

Maybe I should take some time off networking to delve in Applications related staff a bit. HTTP::Header etal is the new lingo!!

Re. Q2, yes, some dumb applications associate requests to sessions via IP addresses/connections instead of just looking at the session cookie in each request. I personally have seen instances of users being able to access other user's data because of connection multiplexing (not through F5, but the principle is the same). It's probably worth checking the Exchange deployment guide for more info.