When a backend server is declared unhealthy by Gateway Load Balancer (GWLB) or removed from the server group associated with GWLB, new connection requests will be routed to the remaining healthy backend servers, but requests sent over exisiting connections are still forwarded to the unavailable backend server. This may cause packet losses. Enable the rebalance feature for the server group to route requests sent over existing connections to healthy backend servers.
Why is rebalance useful?
Rebalance feature in use | No | Yes |
Sample scenario |  |  |
How requests sent over existing connections are processed | Forwarded to the unavailable backend server, which may causes packet losses | Forwarded to healthy backend servers, which ensures the service continuity |
Key benefits of using the rebalance feature:
Seamless upgrade or maintenance of Network Virtual Appliances (NVAs) such as third-party firewalls
No need for special design in user application logic to handle service interruptions caused by NVA switchover
How rebalance works
When a backend server is declared unhealthy, or removed from the server group:
New connection requests will be routed directly to healthy backend servers.
Requests sent over existing connections are forwarded based on multiple factors:
Why the backend server is unavailable
Connection draining enabled
Rebalance enabled
Requests sent over existing connections forwarded to
The backend server fails health checks.
No impact on the results.
✅
Remaining healthy backend servers
❌
The unavailable backend server
The backend server is removed from the server group.
✅
✅
For the specified duration of the timeout: the unavailable backend server
After the timeout duration is reached: remaining healthy backend servers
✅
❌
The unavailable backend server
❌
✅
Remaining healthy backend servers
❌
❌
The unavailable backend server
Enable the rebalance feature
Console
Go to the GWLB console. On the Server Group page, when creating a server group, enable or disable Load Rebalancing (recommended) in the Advanced Settings section.
Alternatively, in the Modify Basic Information dialog box for an existing server group, enable or disable Load Rebalancing (recommended).
API
You can enable or disable the rebalance feature by setting the ServerFailoverMode parameter in the CreateServerGroup or UpdateServerGroupAttribute API.
Enumeration values for the ServerFailoverMode parameter:
NoRebalance (default)
Rebalance
To check whether the rebalance feature is enabled for server groups, call the ListServerGroups operation.
For traffic transmitted over stateful protocols, backend NVAs, such as firewalls, must be configured to work with the rebalance feature.
For example, for traffic transmitted via the TCP protocol, configure firewalls to allow establishing TCP sessions without receiving the initial SYN (Synchronize) segment.
Working principles:
TCP three-way handshakes: A three-way handshake is typically required to establish a TCP connection. This process includes the client sending a SYN segment, the server responding with an SYN-ACK (Synchronize-Acknowledge) segment, and the client sending an ACK (Acknowledge) segment.
If rebalance is enabled for GWLB, requests sent over existing connections may not be forwarded to the original backend NVA but to a new NVA. For a TCP session that has not completed a three-way handshake, requests are forwarded to a new NVA without the initial SYN segment. If backend NVAs do not support establishing TCP sessions in this case, the connection is interrupted. This is the reason why backend NVAs must be configured to allow establishing TCP sessions without the initial SYN segment.
Example configuration: For FortiGate firewalls, enable
tcp-session-without-synin the firewall policy. For more details, refer to the official documentation provided by your specific firewall vendor.