For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

ping-t's avatar
ping-t
Icon for Altostratus rankAltostratus
Aug 26, 2025

Round-robin method not load balanced

I have configured BIG-IP 1600 to distribute the load to two servers in a round-robin fashion, but only one of them is communicating and the load is not distributed.
We have confirmed that all Pool Nodes for load balancing are green, but we would like to know the cause of the problem.
Persistence does not seem to be set.

11 Replies

  • Hi,

    After ensuring that the server is up and running, as mentioned above in the comments (using a curl command or by applying an advanced monitor), the next step is to check whether any persistence method is applied at the F5 virtual server level.

    In some cases, a persistence method such as Source Address Affinity might be configured. If users are connecting through a proxy, the F5 device may only see a single source IP address accessing the service. As a result, due to the persistence configuration, all traffic could be directed to a single backend server instead of being distributed across the pool members.

  • vserver fallback persistence is by default set to source address.

    there are many probable causes of the imbalance.
    vserver config must match app characteristics to get correct load balancing.

  • You can give this a shot. Think this might work:

    1. Enable SNAT Automap on the virtual server and retest connectivity.
    2. Validate real-server routing to force replies via the BIG-IP (use traceroute).
    3. Confirm VLAN/subnet assignments and Self IP coverage for all pool member subnets.
    4. Tighten health monitors to verify full application functionality, not just TCP.
    5. Capture and review packets on both BIG-IP and real servers to trace asymmetric drops.

    By systematically addressing SNAT and asymmetric routing first—and then verifying VLAN, health-monitor, and firewall settings—you can restore true round-robin distribution across both servers.

    • ping-t's avatar
      ping-t
      Icon for Altostratus rankAltostratus

      For the first, SNAT Automap is enabled on the virtual server.

      • Hi ,

         

        Both of the servers are in same VLAN? also i hope you have enabled layer7 monitor in both servers(ping or tcp will make server up if service down.).  also for fix you can try

        • Enable SNAT Automap on the Virtual Server (for quick test), or
        • Configure a proper return route on both servers pointing back to the F5 Self IP.
  • Typically when this happens it is most likely because the volume of traffic hitting your virtual server is not sufficient to show an traffic being sent to all the pool members. I recommend increasing the volume of traffic that you use to test the virtual server as well as the duration of the test.

  • This is often a common misunderstanding of how round robin works in F5. 

    It's TMM handle the round robin independently 

    So if for example you have 4 TMMs, first 4 requests might most probably forwarded to server1, one request from each TMM.

    Try disabling server1 and check if traffic is forwarded to server2. Or simulate a lot of requests and check statistics.

    • ping-t's avatar
      ping-t
      Icon for Altostratus rankAltostratus

      I disabled server1, but could not communicate to server2, and I got a connection error on the source server sending to VIP.

      • Paulius's avatar
        Paulius
        Icon for MVP rankMVP

        Seems to me like server2 isn't configured correctly to receive the traffic. You can run a tcpdump to see what's happening with the traffic that's being sent to it. I'm in agreement with Injeyan_Kostas that we would need to know what the health monitor is because the server could be passing a basic healthcheck that verifies a port is listening but nothing at an application level that would mean the server is responding with content.