Forum Discussion
CirrusSNAT and One-Connect
CirrusHello,
For reference here is the OneConnect Overview article.
The article makes it clear, the F5 does not select a pool member based on available idle connections, it selects a pool member based on the load balancing algorithm.
OneConnect selection process- Request comes in, pool selection takes place etc.
- Load balancing decision based on persistence or algorithm.
- Apply mask to translated source address.
- Re-use idle connection and mark in-use, or open new connection and mark in-use.
- Inspect server response: a. 200, 206, 3xx: eligible for re-use, mark connection idle. b. anything else: not eligible for re-use, close the connection.
It is possible to override the default OneConnect re-use behavior via iRule and/or db setting
sys db tmm.http.oc.droponerrorThe mask on the OneConnect profile only applies to the server-side connection. If you SNAT all connections to a single address, the mask on the OneConnect profile for all intents and purposes is irrelevant.
Your scenarioIn your round-robin scenario, the requests that come into the F5 will be balanced round-robin on a per-request basis.
As long as you don't have persistence:- request 1 --> server 1
- request 2 --> server 2
If you want to test the behavior, you could try these steps:
- Configure a 255.255.255.255 mask in your OneConnect profile.
- Write a simple iRule to SNAT to a different IP if the request is from your test browser/client.
- Run tcpdump to capture the traffic server-side from the specific SNAT address from the iRule.
If you capture with noise and view in Wireshark with the F5 plugin, you can see which client-side connections are associated with the server-side connections.
Reducing connectionsIt is true, OneConnect can be used to reduce server-side TCP connections. However, it is important to keep the end goal in mind: performance.
- It's better to have all servers handling requests from a single client-side connection than 1.
- Connection setup is time-consuming, it's better to keep a connection open as long as possible.
The load balancing algorithm on the F5 is one of the tools F5 provides to put you in control of load distribution. I don't think of OneConnect as a way to "reduce server-side connections handled by the F5", the F5 is more than capable of handling lots of server-side connections.
OneConnect is another tool that works in concert with your load balancing algorithm. It allows the algorithm you choose to distribute HTTP load on a per-request basis instead of a per-connection basis.
CirrusHello Kuna,
No, OneConnect does not override Load Balancing.
This is a excerpt from K7208: Overview of the OneConnect profile
Content Switching
When a OneConnect profile is enabled for an HTTP virtual server, and an HTTP client sends multiple requests within a single connection, the BIG-IP system is able to process each HTTP request individually. The BIG-IP system sends the HTTP requests to different destination servers as determined by the load balancing method. Without a OneConnect profile enabled for the virtual server, the BIG-IP system performs load-balancing only once for each TCP connection.
The statement to take note of is:
The BIG-IP system sends the HTTP requests to different destination servers as determined by the load balancing method.
From a packet-processing point-of-view, idle connections are not evaluated until after the server is selected. Load balancing decision occurs client-side, SNAT and OneConnect re-use occur server-side.
Yes, SNAT occurs before OneConnect, but load balancing occurs before SNAT.
From a "why does OneConnect exist?" point-of-view, allowing OneConnect to override the load balancing algorithm undermines the intended purpose of both the OneConnect profile and the load balancing algorithm on the pool.
