In this lab, we’ll explore F5’s OneConnect feature, which optimizes connection management between clients and backend servers.
This lab will show you that it is almost never a bad idea to activate OneConnect—provided you have a solid understanding of how it works and the changes it introduces to traffic handling.
With this knowledge, OneConnect becomes a powerful tool for maximizing server efficiency and managing traffic effectively.
Objectives
Pre-requisites
Tasks
Credential list :
F5 Big IP :
Username : admin (web ui) / root (cli)
Password : MyLabs789$
Web Viewer VM :
Username : labs
Password : labs
Web Server VM :
Username : labs
Password : labs
Task 1 : Apply the OneConnect profile
After loading the UCS file, you should notice that a virtual server and its associated pool have been created. This virtual server is configured to load balance HTTP traffic using the round-robin method.
| Virtual Server name | Virtual Server IP:port |
| oneForAll_vs | 192.168.110.102:80 |
| Pool member server name | Pool member IP:port |
| Server Red | 192.168.120.2:80 |
| Server Blue | 192.168.120.3:80 |
| Server Green | 192.168.120.4:80 |
To verify that the virtual server is functioning as expected, use the WebViewer VM and access the page at http://192.168.110.102/.
By default, Firefox uses up to 6 concurrent TCP connections to a server. For this lab, it will be easier to reduce this to a single TCP connection to observe the OneConnect effect on traffic.
-
- Open Firefox on the WebViewer VM and, in the URL field, type
about:config. - Accept the risk prompt.
- Open Firefox on the WebViewer VM and, in the URL field, type
- In the configuration tab, search for
network.http.max-persistent-connections-per-serverand set its value to 1.
This adjustment ensures that all HTTP requests will be sent over a single TCP connection.
Reset the pool statistics. Do exactly 12 hard-refresh of the root page.
How many total connections were made to the backend servers ? Why are all the element of the page the same color now ?
First do a reset of the pool statistics.
Go to Local Traffic ›› Pools : Pool List, select the oneForAll_pool.
Open the Statistic tab, select all pool member and clic on Reset. All statistic should display 0.
After performing 12 hard-refreshes, exactly 12 connections to the backend servers were made. This can be viewed on the pool statistics, the column Total under Connection display 12 :
Each hard-refresh generated a single TCP connection to the virtual server, with all HTTP requests for the page elements sent over this one connection. All page elements display in the same color because the F5 BIG-IP is load balancing at Layer 4 level (TCP) in this setup. Consequently, all HTTP requests are directed to a single backend server within each refresh.
Previously, multiple colors appeared because Firefox could open up to 6 concurrent TCP connections, allowing up to 6 backend servers to respond. This resulted in different elements being served by different servers. For this lab, we limited Firefox to a single TCP connection to demonstrate that multiple HTTP requests within a single TCP connection are not load balanced across multiple servers.
The system administrator approaches you with a remark. He learned about a profile called OneConnect that can optimize HTTP load balancing. He asks you to activate it on the virtual server.
Create a OneConnect profile that inherit the default OneConnect profile. Assign it to the virtual server.
Go to Profile – Other – OneConnect. Create the profile without changing the default value :
Now, assign the OneConnect profile to the virtual server. Go to the oneForAll_vs and under acceleration setting, assign the OneConnect profile :
Now that OneConnect is enabled on the virtual server, let’s generate some traffic to see if there are any changes.
Reset the pool statistics. Make sure there is no current connection (all the statistics should display 0)
Then, do exactly 12 hard-refresh of the root page using the webviewer VM.
How many total connections were made to the backend servers ?
After performing 12 hard-refreshes, only 6 connections were established to the backend servers (with 2 CPUs/vCPUs). This can be verified in the pool statistics.
You can also view the virtual server statistics, which provide information about the OneConnect profile.
We can see that a maximum of 6 connections were made, and these connections were reused multiple times.
The OneConnect profile allows for backend connection reuse, meaning that each new client connection does not necessarily initiate a new TCP connection on the server side. Once a connection is established to the backend, the F5 keeps it active and can reuse it for subsequent client connections. With 3 backend servers and 2 TMM instances, up to 6 server-side connections can be open and available for reuse by client connections simultaneously.
Before the OneConnect profile was applied, each connection on the client side was directly associated with a connection on the server side.
Why are all the element of the page of different color now ?
All elements on the page now display in different colors thanks to the OneConnect profile. When a client sends multiple HTTP requests over a single TCP connection, the OneConnect profile enables the F5 to process each request individually. This allows load balancing to occur on a per-request basis instead of per connection, meaning that different requests within the same TCP connection are distributed across multiple backend servers.
Previously, the entire page appeared in a single color because all requests were handled by the same backend server. Now, with requests being balanced across multiple servers, the page showcases a variety of colors.
The system administrator is pleased with the optimizations implemented. However, he has noticed that in some cases, the reuse of backend connections is not occurring.
Reset the pool and virtual server statistics.
Do exactly 12 hard-refresh on the page “http://192.168.110.102/nonexistant.php“.
How many connection are made to the backend server ? Why ?
Since the page does not exist and returns an HTTP 404 error code, the backend connection is no longer eligible for reuse with OneConnect.
Consequently, each request establishes a new connection to the backend server.
OneConnect marks a backend connection as available for reuse only when the previous request returns a successful HTTP 200 or HTTP 206 response code; any other response code renders the connection ineligible for reuse, resulting in the establishment of a new connection.
The system administrator still wants the connection to be reused even in the case of a 404 error.
What profile should be modified ? Change the correct setting to allow connection reuse on 404 error and verify with the virtual server statistics
The OneConnect Status Reuse is managed by the HTTP profile.
Open the HTTP profile oneForAll_http.
Clic the overide checkbox at the end of the line OneConnect Status Reuse to allow the modification.
Add the 404 status code :
Performing 12 hard-refresh on the nonexistant page now display a reuse of connection inside the virtual statistics page :
Task 2 : Customize the OneConnect profile
The administrator notes that the optimization is working almost too well, as each client is currently reusing only one (or two, if you are running two TMM instances) TCP connection on each backend server. He would like the behavior adjusted so that each client has a dedicated backend connection that is still reusable. This means that if a client generates multiple TCP sessions, all should route through a unique backend connection per client, without sharing connections between different clients.
Modify the OneConnect profile to meet this requirement.
What setting do you need to change ? Change it.
Go to Profiles : Other : OneConnect
Select your OneConnect profile.
Clic the overide checkbox on the right of the Source Prefix Lenght option and enter 32 as mask.
This mask ensures that each client has its own dedicated backend connection.
Open the WebViewer 2 virtual machine. Perform the modification on firefox described at step 1 to generate a single tcp connection to the web server.
Reset all statistics.
Perform 6 hard-refresh on each virtual machine, 6 for WebViewer 1 and 6 for WebViewer 2.
How many connection to the backend server are made ? Is it the expected behavior ? Why ?
There is 6 connections made to the backend server.
With the new mask, we expected each client to have its own reusable backend connection, resulting in a total of 12 connections.
Reviewing the virtual server, we can see that SNAT is enabled, translating the source IP address to a Self-IP. The behavior of the OneConnect mask changes when SNAT is in use, as the mask is applied after the Source NAT occurs. In this case, only a single IP address is used after the transformation.
As a result, OneConnect sees only one source address, leading to a single connection that all clients can reuse.
Remove the SNAT auto-map from the virtual server configuration.
Reset all statistics.
Perform 6 hard-refresh on each virtual machine.
How many connection to the backend server are made ?
Remove the SNAT setting in the virtual server page :
Local Traffic ›› Virtual Servers : Virtual Server List ›› oneForAll_vs
On the line Source Address Translation, select none.
After making the modification and establishing the connections, we observe 12 connections to the backend servers.
Without Source NAT, the OneConnect mask now applies to the clients’ source addresses. With 2 clients, each having a different IP address, this results in 6 connections to the backend servers per client.
Task 3 : OneConnect Transformations
The system administrator is pleased with your optimization but would like to understand more about how OneConnect manages to keep a session alive for reuse.
What HTTP mecanism OneConnect uses to keep the connection alive to the backend server ?
The OneConnect profile leverages the HTTP Connection: Keep-Alive header, which instructs the backend server to keep the connection open. This header is automatically included by clients using the HTTP/1.1 protocol. When a client-side session reaches the F5 BIG-IP, it includes this Keep-Alive header, which is then mirrored on the server side, allowing the backend session to remain open. This enables subsequent clients accessing the virtual server to reuse the existing backend session.
The system administrator understand that the HTTP/1.1 Connection header is a key part on how the session is maintained open on the backend side so it can be reused. But he asks you what happen if the client force the connection close using the header Connection: close ? Is the server side session maintened open ?
On the webviewer, open a terminal.
In the terminal, use the curl command to force the header Connection: close :
curl -H “Connection: close” 192.168.110.102 -o /dev/null
The command instruct to access the virtual server with a header Connection: close and to not ouput the result of the webpage.
Reset the pool and virtual server statistics.
Perform the command 12 times.
Are the connection reused on the backend side ?
There are only 6 connections in total on the backend side, indicating that sessions are being reused even when the client sends a Connection: close header.
By default, when the virtual server receives a Connection: close header with a OneConnect profile configured, the F5 transforms the Connection: close header to a Connection: Keep-Alive header on the server side.
Is the Connection:close honored on the client side ?
When opening the webpage in Firefox, we can observe in the virtual server statistics that the connection remains open:
The client-side connection stays active, with only one connection displayed, even after performing a hard refresh. This indicates that the Connection: Keep-Alive is respected by default on the client side.
If we use the curl command to force a Connection: close, we can see that no connection remains once the command completes, confirming that the Connection: close is honored.
The OneConnect statistics still show connection reuse, demonstrating that the Connection: close is correctly transformed to Keep-Alive on the server side, and the Keep-Alive is reverted to Connection: close on the client side.
How does the Big IP knows when to return a Connection:close on the client side ?
Since the Connection: close header is transformed into Connection: Keep-Alive on the backend side, we might wonder how the F5 BIG-IP knows when to reverse this transformation (i.e., convert Keep-Alive from the server back to close for the client).
When this transformation occurs, the F5 BIG-IP not only changes Connection: close to Keep-Alive but also inserts a new header, X-Connection: close. This header is ignored by the backend server but is returned in the HTTP response. This way, the F5 BIG-IP is informed that the client from the original request wanted the connection closed. The F5 then closes the connection on the client side while keeping the session open on the backend side.
The system administrator can’t believe how powerful and sophisticated the F5 BIG-IP is. He only believes what he sees with his own eyes. Prove, using tcpdump, that the header transformation takes place.
Perform a tcpdump command on the F5 Big IP to show the header transformation in action
Remove the health check for the pool to simplify capturing the necessary packets in the tcpdump.
Execute the following tcpdump command:
tcpdump -A -nni 0.0 ‘((tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420) or (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450))’
Explanation of the command:
tcpdump: Packet capture command
-A: Displays the payload in ASCII, allowing us to view the HTTP request and response text.
-nni: -i specifies the network interface (combined with -nn to prevent resolution of ports and IPs).
0.0: Captures traffic on all interfaces.
(tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420): Captures packets containing HTTP GET requests.
(tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450): Captures packets containing HTTP/ responses.
Start this command on the F5 BIG-IP CLI and execute the following curl command from the WebViewer:
curl -H “Connection: close” 192.168.110.102 -o /dev/null
Observation:
The client-side request contains the Connection: close header:
[root@jowxchdenoef:Active:Standalone] config # tcpdump -A -nni 0.0 ‘((tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420) or (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450))’
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:19:31.613509 IP 192.168.110.2.44176 > 192.168.110.102.80: Flags [P.], seq 3554201865:3554201962, ack 1834470153, win 502, options [nop,nop,TS val 1190694082 ecr 4178318620], length 97: HTTP: GET / HTTP/1.1 in slot1/tmm1 lis=/Common/oneForAll_vs port=1.1 trunk=
E…..@.@…..n…nf…P… mW. …..Q…..
F…….GET / HTTP/1.1
Host: 192.168.110.102
User-Agent: curl/8.5.0
Accept: */*
Connection: close
…..1…….)……../Common/oneForAll_vs..1.1..
The header is transformed into X-Cnection: close on the backend side:
plaintext
13:19:31.614115 IP 192.168.120.254.44176 > 192.168.120.2.80: Flags [P.], seq 844883950:844884047, ack 2940324378, win 14600, options [nop,nop,TS val 4178318621 ecr 4278475056], length 97: HTTP: GET / HTTP/1.1 out slot1/tmm1 lis=/Common/oneForAll_vs port=1.2 trunk=
E…..@….w..x…x….P2[…A….9.r……
……Y0GET / HTTP/1.1
Host: 192.168.110.102
User-Agent: curl/8.5.0
Accept: */*
X-Cnection: close
…..1…….)……../Common/oneForAll_vs..1.2..
Finally, the response to the client includes the Connection: close header, as expected:
13:19:31.621097 IP 192.168.110.102.80 > 192.168.110.2.44176: Flags [P.], seq 1:1521, ack 97, win 14697, options [nop,nop,TS val 4178318628 ecr 1190694082], length 1520: HTTP: HTTP/1.1 200 OK out slot1/tmm1 lis=/Common/oneForAll_vs port=1.1 trunk=
E..$..@….|..nf..n..P..mW. …j..9i…….
…$F…HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Mon, 04 Nov 2024 21:40:09 GMT
Content-Type: text/html
Content-Length: 2430
Last-Modified: Sun, 20 Oct 2024 14:43:43 GMT
Connection: close
ETag: “6715171f-97e”
Accept-Ranges: bytes
Set-Cookie: BIGipServeroneForAll_pool=41461952.20480.0000; path=/; Httponly
