This topic describes how to add a UDP listener to a Classic Load Balancer (CLB) instance. UDP applies to services that prioritize real-time content delivery over reliability, such as video conferencing and real-time quote services. You can add a UDP listener to forward UDP packets.
A CLB instance is created. For more information, see Create a CLB instance.
- You cannot specify ports 250, 4789, or 4790 for UDP listeners. They are system reserved ports.
- Fragmentation is not supported.
- You cannot view source IP addresses by using the UDP listeners of a CLB instance in the classic network.
- The following operations take effect 5 minutes after they are performed on a UDP listener:
- Remove backend servers.
- Set the weight of a backend server to 0 after it is detected unhealthy.
- IPv6 packets have longer IP headers than IPv4 packets. When an IPv6 CLB instance uses a UDP listener, make sure that the following requirement is met: The
maximum transmission unit (MTU) supported by the network interface controller (NIC)
that each backend server uses to communicate with CLB does not exceed 1,200 bytes. Otherwise, oversized packets may be discarded. You must
modify the MTU setting in the configuration files of some applications accordingly.
TCP supports Maximum Segment Size (MSS) announcement. Therefore, when you use a TCP, HTTP, or HTTPS listener, you do not need to perform additional configurations.
Step 1: Configure a UDP listener
- Log on to the CLB console.
- In the top navigation bar, select the region where the CLB instance is deployed.
- Use one of the following methods to open the listener configuration wizard:
- On the Instances page, find the CLB instance and click Configure Listener in the Actions column.
- On the Instances page, find the CLB instance that you want to manage and click the ID of the instance. On the Listeners tab, click Add Listener.
- Set the following parameters and click Next.
Parameter Description Select Listener Protocol Select UDP. Listening Port Set the listening port that is used to receive requests and forward them to backend servers. Valid values: 1 to 65535.You can set a TCP or UDP listener to listen on all ports within a specified port range.Note This feature is available for only users in a whitelist. To use this feature, . Listener Name Specify a name for the listener. Advanced Click Modify to configure advanced settings. Scheduling Algorithm Select a scheduling algorithm.
- Weighted Round-Robin (WRR): Backend servers that have higher weights receive more requests than backend servers that have lower weights.
- Round-Robin (RR): Requests are distributed to backend servers in sequence.
- Consistent Hash (CH):
- Source IP: specifies consistent hashing that is based on source IP addresses. Requests from the same source IP address are distributed to the same backend server.
- Tuple: specifies consistent hashing that is based on four factors: source IP address, destination IP address, source port, and destination port. Requests that contain the same information based on the four factors are distributed to the same backend server.
- QUIC ID: specifies consistent hashing that is based on Quick UDP Internet Connections (QUIC)
IDs. Requests that contain the same QUIC ID are distributed to the same backend server.
Notice QUIC is implemented based on draft-ietf-quic-transport-10 and is rapidly evolving. Therefore, compatibility is not guaranteed for all QUIC versions. We recommend that you perform tests before you apply the protocol to a production environment.
Enable Session Persistence Specify whether to enable session persistence.
After session persistence is enabled, the listener forwards all requests from the same client to the same backend server.
Enable Access Control Specify whether to enable access control.
Select an access control method after you enable access control. Then, select an access control list (ACL) that is used as the whitelist or blacklist of the listener.Note IPv6 instances can be associated only with IPv6 ACLs, while IPv4 instances can be associated only with IPv4 ACLs. For more information, see Create an access control list.
Enable Connection Draining After connection draining is enabled, connections to backend servers can function as expected during the specified timeout period after the backend servers are removed or fail health checks.Note This feature is available for only users in a whitelist. To use this feature, . Enable Peak Bandwidth Limit
Specify whether to set a maximum bandwidth value for the listener.
If a CLB instance is billed based on bandwidth usage, you can set different maximum bandwidth values for different listeners. This limits the amount of traffic that flows through each listener. The sum of the maximum bandwidth values of all listeners that are added to a CLB instance cannot exceed the maximum bandwidth value of the CLB instance. By default, this feature is disabled and all listeners share the bandwidth of the CLB instance.Note If a CLB instance is billed based on data transfer, the bandwidth of its listeners is not limited by default.
Proxy Protocol Use the proxy protocol to pass client IP addresses to backend servers.Note You cannot enable this feature in scenarios where PrivateLink is used. Obtain Client Source IP Address Specify whether to reserve the real IP addresses of clients. Only Layer 4 listeners support this feature. By default, this feature is enabled.Note You cannot view source IP addresses by using the UDP listeners of a CLB instance in the classic network. To obtain source IP addresses, enable Proxy Protocol. Automatically Enable Listener After Creation Specify whether to immediately enable the listener after it is created. By default, this feature is enabled.
Step 2: Add backend servers
After you configure the listener, you must add backend servers to process client requests. You can use the default server group that is configured for the CLB instance. You can also configure a vServer group or a primary/secondary server group, or enable the primary/secondary mode for the listener. For more information, see Overview.
- On the Backend Servers wizard page, select whether to enable the primary/secondary mode.
A listener that has the primary/secondary mode enabled is associated with a primary server group and a secondary server group. Each server group contains one or more Elastic Compute Service (ECS) instances. A listener associated with a primary/secondary server group offers higher reliability than a listener associated with a primary server and a secondary server. Before you enable the primary/secondary mode for a listener, make sure that two vServer groups are created. For more information about how to create a vServer group, see Create a vServer group.
Parameter Description Primary Server Group Select a vServer group as the primary server group. The server group is used to receive requests. Secondary Server Group Select a vServer group as the secondary server group. When the number of unhealthy ECS instances in the primary server group reaches the failover threshold, user traffic is distributed to the secondary server group. Failover Policy Select a primary/secondary failover policy.
- Primary Server Group First: The primary server group is prioritized to receive requests. When the number of
unhealthy ECS instances drops below the failover threshold, the user traffic is distributed
to the primary server group again.
Failover Threshold: Set a threshold to trigger a primary/secondary failover.
- Manual Failover: If you select this policy, the primary server group and the secondary server group have the same weight. When the number of unhealthy ECS instances drops below the default threshold, the user traffic is still distributed to the secondary server group. If you want to distribute the user traffic to the primary server group, you must manually switch over the server group. The interval between two switchovers must not be less than 1 minute.
- Primary Server Group First: The primary server group is prioritized to receive requests. When the number of unhealthy ECS instances drops below the failover threshold, the user traffic is distributed to the primary server group again.
- If the primary/secondary mode is disabled, select the type of backend server to which
the listener forwards requests. In this example, Default Server Group is selected.
Select Default Server Group and click Add More.
- In the My Servers panel, select the ECS instances that you want to add as backend servers and click Next.
- On the Configure Ports and Weights wizard page, specify the weights of the backend servers that you want to add. A backend
server with a higher weight receives more requests. Note If the weight of a backend server is set to 0, no request is distributed to the backend server.
- Click Add. On the Default Server Group tab, specify the ports that you want to open on the
backend servers to receive requests. The backend servers are the ECS instances that
you selected. Valid values: 1 to 65535.
You can specify the same port on different backend servers that are added to a CLB instance.
- Click Next.
Step 3: Configure health checks
CLB performs health checks to check the availability of the ECS instances that serve as backend servers. The health check feature improves overall service availability and reduces the impact of backend server failures.
On the Health Check wizard page, click Modify to modify the health check configurations. For more information, see Configure health check.
Step 4: Submit the configurations
- On the Confirm wizard page, check the configurations. You can click Modify to modify the configurations.
- After you confirm the configurations, click Submit.
- When Successful appears, click OK.
After you configure the listener, you can view the listener on the Listener tab.