Help Center/ Anti-DDoS Service/ FAQs/ AAD FAQs/ Faults/ What Should I Do When Encountering an Access Freezing, Delay, or Failure?
Updated on 2024-07-03 GMT+08:00
View PDF
Share

What Should I Do When Encountering an Access Freezing, Delay, or Failure?

Symptom

Access from a client to the high-defense IP address is frozen, has long delays, or loses packets.

Troubleshooting

  • Cross-network access

    AAD supports CTCC, CUCC, CMCC, and BGP lines. Access delays and packet loss may occur if cross-network resolution is configured on DNS or cross-network back-to-origin is configured for origin server IP addresses on AAD.

    Solution:

    • On the DNS console: Check DNS configuration.

      This fault will not occur if you use the CNAME resolution provided by HUAWEI CLOUD. If you are using A record resolution, configure high-defense IP addresses based on the carrier of the line transmitting the access traffic. If your traffic is transmitted over the BGP line, retain the default high-defense IP address configuration. Huawei Cloud is not responsible for the packet loss or delays caused by improper DNS configuration.

    • On the AAD console: Check the origin server IP address.

      If the origin server uses a specific carrier line, packet loss and delays exist inevitably during cross-network access, and HUAWEI CLOUD is not responsible for the packet loss and delays.

      If the origin server uses lines of multiple carriers, add origin server IP addresses accordingly based on the high-defense IP addresses of the carrier lines, for example, associate a CTCC high-defense IP address with a CTCC origin server IP address. Huawei Cloud is not responsible for the packet loss or delays caused by improper back-to-origin line configuration.

  • Backend server exceptions

    Troubleshoot the fault based on the origin server type configured for the high-defense IP address.

    • The origin server is a load balancer.

      To resolve the problem, perform the following steps:

      1. Run TCPing using the IP address and port number of the load balancer to locate the fault.
      2. Check the load balancer status (such as number of connections and backend servers).
      3. Check whether blacklists, whitelists, or other access control policies have been configured for the load balancer and ensure that the back-to-origin IP address range is allowed through.
      4. Check backend servers and networks of the load balancer for any IP address blocking policies on firewalls.
    • The origin server is a cloud server.

      To resolve the problem, perform the following steps:

      1. Run TCPing using the IP address and port number of the cloud server to locate the fault.
      2. Check whether the server has encountered exceptions, such as black holes, scrubbing incidents, high CPU usage, slow database requests, and outbound bandwidth exhaustion.
      3. Check whether blacklists, whitelists, or other access control policies have been configured for the cloud server and ensure that the back-to-origin IP address range is allowed through.
      4. Check the cloud server or networks for security software or IP address blocking policies that block the back-to-origin IP addresses.
  • Whether high-defense IP addresses have scrubbing incidents
    • High-defense IP addresses have experienced scrubbing incidents.

      To resolve the problem, perform the following steps:

      1. Run TCPing to check for and record delays and packet loss on attacked ports.
      2. Run TCPing to check for and record delays and packet loss on non-attacked ports.

      Locate the fault by checking the records against the following table.

      Table 1 Results

      Delay and Packet Loss on Attacked Ports

      Delay and Packet Loss on Non-attacked Ports

      Cause Analysis

      Yes

      No

      The scrubbing policy is executed properly on attack traffic. Check the backend server status and identify the server's attack defense capability. If the attack defense capability is weak, you need to enforce a powerful defense policy.

      Yes

      Yes

      Normal traffic is scrubbed by the scrubbing policy. You can submit a service ticket for background troubleshooting.

      No

      No

      The fault is not caused by the scrubbing policy.

      No

      Yes

      Generally, this situation does not exist.

      In the first two cases, you are advised to submit a service ticket. To enforce a more powerful defense policy, you need to provide details about your server's attack defense performance, including:

      • Normal user access
      • Service interaction processes
      • Application service capabilities
    • High-defense IP addresses have not experienced scrubbing incidents.

      The fault is not caused by attacks.

  • High-defense IP addresses are blocked by black holes.

    The high-defense IP address is blocked by a black hole if the attack traffic towards this IP address exceeds the configured elastic protection bandwidth. You can check whether packet loss is caused by a black hole.

    If so, you are advised to purchase a large elastic protection bandwidth and adjust your service systems to make them capable of switching traffic to another line when a black hole is triggered.

Parent topic: Faults