Gateway Load Balancer (GWLB) is ideal for deploying, extending, or managing third-party virtual network appliances (NVAs) in scenarios such as firewalls, intrusion detection, traffic mirroring, and deep packet inspection (DPI). GWLB runs in transparent mode at Layer 3 in the Open Systems Interconnection (OSI) reference model. Therefore, you must make preparations before you use GWLB to deploy NVAs. This topic describes how GWLB works and how to integrate NVAs with GWLB.
What is GWLB?
GWLB is a load balancer that works at Layer 3, also known as the network layer, in the OSI reference model. GWLB helps enterprise applications deploy, extend, and manage various types of third-party NVAs in scenarios such as firewalls, intrusion detection, traffic mirroring, and DPI. GWLB offers the following capabilities:
GWLB supports the deployment of multiple third-party NVAs.
GWLB provides more reliable deployment of third-party NVAs.
GWLB supports cross-zone availability of third-party NVAs.
GWLB can work with PrivateLink to maintain the availability of third-party NVAs across virtual private clouds (VPCs) and accounts.
GWLB is compatible with the software as a service (SaaS) services of third-party NVA providers.
How it works
Workflow
As shown in the following figure, a GWLB instance is connected to a GWLB endpoint of another VPC. GWLB endpoint is a special type of VPC endpoint. A GWLB instance can be connected to multiple GWLB endpoints.
The following table describes how a GWLB instance works.
No. | Description |
① | Network traffic from the client to the server is routed to a GWLB endpoint. |
② | The GWLB endpoint forwards the network traffic to the associated GWLB instance over PrivateLink. |
③ | The GWLB instance encapsulates the original packet by using GENEVE and forwards the traffic to a healthy NVA at the backend based on the traffic scheduling algorithm. The NVA identifies the traffic source based on information such as the 64-bit GWLB endpoint ID that is carried by GENEVE. |
④ | After the NVA processes the packet, it forwards the packet to the GWLB instance by using GENEVE. |
⑤ | The GWLB instance forwards the traffic to the corresponding GWLB endpoint over PrivateLink. |
⑥ | The GWLB endpoint queries a route based on the destination address and forwards the traffic to the destination server. |
Traffic scheduling methods
GWLB supports traffic scheduling based on the consistent hash algorithm of 5-tuple, 3-tuple, or 2-tuple packet. A 5-tuple packet contains the source IP address, destination IP address, protocol, source port, and destination port. A 3-tuple packet contains the source IP address, destination IP address, and protocol. A 2-tuple packet contains the source IP address and the destination IP address. GWLB routes traffic that have the same tuple to the same backend server.
General cases:
For traffic transmitted over TCP or UDP, you can select a hash algorithm based on 5-tuple packets.
For traffic transmitted over a protocol other than TCP and UDP, you can select a hash algorithm based on 3-tuple packets.
Health check mechanism
GWLB periodically performs health checks at specific intervals. GWLB sends TCP, HTTP, or HTTPS packets to a backend NVA, and checks whether the backend NVA is healthy based on the response of the backend NVA.
TCP: If GWLB can establish a TCP connection with a backend NVA, GWLB considers the backend NVA healthy.
HTTP or HTTPS: If the HTTP status code 2xx or 3xx is returned after GWLB sends an HTTP or HTTPS request to the backend NVA, GWLB considers the backend NVA healthy. Otherwise, GWLB considers the backend NVA unhealthy. GWLB does not perform hostname verification on the certificate that is passed in. Therefore, certificates, including self-signed certificates, can take effect as long as they are not expired.
Health check packets are not encapsulated by GENEVE.
If the NVA does not respond before the health check timeout period ends, the NVA fails health checks.
Integrate an NVA with GWLB
Integration method
GWLB communicates with backend NVAs over the GENEVE protocol. GWLB encapsulates the GENEVE type-length-value (TLV) in each packet to send additional information, such as GWLB endpoint ID and Flow Cookie, to the NVA. A GENEVE packet that is received by an NVA may contain one or more GENEVE TLVs.
GWLB endpoint ID: the 64-bit ID assigned to the GWLB endpoint. An NVA can use a GWLB endpoint ID to associate packets with its configurations. A GWLB endpoint ID is also used to determine the source of traffic.
Flow Cookie: the 32-bit random number that is generated for a flow when GWLB creates a flow entry in a flow table. Each flow has a unique cookie. The NVA must return the original cookie. When GWLB receives a packet from the NVA, GWLB forwards the packet only if the cookie in the packet matches the cookie assigned to the flow. If the cookie does not match the assigned cookie or no cookie exists, the packet is dropped.
The following process describes how an NVA responds to a request:
Encapsulate the original packet in a GENEVE header.
Exchange the source IP address and the destination IP address in the outer IPv4 header. The source IP address is the IP address of the NVA and the destination IP address is the IP address of GWLB.
Save the original port and do not exchange the source and destination ports in the outer IPv4 header.
Update the IP checksum in the outer IPv4 header.
Return all original fields in the GENEVE header.
Return all original TLVs in GENEVE Option, including GWLB endpoint ID and Flow Cookie.
GENEVE packet format
The following example shows the format of a GENEVE packet. For more information about GENEVE, see RFC 8926.
Outer IPv4 Header:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |Protocol=17 UDP| Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = xxxx | Dest Port = 6081 Geneve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer Geneve Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0|Opt Len = 8|O|C| Rsvd. | EtherType = 0x0800 or 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) = 0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer Geneve Options: Alibaba Cloud Gateway Load Balancer TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class = 0x0139 (Ali)| Type = 1 |R|R|R| Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 64-bit GWLB endpoint ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class = 0x0139 (Ali)| Type = 3 |R|R|R| Len = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Flow Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Customer payload follows...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Customer payload identified by EtherType in Geneve header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+