Fault-related questions

Will BCC instance anomalies affect BLB service?

BLB actively monitors the health of backend BCC instances. If an instance encounters problems, BLB will redirect new requests to other healthy BCC instances. As long as one functional BCC instance remains, the service stays operational.

How to do if health check status remains abnormal?

1. Ensure that there is a process/service listening on the health check port of the cloud host. a) Verify whether the BCC instances are functioning properly; b) Verify whether the service deployed on the BCC instances is normal and confirm that there is a process or service listening on the health check port. By default, the health check port for TCP listeners are the same as the backend service port.
2. Ensure correct configuration of security group policies for cloud hosts. Refer to [Real Server Security Group Settings ](BLB/Operation guide/General-purpose BLB instance/Creating BLB Ordinary Instance.md#Set security group for real servers)for details.

You can manually request the cloud host's port to confirm normal accessibility.

• If using TCP health checks, you can use the telnet/nmap command to attempt to establish a TCP connection with the port, eg. nmap ipaddress –p port;
• If using HTTP health checks, you can use the curl command to ensure that the returned HTTP status code is 2XX or 3XX, eg. curl –I ipaddress:port.

4. If the backend member is an IP address, it shall be within the same VPC as the application BLB instance.

When the forwarding rule is source IP, is loopback prevention supported?

The load balancer allows a single BCC to act as both a client and a server. In such cases, the Client IP and Server IP seen by BLB are identical. Keep in mind that source IP forwarding rules do not prevent loopback. To avoid loopbacks, you can choose weighted round-robin or weighted least-connections forwarding rules.

How to do if network connectivity fails when accessing load balancer TCP/UDP/ICMP protocols via IP shard?

BLB currently does not support forwarding of fragmented messages; fragmented messages will be discarded after reaching the load balancer. Therefore, when using TCP\UDP for communication, the entire packet size from the client and server shall be strictly controlled to ensure it does not exceed the default MTU (1500 bytes). When UDP service messages are fragmented, common symptoms include service unavailability. When TCP service messages are fragmented, common symptoms include: small messages (such as TCP three-way handshake and four-way wavehand) are transmitted normally, but large messages (such as service request and response) are dropped, causing retransmission and connection failure. Solution: Reduce message size between the client and server to prevent packet fragmentation and ensure the packet size is no more than 1500 bytes.

Why can't client access the load balancer?

The real server configured for Layer-4 listeners does not support acting as both client and server by default. Check whether the client and server are running on the same server . In case of health check anomalies, check whether the RS health check is normal . Check whether the backend service is normal, listeners are functional, and client can directly access RS services normally. Verify whether firewall policies exist on the backend service and whether the service port and client IP access permissions are granted. Verify whether the corresponding client IP and port access permissions are granted for the access control list and security group.