In this lab, you will learn how to configure a virtual server and pool on the F5 BIG-IP platform to load balance web traffic. A virtual server acts as the entry point for incoming client requests, distributing the traffic across multiple pool members—backend servers hosting your web applications. This ensures that no single server is overwhelmed, enhancing both scalability and availability.
By the end of the lab, you will have a working setup that dynamically distributes web traffic, providing a seamless experience for users and ensuring high availability for the application.
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 : Create an HTTP pool with 3 pool members
- Web Server Red : 192.168.120.2
- Web Server Green : 192.168.120.3
- Web Server Blue : 192.168.120.4
The health-check should be the default http check.
Once created, check the status of the pool.
Is the pool available (green) ? Verify that all the 3 pool members are available
The pool is available (green) thanks to the health check. Going into the member section of the pool, we can verify that each pool member is available.
What kind of object is automaticaly created if you create pool member directly on the pool screen ? Verify that the said object is created.
When using the pool screen to create pool member, nodes are automaticaly created if not already present. In our case, no nodes were present, so upon the pool creation, nodes are created. We can verify the nodes created in the Local Traffic ›› Nodes screen
What are the status of the nodes ? Why ?
The nodes have the status unknown. Since the nodes were automaticaly created, no health check were attached to the nodes. This explain the unknown status. The unknown status still allow the F5 to send traffic to the node, while the unavailable status (that may have been put by a health-check) do not send new traffic to the node.
Task 2 : Create a Virtual Server
Create the virtual server “loadzilla_vs”, the virtual server should use the IP adress 192.168.110.100 and tcp port 80.
Attach to this virtual server the previously created pool.
What is the status of the virtual server ?
The virtual server inherit the status of its default pool. Since the pool is available, the virtual server shows as available. This can be verified with the green circle next to the virtual server in the virtual server list.
What kind of object is automaticaly created if you create a new virtual server ? Verify that the said object is created.
When you create a new virtual server on a new IP adress, an object type of Virtual Address is created. We can verify the creation of the virtual address in the Virtual Server >> Virtual Address List screen
Task 3 : Access the Virtual Server
Open the web viewer virtual machine.
Open the web browser and try accessing the virtual server http://192.168.110.100/
Do multiple hard-refresh (CTRL-SHIFT-R).
Which backend server is reponding to you ?
Doing multiple hard refreshes, the backend server changes.
Are the requests equaly shared between the backend server ? Explain why it is not perfectly the same amount on all servers.
Yes, the requests are almost equaly shared between the backend server. This is due to the default load balancing method used, the round-robin method.
This can be verified using the statistic view of the pool.
In this example, we can observe that all pool members have a similar number of connections. However, the blue pool member (192.168.120.4:80) has 2 fewer connections than the others. Why is that?
This is a more advanced topic, but to summarize: the F5 BIG-IP uses multiple TMM (Traffic Management Microkernel) instances, each making independent load-balancing decisions. The number of TMM processes depends on the number of CPU or vCPU cores available. As a result, slight variations in the number of requests across pool members can occur.
For example, if you have 4 requests and 4 TMM instances, there’s a chance that only 2 TMM instances will process the 4 requests, while the other 2 TMMs handle no traffic. This can result in small discrepancies in how connections are distributed among pool members.
F5’s article on Clustered Multiprocessing (CMP) explains how these TMM processes can sometimes cause minor load-balancing inconsistencies. This effect is most noticeable when traffic is low. However, in high-traffic production environments, requests are more evenly distributed across backend servers.
Now you can explain to customers why achieving perfectly balanced traffic across all servers is nearly impossible!
Conclusion
Congratulations! You’ve successfully created your very own virtual server and associated it with a pool of web servers. With this setup, you now have a foundational load balancing solution in place, ensuring that traffic is distributed evenly among your servers.
As you explored this process, you may have noticed that creating a pool or a virtual server also automatically generated related objects like nodes and virtual addresses.
However, keep in mind that load balancing can sometimes appear imperfect due to Clustered Multiprocessing (CMP).
