Contents:
- What is OneConnect™?
- HTTP/1.0 vs HTTP/1.1 and OneConnect
- Understanding OneConnect Source Masks a.k.a. Source Prefix Length a.k.a. OneConnect Mask
- OneConnect Transformations
- OneConnect with SNAT vs. Inline Traffic
- OneConnect Profile Settings
- OneConnect & Persistence & Content Switching
OneConnect has been around since the F5® BIG-IP® became a full proxy in version 9.x, but to this day it remains one of the most powerful and important F5 features for scaling HTTP traffic to websites and modern web applications. Understanding F5 OneConnect can help you extend the life of your servers and network while decreasing latency. Let’s dive into all the important pieces of OneConnect so we can gain a better understanding of how you should and shouldn’t use OneConnect.
What is OneConnect?
F5 OneConnect is a BIG-IP feature that allows you to reuse established server-side TCP connections to servers in pools behind the BIG-IP when sending HTTP traffic. HTTP traffic is important there, as OneConnect was built for HTTP and should be avoided for other protocols – with that in mind OneConnect must always be used with an associated HTTP profile.
When previously established TCP connections on the server-side can be reused, creating new connections can often be avoided – resulting in less connections on the backend servers. Since each new connection established on the servers causes them to allocate resources, using OneConnect can save valuable server resources around threads, memory, and CPU. Savings really start to add up at the higher traffic rates.
How do you turn on OneConnect?
OneConnect is accessed via a OneConnect profile placed on a virtual server in the F5 BIG-IP. This allows you to use the feature on a “VS by VS” basis (i.e. it does not have to be used globally).
HTTP/1.0 vs HTTP/1.1 and OneConnect
Before we jump into the nuances of OneConnect, we’ll need to make sure you understand how HTTP 1.0 handles connections and traffic differently than HTTP 1.1 – I know the suspense is killing you 😉 … in short – HTTP 1.0 is pretty inefficient when it comes to connections – sending one http request per TCP connection – for example: GET /index.html and GET /image.gif – that’s 2 TCP connections in HTTP/1.0 world. HTTP 1.1 officially makes use of Keep-Alives for http traffic, allowing connections to remain open for a bit allowing re-use of those older connections. This allows GET /index.html and GET /image.gif all over the same connection to the server from the same host. HTTP/1.0 actually has the Keep-Alives feature, but as an experimental implementation for persistent connections.
F5’s OneConnect takes the HTTP 1.1 Keep-Alive concept one step further and allows you to send multiple HTTP requests from more than one source client over the same backend / server-side connection(s). HTTP 1.0 is indeed supported with OneConnect from a client-side and server-side perspective, because of the OneConnect Transformations feature built into OneConnect that can transform HTTP 1.0 client side connections into HTTP 1.1 server-side connections – allowing HTTP 1.0 hosts and servers to use the benefits of HTTP 1.1 and OneConnect. Yes servers too! Since HTTP 1.0 had keep-alives support, OneConnect with transformations *typically works with older HTTP 1.0 servers as well.
Note: HTTP pipelining is not compatible with OneConnect and must be disabled on your servers when using OneConnect. It’s typically not an issue as pipelining is rarely used these days and disabled by most browsers.
How does BIG-IP decide which connections are eligible for re-use to which hosts? It’s done via a setting inside the OneConnect profile – Source Mask a.k.a. “Source Prefix Length.”
Understanding OneConnect Source Masks a.k.a. Source Prefix Length a.k.a. OneConnect Mask
Up to version 11.x F5 used the term “source mask” in the GUI when describing which clients could use the eligible connections “kept alive”, and in version 12.x on they started to refer to it as “Source Prefix Length”. Throughout F5 documentation you may also find it referred to as “OneConnect mask” – I know I know, fun stuff right? To further confuse you it’s consistently labeled as “source-mask” through v.10-13x+ in the CLI via TMSH 🙂
You’re probably familiar with how a subnet masks works, i.e. a typical subnet mask tells you how many usable hosts are available per subnet. The OneConnect Source Prefix Length works in a similar way, but in OneConnect’s case the mask is used to identify if the IP is part of the range that is eligible for re-use. Note that if SNAT is used, the source mask is applied to the translated address – it’s not applied to the true source of the client, rather it’s applied to the SNAT address that belongs to the BIG-IP. That’s super important to understand and I dive into it a bit more below in the OneConnect with SNAT vs. Inline Traffic section.
For example: a mask of 255.255.255.255 uses all 32 bits, and if used in your typical subnet mask scenario the range would only be a single address. Similarly in the OneConnect Source mask case, if 255.255.255.255 is used, the BIG-IP would only reuse connections that came in with the exact IP. In other words, let’s say my IP was 10.2.1.175 and I accessed a Virtual Server that had OneConnect turned on and the source mask = 255.255.255.255, only if I came in again (before the keep alive timer ran out of course) with the same IP of 10.2.1.175 would the BIG-IP be able to reuse the server side connection. Conversely, if you configured a source mask of 0.0.0.0, you would have no bits selected and any IP coming into that VIP would match could use any of the connections held open by OneConnect on the server side.
You want to make sure you understand how the masks work especially when using too broad or too short of a OneConnect source mask – too broad like 0.0.0.0 may skew your load balancing and multiple clients would appear as if they are originating from one IP address – this is not always a bad thing but server folks may have something to say about it ;). Too specific and you’ll never reap the benefits of multiplexing connections, but you may see a more even balance of load across servers in your pool.
Note: The prefix length can also be used for IPv6 addresses, with a value of up to 128 bits.
Here is a table to help you understand how source mask works:
| OneConnect Source Mask a.k.a. Source Prefix Length | Which Hosts are Eligible to Reuse Server-Side Connections |
| 0.0.0.0 | This is the default setting – all zeros or no bits. This will consider any client coming in eligible to use OneConnect designated open TCP connection on the server side. This “any” mask doesn’t group connections based on octets matched, rather it uses open TCP connections marked for reuse at will. F5 notes this is highly efficient – but one could argue efficiencies could be lost if traffic patterns are sending a lot of traffic to one server vs. other pool members. |
| 255.0.0.0 | Only needs the first octet to match to select an idle TCP connection for reuse. For example, if a client with an IP of 10.40.20.35 is first to come into a virtual server with a OneConnect Profile assigned with this source mask, and another client comes in with an address of 10.22.33.44 (while that server-side connection is still held open for reuse) it would be eligible to that client as only the “10” in the first octet needs to match – the other 3 octects can be anything. |
OneConnect Transformations
As discussed above in the “HTTP/1.0 vs. HTTP/1.1 and OneConnect” section in this article, HTTP 1.0 clients and servers can take advantage of OneConnect by utilizing the OneConnect Transformation feature – the setting is on by default in the OneConnect profile.
So what does the OneConnect Transformation setting actually do under the hood? If you recall the example above with the GET /index.html and GET /image.gif being two separate connections in 1.0, it’s because after the first GET /index.html the client sends a “Connection: close” header. In the same example HTTP 1.1 does not send that connection close header, instead it uses the “Connection: Keep-Alive” header to keep the party going. OneConnect Transformation takes the Connection: Close headers and changes them to X-Cnection: close, and also ads the Connection: Keep-Alive header on the server-side to keep the connection open after the server has sent its response. So what the heck is the X-Cnection: close header for? Just tracking, the servers *should ignore it, but if you wanted to key on something on the servers to log how many connections are utilizing HTTP 1.0 and being transformed you could key on it. It makes for some fun around the office “Look at all the people actually still using HTTP 1.0!! :)” Unless of course your servers are still on 1.0, <face palm>!
With the transformation feature the 1.0 clients and servers can now reap the benefits of 1.1 without ever having to lift a packet (c’mon it’s a network joke stay with me folks!). The server-side connections will now stay open and available for reuse until the server or the BIG-IP system closes the connection for:
- Exceeding the TCP connection idle-timeout
- Exceeding the TCP Keep-Alive idle-timeout
- Exceeding Maximum Reuse value
OneConnect with SNAT vs. Inline Traffic
SNAT, if you’ve been using F5 for a while at some point you’ve come across SNAT and SNAT auto-map. Essentially SNAT allows you to load balance and provide other BIG-IP services to any server the BIG-IP can route to by changing the server side source address to an address that the BIG-IP owns. Since the F5 is a Full Proxy and manages both client side and server side connections independently, traffic that enters the F5 has to leave the F5 as well – i.e. asymmetric routing bad <insert gorilla grunting noise>. Hence SNAT changes that server-side traffic to source from the F5 so traffic comes back to it after hitting the server a.k.a. pool member. The alternative to this inline traffic, i.e. the servers being load balanced need to explicitly route back through the F5. Inline traffic is typically accommodated by changing the server’s gateway to a self IP on the BIG-IP, but I’ve also seen this accomplished by shear nature of topology, i.e. somewhere in the routing all traffic passes back through the BIG-IP.
Okay, so why should you be concerned about SNAT and OneConnect? It’s because the source mask a.k.a. source prefix length keys on the address AFTER the SNAT translation has been completed. The order of operation is:
- BIG-IP system parses the HTTP request
- Server is selected using the load-balancing method defined in the pool
- SNAT is performed and translates the true source IP to the SNAT IP address
- OneConnect prefix length is applied to the SNAT IP address and TMOS® determines if the address matches the prefix length and is eligible to reuse an existing idle connection
Because the OneConnect mask / prefix length is applied to the SNATed address, you have to be careful when using OneConnect with SNAT–as the SNATed address will typically be the same. This results in the BIG-IP basically ignoring the source mask you set, as it will always match unless you’re using a SNAT pool. OneConnect with SNAT auto-map (no snat pool) basically works similar to a source mask of 0.0.0.0, matching all connections, but that may not always be your intent. Morale of the story is to be cognizant when you use SNAT with OneConnect and plan accordingly with something like a SNAT pool to ensure the source mask / source prefix length is used how you intended it to be.
To combat uneven load balancing, you can consider using the maximum re-use value to force the BIG-IP to make another connection and load balancing decision.
Here are a couple scenarios to consider when using OneConnect and how you can combat them:
- Uneven Load Balancing – Consider using the maximum re-use value to force the BIG-IP to make another connection and load balancing decision. This will force traffic to be sent to other pool members and help even the load.
- Losing the Client IP address a.k.a. True Layer 3 Source Address – When you use SNAT with OneConnect (and even without OneConnect you’ll run into this), or broader source masks like 0.0.0.0, you should consider using the X-Forwarded-For header, which can be turned on in the HTTP profile. All modern web servers can be modified to log the XFF vs. the true client source address in their log files to capture the source address.
OneConnect Profile Settings
| OneConnect Profile Setting | Description |
| Source Mask / Source Prefix Length | Mask applied to the source IP address used to determine if the connection is eligible to reuse a server-side connection |
| Maximum Size | Max number of idle server-side connections kept in the connection pool |
| Maximum Age | Max number of seconds a server-side connection is allowed before the connection is deleted from the available connection pool |
| Maximum Reuse | Max number of requests to be sent over a server-side connection. If this value is used, it’s recommended to be set a bit lower than the maximum number of HTTP Keep-Alive requests accepted by the back-end servers. This is to prevent the back-end server from initiating a connection close and entering the TIME_WAIT state. |
| Idle Timeout Override | Max time idle server-side connections are kept open. If you lower this value it may result in a lower number of idle server-side connections, but at the expense of increasing request latency and server-side connection rate. |
| Limit Type | Available in 11.6 and later, this controls how connection limits are enforced in the previous settings
|
OneConnect & Persistence & Content Switching
By default BIG-IP performs load balancing on a per TCP connection basis, but with HTTP Keep-Alives multiple requests can be contained in a single connection. This poses problems when using persistence or content switching with HTTP – as out of the box BIG-IP does not account for load balancing on a per request basis, again it’s performed per connection. This results in the first request after a connection is established to be sent to the correct pool member – honoring persistence and content switching logic, but subsequent requests also go to the same pool member, regardless of the persistence and content switching logic you’re using.
To fix this you need to detach the server-side connection so the BIG-IP makes a new load balancing decision, you can do that in one of two ways:
- iRule command LB::detach
- OneConnect
You can explicitly use the iRule LB::detach command to “detach” the server-side connections but unless you need to do something past that with more iRule logic the OneConnect profile detaches server-side connections by default. I know that doesn’t sound intuitive at first – in one breath we’re talking about keeping connections alive, but then we’re saying we detach connections by default. Think of it this way – we’re only detaching connections from the F5, not the server, so the connection is still there at the server waiting for more requests.
I hope you found this article helpful in your journey to understanding OneConnect and BIG-IP. Do you have a question or maybe an interesting story how you solved a problem, or caused :), with OneConnect? Well, the world is waiting! Post a comment below!
Leave a Reply