Server Load Balancer:Overview of GWLB instances

Instance status

The following table describes the different states of a GWLB instance and whether specific operations are supported in each state.

IP version

GWLB instances support the IPv4 protocol version, which means GWLB supports IPv4 traffic access.

A GWLB instance communicates with backend servers using a private IPv4 address, which is assigned by the subnet where the GWLB instance resides.

Cross-zone forwarding

By default, cross-zone forwarding is enabled. When a GWLB instance receives client traffic, each GWLB instance distributes the traffic among backend servers in all enabled zones within the same region. Currently, the cross-zone forwarding feature cannot be disabled.

Network MTU

The maximum transmission unit (MTU) of a network connection is the size of the largest packet that can be transmitted over the connection. An MTU includes the size of IP headers and payload but excludes the size of Ethernet headers.

• GWLB MTU limit:

  The maximum packet size supported by GWLB is 1500 bytes. Therefore, any packet exceeding 1500 bytes will be discarded and not transmitted.

• MTU settings for network virtual devices:

  When a GWLB instance encapsulates IP traffic with a Geneve header to forward it to a network virtual device, it adds 68 bytes to the original packet. It is recommended to set the MTU of the network virtual device to at least 1568 bytes (1500 bytes for the original packet size plus 68 bytes for the Geneve header encapsulation) to ensure it can handle packets up to 1500 bytes.

• IP fragmentation:

  GWLB does not support IP fragmentation. If the original packet size exceeds 1500 bytes, it cannot be fragmented into smaller segments for transmission.

• Path MTU Discovery (PMTUD):

  GWLB does not generate ICMP messages to indicate fragmentation is needed, so PMTUD is not supported.

Idle connection timeout period

The connection idle timeout is the maximum duration that a network connection can remain idle without data transmission. If no connection requests occur within the idle timeout period, the current connection is closed, and the GWLB instance routes new traffic to a new backend server. Existing traffic is discarded until a new connection is established upon the next request.

• For TCP traffic, the connection idle timeout is 350 seconds.

• For non-TCP traffic, the connection idle timeout is 120 seconds.

Traffic processing mode

By default, the traffic processing mode for a GWLB instance is Load balancing, which means that when GWLB receives traffic from the GWLB endpoint, it forwards the traffic to backend servers for processing.

During network emergencies, network issue diagnostics, or Network Virtual Appliance (NVA) upgrade and maintenance, when the backend NVAs associated with GWLB are unavailable, you can change the traffic processing mode for GWLB to Bypass. In this mode, when GWLB receives traffic from the GWLB endpoint, the traffic is directly returned to the GWLB endpoint without being forwarded to backend NVAs, ensuring that your services are not interrupted.

Bypass mode

Traffic processing mode	Load balancing	Bypass
GWLB behavior	When GWLB receives traffic from the GWLB endpoint, it forwards the traffic to backend servers for processing.	When GWLB receives traffic from the GWLB endpoint, the traffic is directly returned to the GWLB endpoint without being forwarded to backend servers.
Networking diagram
Use scenarios	Default mode. In this mode, third-party firewalls process business traffic properly.	Mainly used during network and third-party firewall maintenance. Emergencies: When business traffic exceeds the processing capacity of the third-party firewall cluster in the server group, there is a risk of service interruption. In this case, you can switch GWLB to bypass mode to ensure that your services are not interrupted. After the firewall cluster is scaled out, switch back to load balancing mode. Issue diagnostics: When diagnosing networking issues for your system, you can switch GWLB to bypass mode to check whether firewalls are working as expected. NVA upgrade and maintenance: When third-party firewalls require upgrades or maintenance, such as image upgrades, you can switch GWLB to bypass mode. Then, you can upgrade the firewall image without interrupting the system network.
Remarks	-	Billing: In bypass mode, GWLB is still working to forward requests, so LCU fees are still billed. Health checks: In bypass mode, GWLB health checks are still performed properly.

Console

In the GWLB console, on the instance details page, click Modify corresponding to Traffic Processing Mode and switch the traffic processing mode.

API

You can switch the traffic processing mode for GWLB by setting the TrafficMode parameter in the UpdateLoadBalancerAttribute API.

Enumeration values for the TrafficMode parameter:

• LoadBalance (default)

• ByPass

To query the current traffic processing mode for GWLB, see:

• ListLoadBalancers

• GetLoadBalancerAttribute

Warning

• Before you switch GWLB to bypass mode, ensure you understand and accept the risks caused by backend NVAs not working.

• Before you switch GWLB to load balancing mode, if business traffic is transmitted over stateful protocols, you must configure backend NVAs (such as firewalls) to work with GWLB to prevent existing connections from being interrupted.

  • 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.

    • When GWLB is in bypass mode, requests are directly forwarded to the service application by GWLB. On the contrary, in load balancing mode, GWLB forwards requests to the backend NVAs for filtering before forwarding them to the service application. In this case, if the backend NVAs require SYN segments to establish or identify a connection, when packets transmitted over existing connections reach the NVAs, their session states cannot be identified. This causes the connections to interrupt but does not affect new connections. If you want to ensure that the existing connections are not interrupted, you must enable TCP sessions without SYN segments on the NVAs.

  • Example configuration: For FortiGate firewalls, enable tcp-session-without-syn in the firewall policy. For more details, refer to the official documentation provided by your specific firewall vendor.

References

Create and manage a GWLB instance