Host fault detection method and device, computer equipment, medium and program product

Abstract

The invention relates to a host fault detection method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: acquiring a network data packet connected with a gateway through a layer 2, and analyzing a source address and a destination address of the network data packet; determining the transmission direction of the network data packet according to the source address and the destination address, and updating the flow marking states corresponding to the source address and the destination address in the address resolution protocol table item according to the transmission direction; under the condition that the detection moment arrives, selecting a to-be-detected host according to each flow mark state in the address resolution protocol table item; and sending an address resolution protocol request for each to-be-detected host, determining a fault detection result of the to-be-detected host according to a response condition of the address resolution protocol request, and updating the address resolution protocol table item according to the fault detection result. By adopting the method, the utilization rate of network bandwidth resources can be improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing and communication technology, and in particular to a host fault detection method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] A Layer 2 Gateway (L2GW) is a network device that provides Layer 2 interconnection within a Virtual Private Cloud (VPC). It is used to establish virtual tunnels based on Virtual Private Networks (VPNs) or Direct Connect Cloud Lines (DCs) to enable interoperability between Layer 2 networks on and off the cloud.

[0003] In related technologies, L2GW mainly uses two methods to detect host faults: the first is the ARP aging detection method, which means that when the ARP aging time is reached, ARP detection is performed regardless of whether there is traffic; the second is a combination of traffic and ARP aging detection, which means that when the ARP aging time is reached, if there is traffic that hits the corresponding ARP entry, no detection is performed, otherwise ARP detection is performed.

[0004] However, the first method generates a large number of unnecessary ARP packets by periodically initiating probes without checking traffic conditions, increasing the risk of ARP storms and network loops, while also consuming network bandwidth. The second method, while avoiding probes when traffic is present, fails to detect host failures in a timely manner when traffic continues to transmit, causing the faulty traffic to continue circulating in the network and putting continuous pressure on network and bandwidth. Summary of the Invention

[0005] Therefore, it is necessary to provide a host fault detection method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the utilization rate of network bandwidth resources, in order to address the above-mentioned technical problems.

[0006] Firstly, this application provides a host failure detection method, including:

[0007] Obtain network packets passing through the Layer 2 connection gateway, and parse the source and destination addresses of the network packets;

[0008] The transmission direction of the network data packet is determined based on the source address and the destination address, and the traffic tag status corresponding to the source address and the destination address in the Address Resolution Protocol (ARP) entry is updated based on the transmission direction.

[0009] When the detection time arrives, the host to be detected is selected according to the traffic marker status in the Address Resolution Protocol (ARP) table entry;

[0010] For each host to be detected, an Address Resolution Protocol (ARP) request is sent. The fault detection result of the host to be detected is determined based on the response to the ARP request, and the ARP entry is updated based on the fault detection result.

[0011] In one embodiment, the step of sending an Address Resolution Protocol (ARP) request for each of the hosts to be detected, and determining the fault detection result of the host to be detected based on the response to the ARP request, includes:

[0012] Get the preset number of probes and the timeout duration for each probe;

[0013] For each host to be detected, the detection counter is initialized according to the preset number of detections, an address resolution protocol request is sent, and timing is started to obtain timing data;

[0014] If the timing data exceeds the single timeout duration and no response is received, the value of the probe counter is decremented by 1, and the steps of sending the address resolution protocol request and starting timing to obtain timing data are repeated until the value of the probe counter is 0. If the value of the probe counter is 0, it is determined that the host under test has malfunctioned.

[0015] In one embodiment, the step of sending an Address Resolution Protocol request and starting timing to obtain timing data includes:

[0016] If the value of the probe counter is greater than 1, an address resolution protocol request is sent by unicast and timing is started to obtain timing data;

[0017] When the value of the probe counter is equal to 1, an address resolution protocol request is sent by broadcast and timing is started to obtain timing data.

[0018] In one embodiment, the step of sending an Address Resolution Protocol request and starting timing to obtain timing data using unicast includes:

[0019] Extract the access control address corresponding to the host to be detected from the address resolution protocol entry;

[0020] Generate a unicast address resolution protocol request message based on the address of the host to be detected and the access control address;

[0021] The Layer 2 connection gateway sends a unicast address resolution protocol request message to the host under test and starts timing to obtain timing data.

[0022] In one embodiment, the step of sending an Address Resolution Protocol request and starting timing to obtain timing data via broadcast includes:

[0023] Based on the address of the host to be detected and the network segment address where the Layer 2 connection gateway is located, a broadcast address resolution protocol request message is generated;

[0024] The Layer 2 connection gateway broadcasts the Broadcast Address Resolution Protocol (BRP) request message within the network segment and starts timing to obtain timing data.

[0025] In one embodiment, the transmission direction includes uplink traffic and downlink traffic; determining the transmission direction of the network data packet based on the source address and the destination address includes:

[0026] The source address is matched with the virtual private cloud network segment identifier and the on-premises network segment identifier to obtain the network segment affiliation of the source address;

[0027] The destination address is matched with the virtual private cloud network segment identifier and the on-premises network segment identifier to obtain the destination address network segment affiliation.

[0028] If the source address network segment belongs to the virtual private cloud network segment in the cloud and the destination address network segment belongs to the on-premises network segment, the transmission direction is determined to be uplink traffic.

[0029] If the source address network segment belongs to the on-premises network segment and the destination address network segment belongs to the on-premises virtual private cloud network segment, the transmission direction is determined to be downlink traffic.

[0030] Secondly, this application also provides a host fault detection device, comprising:

[0031] The data acquisition module is used to acquire network data packets passing through the Layer 2 connection gateway and parse the source and destination addresses of the network data packets;

[0032] The data update module is used to determine the transmission direction of the network data packet based on the source address and the destination address, and update the traffic marker status corresponding to the source address and the destination address in the Address Resolution Protocol (ARP) entry based on the transmission direction.

[0033] The data selection module is used to select the host to be detected based on the traffic marker status in the Address Resolution Protocol (ARP) table when the detection time arrives.

[0034] The fault detection module is used to send an Address Resolution Protocol (ARP) request to each of the hosts to be detected, determine the fault detection result of the host to be detected based on the response to the ARP request, and update the ARP entry based on the fault detection result.

[0035] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps described in the first aspect.

[0036] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps described in the first aspect.

[0037] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps described in the first aspect.

[0038] The aforementioned host fault detection methods, devices, computer equipment, computer-readable storage media, and computer program products, by acquiring network data packets passing through a Layer 2 gateway and resolving the source and destination addresses of these packets, can monitor data flow in the network in real time. This enables the system to make intelligent decisions based on actual network traffic conditions, rather than blindly probing at fixed time intervals. It determines the transmission direction of network data packets based on the source and destination addresses and updates the traffic marker status corresponding to the source and destination addresses in the Address Resolution Protocol (ARP) entries accordingly. This ensures that the active state of the host, whether initiating or receiving communication, is accurately recorded, solving the problem of relying on a single dimension for judgment in traditional solutions. To address the potential for misjudgment due to host status issues, when the detection time arrives, the host to be detected is selected based on the status of each traffic marker in the Address Resolution Protocol (ARP) table. The selective probing mechanism directly solves the problem of wasted network bandwidth resources caused by indiscriminate probing in traditional schemes, significantly reducing unnecessary probe traffic in the network. An ARP request is sent to each host to be detected, and the fault detection result of the host is determined based on the response to the ARP request. The ARP table entry is then updated based on the fault detection result, ensuring that only hosts that may actually be faulty are probed and verified. When a host does indeed malfunction, it can be detected and the table entry updated promptly, avoiding the continuous transmission of faulty traffic and improving network bandwidth resource utilization. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 This is an application environment diagram of a host fault detection method in one embodiment;

[0041] Figure 2 This is a flowchart illustrating a host fault detection method in one embodiment;

[0042] Figure 3 Here is an example diagram of a traffic labeling implementation scheme in one embodiment;

[0043] Figure 4 This is a schematic diagram of the flow marking results in one embodiment;

[0044] Figure 5 This is a flowchart illustrating step S204 of the host fault detection method in one embodiment;

[0045] Figure 6 This is a structural block diagram of a host fault detection device in one embodiment;

[0046] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0048] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0049] The host fault detection method provided in this application embodiment can be applied to, for example, Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located on the cloud or other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0050] In one exemplary embodiment, such as Figure 2 As shown, a host fault detection method is provided, which is applied to... Figure 1 Taking server 104 as an example, server 104 can be deployed on a Layer 2 connection gateway, including the following steps S202 to S208. Wherein:

[0051] Step S202: Obtain network data packets passing through the Layer 2 connection gateway, and parse the source and destination addresses of the network data packets.

[0052] In a network data packet, the data unit transmitted in the network can contain complete protocol header information and payload data, such as Ethernet frames, IP packets, TCP segments, and other packet formats at different levels. The source address is the address information in the network data packet that identifies the sender; it can be a MAC address (Media Access Control address) or an IP address (Internet Protocol address). The destination address is the address information in the network data packet that identifies the receiver; it can also be a MAC address or an IP address.

[0053] For example, server 104 can establish a network packet capture task, deploying a packet listener on the network interface of the Layer 2 connection gateway to achieve real-time network traffic monitoring. Server 104 can be configured with a packet capture program capable of listening to all incoming and outgoing traffic passing through the Layer 2 connection gateway, which may include uplink packets from cloud VPC network segments and downlink packets from on-premises IDC (Internet Data Center) network segments. Server 104 can set packet filtering rules to focus on capturing packets containing ARP (Address Resolution Protocol) information and packets carrying business traffic, while filtering out system management traffic and other non-packet traffic to improve processing efficiency.

[0054] After capturing network packets, server 104 can parse the Ethernet frame header of the packets, extracting the source MAC address and destination MAC address fields to identify the hardware addresses of the sending and receiving devices. Server 104 can also extract the source IP address and destination IP address fields, and record additional information such as the packet's timestamp, packet size, and protocol type. During the parsing process, server 104 can build a packet information table to record information such as the source address, destination address, transmission time, and packet type of each packet. Server 104 can identify and discard packets with abnormal formats or corruption to ensure the quality of data processed subsequently. Furthermore, server 104 can establish packet statistics, providing real-time statistics on the number of packets, traffic volume, and protocol distribution passing through the Layer 2 connection gateway.

[0055] In some embodiments, server 104 may employ a hardware-accelerated packet processing method. Server 104 can utilize the hardware offload function of the network interface card (NIC) to offload the basic packet parsing work to the hardware level, reducing the processing burden on the CPU (Central Processing Unit). Server 104 may be configured with a dedicated packet processing engine capable of processing multiple packet streams in parallel, improving packet processing throughput through multi-threading or multi-processing. Server 104 may establish a packet cache to store parsed packet information in a high-speed cache.

[0056] For example, such as Figure 3As shown, the network packets that server 104 can handle mainly involve Layer 2 interconnection traffic between the cloud and on-premises environments. When host vm1 (address 1.1.1.1) in the cloud VPC sends a data packet to host vm2 (address 1.1.1.2) in the on-premises IDC, server 104 can capture the data packet and resolve the source IP address to 1.1.1.1 and the destination IP address to 1.1.1.2. Server 104 can extract the source MAC address from the data packet, which corresponds to the network interface hardware address of host vm1 in the cloud, and the destination MAC address, which can be the MAC address of the Layer 2 connection gateway or the MAC address of host vm2 in the on-premises environment after address learning. When host vm3 (address 1.1.1.3) in the on-premises IDC sends a data packet to host vm1 in the cloud, server 104 can capture and parse the data packet, extracting the source IP address to 1.1.1.3 and the destination IP address to 1.1.1.1.

[0057] Step S204: Determine the transmission direction of the network data packet based on the source address and destination address, and update the traffic tag status corresponding to the source address and destination address in the Address Resolution Protocol (ARP) entry according to the transmission direction.

[0058] The transmission direction refers to the flow direction of network data packets in the cloud and on-premises network environments. Specifically, it can include two types: uplink traffic and downlink traffic. Uplink traffic refers to the data flow transmitted from the cloud VPC network segment to the on-premises IDC network segment, while downlink traffic refers to the data flow transmitted from the on-premises IDC network segment to the cloud VPC network segment.

[0059] The Address Resolution Protocol (ARP) entry refers to a data structure stored in the Layer 2 connectivity gateway used to maintain the mapping relationship between network layer addresses and data link layer addresses. Each entry can contain basic fields such as IP address, MAC address, interface information, and aging time. Traffic tagging status refers to an additional identifier field added to each ARP entry to record the host's active status, including uplink and downlink traffic tags. A value of 1 indicates an active state, and a value of 0 indicates an inactive state.

[0060] For example, server 104 can distinguish between cloud-based VPC network segments and on-premises IDC network segments using pre-configured network topology information. Server 104 can maintain a network segment configuration table, which records information such as the network address range, subnet mask, and gateway address of cloud-based VPCs, as well as parameters such as the network address range, tunnel interface information, and peer gateway address of on-premises IDCs. Server 104 can match the source IP address with the network segment configuration table to determine the network segment type of the source address, and simultaneously match the destination IP address with the configuration table to determine the network segment type of the destination address. When the source IP address belongs to the cloud-based VPC network segment and the destination IP address belongs to the on-premises IDC network segment, server 104 can determine that the data packet transmission direction is uplink traffic; when the source IP address belongs to the on-premises IDC network segment and the destination IP address belongs to the cloud-based VPC network segment, server 104 can determine that the data packet transmission direction is downlink traffic.

[0061] After determining the transmission direction, server 104 can search the existing ARP table for an entry matching the source IP address. If a matching entry is found, its current traffic label status is obtained; otherwise, a new ARP entry is created and its traffic label status is initialized to inactive. Server 104 can also search the ARP table for an entry matching the destination IP address, performing the same lookup or creation operation. Server 104 can update the corresponding traffic label according to the determined transmission direction. When the transmission direction is uplink, the uplink traffic label of the ARP entries corresponding to both the source and destination IP addresses is set to active; when the transmission direction is downlink, the downlink traffic label of the ARP entries corresponding to both the source and destination IP addresses is set to active.

[0062] While updating the traffic tagging status, server 104 can also record detailed timestamp information to support subsequent activity analysis. Server 104 can record the last active time for each updated ARP entry, with the timestamp identifying the moment the host last participated in network communication. Server 104 can establish a traffic tagging history record mechanism to save the activity status changes of each host within different time windows.

[0063] For example, server 104 can perform transmission direction determination and traffic tag update operations when processing communication traffic between cloud and on-premises hosts. When cloud host vm1 (address 1.1.1.1) sends a data packet to on-premises host vm2 (address 1.1.1.2), server 104 can match the source IP address 1.1.1.1 with the pre-configured cloud VPC network segment to confirm that it belongs to the cloud network segment, and then match the destination IP address 1.1.1.2 with the on-premises IDC network segment to confirm that it belongs to the on-premises network segment, thereby determining that the transmission direction of the data packet is uplink traffic. Server 104 can then look up the entry for IP address 1.1.1.1 in the ARP table and set its uplink traffic tag to 1, and at the same time look up the entry for IP address 1.1.1.2 and set its uplink traffic tag to 1 as well. In this way, the active status tags of both communicating parties can be updated simultaneously through the processing of a single data packet. When on-premises host VM2 sends a response packet to cloud host VM1, server 104 can perform the reverse judgment process to determine that the transmission direction is downlink traffic and set the downlink traffic flag of the corresponding ARP entry to 1. When on-premises host VM3 (address 1.1.1.3) communicates with cloud host VM1, server 104 can similarly determine the transmission direction based on the network segment affiliation of the source and destination addresses and update the corresponding traffic flag status to ensure that the active status of all hosts participating in the communication can be accurately recorded.

[0064] Step S206: When the detection time arrives, select the host to be detected according to the status of each traffic marker in the Address Resolution Protocol (ARP) table.

[0065] The detection time refers to the point in time when the preset detection period (Detecinterval) arrives. This point in time triggers the system to perform activity assessment and probe decisions on all ARP entries. The detection period can range from 10 seconds to 300 seconds and can be adjusted according to network environment and performance requirements. The host to be detected refers to host devices identified as potentially faulty through traffic labeling state analysis. These hosts do not exhibit sufficient network activity within the current detection period and require active probes to verify their actual operational status. Traffic labeling state assessment is used to determine the activity level of the corresponding host within the detection period.

[0066] For example, server 104 can monitor the arrival of the detection period through a system timer, configure a detection period timer that periodically generates a trigger signal according to a preset Detecinterval time interval, and send a notification to the main control program when the timer expires. After receiving the notification that the detection time has arrived, server 104 can start an ARP entry traversal program, thereby accessing all valid entries in the ARP table one by one in a predetermined order. Server 104 can perform a traffic tag status read operation for each ARP entry to obtain the current values ​​of its uplink and downlink traffic tags, and can also read the last active timestamp and other relevant status information of the entry.

[0067] After reading the traffic marker status, such as Figure 4 As shown, server 104 can execute a host activity assessment algorithm to determine the activity status of each host. Server 104 can check the uplink and downlink traffic flags of ARP entries. When either flag is 1, it indicates that the host has participated in network communication during the current detection period, and server 104 classifies it as an active host. Server 104 can perform a traffic flag reset operation for entries classified as active hosts, setting both the uplink and downlink traffic flags to 0. Server 104 can simultaneously update the aging time of the ARP entries corresponding to active hosts, calculating a new aging time value based on the detection period to ensure that ARP entries for active hosts are not mistakenly deleted due to aging.

[0068] For ARP entries where both the uplink and downlink traffic markers are 0, server 104 can perform further activity verification. Server 104 can calculate the time difference between the current time and the last active timestamp of the ARP entry. When the time difference is less than the detection period and there is a recent traffic activity record, server 104 can consider it an active host and perform the corresponding reset operation. When the time difference is found to be greater than or equal to the detection period, or the traffic marker status clearly indicates no activity, server 104 can classify the corresponding host as a suspected faulty host and add it to the list of hosts to be detected.

[0069] Furthermore, server 104 can assign priority weights to each host to be detected based on factors such as the host's last active time, historical fault records, and network location. Hosts with higher priority can be probed first. Server 104 can implement probe load control; when the number of hosts to be detected exceeds the system's processing capacity, it can select some hosts for probes according to priority, while the remaining hosts are delayed until the next detection cycle. Server 104 can establish active host statistics records, including the number, distribution, and network segment affiliation of active hosts within the current detection cycle.

[0070] In some embodiments, server 104 may also employ an intelligent activity assessment method based on historical behavior patterns. Server 104 can establish a host behavior pattern learning module to build a personalized activity assessment model by analyzing the activity change patterns of each host within historical detection periods. Server 104 can employ a sliding time window mechanism, considering not only the traffic marking status within the current detection period but also comprehensively analyzing the activity trends of previous detection periods to improve the accuracy of fault diagnosis. Server 104 can implement network topology-based correlation analysis; when multiple hosts within a network segment simultaneously display an inactive state, the connectivity of the network infrastructure is checked first to avoid misjudging network faults as host faults. Server 104 can also establish an adaptive detection period adjustment mechanism, dynamically adjusting the Detecinterval parameter according to network load and historical fault frequency, extending the detection period under high load to reduce the detection frequency, and shortening the detection period during periods of high fault incidence to improve detection sensitivity.

[0071] For example, server 104 can comprehensively evaluate the traffic marking status of each host in the cloud and on-premises when the detection time arrives. Assuming the current detection period is 60 seconds, when the timer triggers the detection time, server 104 can first check the ARP entry of the cloud host vm1 (address 1.1.1.1). If it finds that its uplink traffic marking is 1 and its downlink traffic marking is 1, it indicates that the host has both sent and received data packets in the current period. Server 104 can classify it as an active host and reset both traffic markings to 0. Server 104 then checks the ARP entry of the on-premises host vm2 (address 1.1.1.2). If it finds that its uplink traffic marking is 0 and its downlink traffic marking is 0, and the last active timestamp shows that there has been no activity for more than 60 seconds, server 104 can classify it as a suspected faulty host and add it to the list to be detected. For the on-premises host vm3 (address 1.1.1.3), if its uplink traffic is marked as 1 but its downlink traffic is marked as 0, server 104 can still classify it as an active host because this host has participated in at least one communication activity during the detection period, proving that it is in a normal working state. Through this detailed status analysis, server 104 can accurately identify the hosts that truly need fault verification and avoid unnecessary probing of normally working hosts.

[0072] Through the above steps, server 104 implements an intelligent host screening mechanism based on traffic activity, establishes an accurate ability to identify suspected faulty targets, and accurately distinguishes between active hosts and suspected faulty hosts by comprehensively analyzing traffic label status and time information. This ensures that subsequent probe operations are only performed on hosts that may actually have problems, significantly reducing unnecessary network probe traffic and effectively avoiding the ARP storm problem caused by indiscriminate probes in traditional solutions. At the same time, it ensures timely maintenance and aging time updates of ARP entries for active hosts, guaranteeing the continuity and stability of network communication.

[0073] Step S208: Send an Address Resolution Protocol (ARP) request for each host to be detected, determine the fault detection result of the host to be detected based on the response to the ARP request, and update the ARP table entry based on the fault detection result.

[0074] The Address Resolution Protocol (ARP) request message is used to query the MAC address corresponding to a specific IP address. It can contain information such as the sender's IP address, MAC address, and target IP address.

[0075] For example, server 104 can obtain a preset number of probe attempts and a single timeout duration. The preset number of probe attempts (Detectime) refers to the maximum number of probe attempts allowed before determining a host failure, ranging from 1 to 5, to ensure the reliability of the probe results. The single timeout duration (Detectimeout) refers to the maximum time to wait for a single ARP request response, ranging from 100 milliseconds to 10 seconds. If no response is received within this time, the probe is considered to have failed. For example, server 104 can obtain the preset number of probe attempts (Detectime) and the single timeout duration (Detectimeout) parameters from the system configuration, and these parameters can be flexibly configured according to the characteristics of the network environment and performance requirements.

[0076] Furthermore, server 104 can initialize a probe counter for each host to be detected based on a preset number of probes, send an Address Resolution Protocol (ARP) request, and start timing to obtain timing data. If the timing data exceeds the single timeout duration and no response is received, the probe counter value is decremented by 1, and the steps of sending ARP requests and starting timing to obtain timing data are repeated until the probe counter value is 0. When the probe counter value is 0, it is determined that the host to be detected has failed. The probe counter is a numerical variable used to track the remaining number of probes for the current host. Its initial value is set to a preset number of probes, and it can be decremented by 1 after each failed probe. When the counter is 0, a host failure is confirmed. For example, when the probe counter value is greater than 1, server 104 can send an ARP request and start timing using unicast to obtain timing data; when the probe counter value is equal to 1, server 104 can send an ARP request and start timing using broadcast to obtain timing data.

[0077] For example, server 104 can create an independent probe task for each host in the list of hosts to be detected. Each probe task can include basic information such as the target host's IP address, MAC address, and network segment, as well as probe status tracking variables. Server 104 can initialize a probe counter for each probe task, setting the initial value of the counter to a preset number of probes (Detectime), and simultaneously create a timer object to track the execution time of a single probe. Server 104 can also establish a probe task scheduling mechanism to rationally arrange the execution order of probe tasks according to the priority of the hosts to be detected and the system resource situation, avoiding the impact on the network caused by launching too many probe requests simultaneously.

[0078] When initiating a specific probe operation, server 104 can determine the probe method based on the current probe counter value. It checks the probe counter value; if the value is greater than 1, it uses unicast probe; if the value is equal to 1, it uses broadcast probe. This progressive probe strategy minimizes network impact while ensuring probe reliability. Server 104 can start a timer immediately after sending an ARP request to record the precise timestamp of the probe request. It can also establish an ARP reply listening mechanism to capture ARP reply packets in the network and match them with the currently occurring probe request to determine if the reply packet originates from the target host being probed.

[0079] During the timing process, server 104 can continuously monitor whether it receives ARP reply packets from the target host. When server 104 receives a correct ARP reply within the timeout period, it can immediately stop the timing, mark the probe result as successful, and update the ARP table entry information corresponding to the target host, including refreshing the aging time and resetting the traffic marking status. When the timing data reaches the single timeout duration and no valid reply is received, server 104 can determine that the current probe has failed, decrement the probe counter value by 1, and determine the next operation based on the decremented counter value. When the probe counter value is reduced to 0, server 104 can confirm that the target host has failed, delete the corresponding table entry record from the ARP table, clean up the related forwarding table entries and routing information, and generate a fault event log record.

[0080] In this embodiment, when handling probe failures, server 104 can adopt different retry strategies based on the current value of the probe counter. When the probe counter value is still greater than 1, server 104 can continue to retry the probe using unicast, repeatedly executing the ARP request sending and timer listening process. When the probe counter value equals 1, server 104 can switch to broadcast probe mode for a final probe attempt, expanding the probe range and increasing the probability of success. Server 104 can set an appropriate interval between each probe retry to avoid excessive pressure on the target host from continuous probes.

[0081] In some embodiments, server 104 may also employ parallel probing and intelligent probing scheduling mechanisms. Server 104 can establish a probing task pool, executing probing tasks for multiple hosts to be detected in parallel, improving probing efficiency through multi-threading or asynchronous I / O. Server 104 can implement intelligent probing interval adjustment, dynamically adjusting the probing interval and timeout based on network latency and the historical response characteristics of the target host, improving the targeting and accuracy of the probing. Server 104 can also establish a probing result cache, recording the historical probing results and response characteristics of each host to optimize the selection of probing strategies.

[0082] For example, server 104 can perform a detailed multi-stage probing process for a suspected faulty on-premises host vm2 (address 1.1.1.2). Server 104 can obtain the probing parameters configured by the system, assuming Detectime is set to 3 times and Detectimeout is set to 1 second, and then create a probing task for host vm2 and initialize the probing counter to 3. Server 104 can start the first unicast probe, extract the MAC address corresponding to host vm2 from the ARP table entry as the target hardware address, construct a unicast ARP request packet containing the source IP address, source MAC address, target IP address 1.1.1.2, and target MAC address, send the packet to the target host through the on-premises interface of the Layer 2 connection gateway, and start timing. If no ARP response is received from vm2 within the 1-second timeout period, server 104 can decrement the probing counter by 1 to 2 and continue the second unicast probe, repeating the same packet construction and sending process. If the second probe still fails, server 104 can decrement the probe counter by 1 and then switch to broadcast probe mode. It constructs a broadcast ARP request message and broadcasts it within the on-premises network segment via the Layer 2 gateway. If the broadcast probe receives an ARP response from vm2 within the timeout period, server 104 can confirm the host is functioning correctly and update its ARP table entry. If no response is received, it confirms a failure in vm2 and deletes the corresponding ARP table entry.

[0083] Furthermore, during the process of sending an Address Resolution Protocol (ARP) request and starting timing to obtain timing data using unicast, server 104 can extract the access control address corresponding to the host to be detected from the ARP table entry; generate a unicast ARP request message based on the address and access control address of the host to be detected; send the unicast ARP request message to the host to be detected through a Layer 2 connection gateway, and start timing to obtain timing data.

[0084] When sending Address Resolution Protocol (ARP) requests using unicast, server 104 can extract the MAC address information corresponding to the host to be detected from the currently maintained ARP table entries. This MAC address can be the target host's hardware address. Server 104 can construct a complete unicast ARP request message based on the IP address of the host to be detected and the extracted MAC address information. The destination MAC address field in the Ethernet frame header of this message is set to the target host's hardware address, ensuring the message is accurately delivered to the target host. Server 104 can set the sender IP address to the IP address of the Layer 2 connection gateway in the corresponding network segment, the sender MAC address to the hardware address of the corresponding interface of the Layer 2 connection gateway, the target IP address to the network address of the host to be detected, and the operation field to the ARP request type in the ARP request message. Server 104 can send the constructed unicast ARP request message through the appropriate network interface of the Layer 2 connection gateway. If the host to be detected is located in a cloud VPC network segment, it is sent through the cloud interface; if it is located in an on-premises IDC network segment, it is sent through the established virtual tunnel interface.

[0085] Furthermore, during the process of sending an Address Resolution Protocol (ARP) request and starting timing to obtain timing data using a broadcast method, server 104 can generate a broadcast ARP message based on the address of the host to be detected and the network segment address where the Layer 2 connection gateway is located; and broadcast the broadcast ARP message within the network segment through the Layer 2 connection gateway to start timing and obtain timing data.

[0086] When sending Address Resolution Protocol (ARP) requests via broadcast, server 104 can determine the network segment range to which the host to be detected belongs based on its IP address, and obtain the gateway address and interface information of the Layer 2 connection gateway within that network segment. Server 104 can construct a broadcast ARP request message, setting the destination MAC address field in the Ethernet frame header to the broadcast address to ensure that the message can be received by all devices within the network segment. Server 104 can set the sender IP address to the gateway address of the Layer 2 connection gateway, the sender MAC address to the hardware address of the gateway interface, the destination IP address to the network address of the host to be detected, and the destination MAC address field to all zeros or an unknown address identifier in the broadcast ARP request message. This message is then broadcast within the network segment to which the host to be detected belongs via the Layer 2 connection gateway. When the host is located in a VPC network segment in the cloud, the broadcast occurs within the corresponding Virtual Private Cloud subnet. When the host is located in an on-premises IDC network segment, the broadcast occurs through a virtual tunnel within the on-premises network environment, ensuring that the broadcast coverage extends to the network locations where the target host may be located.

[0087] In the aforementioned host fault detection method, by acquiring network data packets passing through the Layer 2 connection gateway and resolving the source and destination addresses of these packets, the system can monitor data flow in the network in real time. This allows the system to make intelligent decisions based on actual network traffic conditions, rather than blindly probing at fixed time intervals. The transmission direction of the network data packets is determined based on the source and destination addresses, and the traffic marker status corresponding to the source and destination addresses in the Address Resolution Protocol (ARP) entries is updated accordingly. This ensures that the active state of the host, whether initiating or receiving communication, is accurately recorded, resolving the potential misjudgment issues that may arise from judging host status based on a single dimension in traditional solutions. When the detection time arrives, the host to be detected is selected based on the status of each traffic marker in the Address Resolution Protocol (ARP) table. The selective probing mechanism directly solves the problem of wasted network bandwidth resources caused by indiscriminate probing in traditional schemes, significantly reducing unnecessary probe traffic in the network. An ARP request is sent to each host to be detected, and the fault detection result of the host is determined based on the response to the ARP request. The ARP table entry is updated based on the fault detection result, ensuring that only hosts that may actually be faulty are probed and verified. When a host does indeed fail, it can be detected and the table entry can be updated in a timely manner, avoiding the continuous transmission of faulty traffic and improving the utilization rate of network bandwidth resources.

[0088] In one exemplary embodiment, such as Figure 5 As shown, the transmission direction includes uplink traffic and downlink traffic; step S204 includes steps S302 to S306. Wherein:

[0089] Step S302: Match the source address with the virtual private cloud network segment identifier and the on-premises network segment identifier to obtain the source address network segment affiliation.

[0090] The cloud-based Virtual Private Cloud (VPC) network segment identifier refers to the configuration parameters used to identify the network address range of the VPC, including information such as network address, subnet mask, and address prefix length, such as CIDR (Classless Inter-Domain Routing) format like 192.168.1.0 / 24 or 10.0.0.0 / 16. The on-premises network segment identifier refers to the configuration parameters used to identify the network address range of the on-premises Internet Data Center (IDC), and can also be represented by a combination of network address and subnet mask, such as 172.16.0.0 / 16 or 200.51.51.0 / 24. The source address network segment attribution refers to the network segment category to which the source IP address belongs, determined by a network address matching algorithm. The result can include three types: cloud-based VPC network segment, on-premises network segment, or unknown network segment.

[0091] For example, server 104 can load predefined network segment identification information from the system configuration database to establish a complete network segment configuration table. Server 104 can maintain a list of virtual private cloud (VPC) network segment identifiers, which contains the network address ranges of all VPC subnets currently covered by the L2GW service. Each entry records detailed information such as network address, subnet mask, address prefix length, network segment name, and associated interface. Server 104 can maintain a list of on-premises network segment identifiers, recording information about all on-premises IDC network segments connected via virtual tunnels, including parameters such as remote network address, local tunnel interface, peer gateway address, and tunnel type. Server 104 can establish a network segment matching algorithm that can efficiently compare any IP address with the network segment identifier list to determine the network segment to which the address belongs.

[0092] During source address matching, server 104 extracts the source IP address as the matching target. After completing network segment matching, server 104 can establish a matching result verification mechanism to ensure matching accuracy. Server 104 checks whether the source address matches multiple network segment identifiers simultaneously. If overlapping network segments occur, the most matching network segment is selected according to network segment priority or specificity principles. Server 104 can record detailed information about the matching process, including the number of network segments involved in the matching, the matching algorithm execution time, and the final matching result, for use in network segment configuration optimization and matching performance analysis. For source addresses that cannot match any predefined network segment, server 104 marks the network segment belonging to an unknown network segment and generates corresponding alarm information to prompt the administrator to check the integrity of the network segment configuration.

[0093] In some embodiments, server 104 may employ a cache-based fast network segment matching method. Server 104 may establish a network segment matching cache table, storing the most recently matched IP addresses and their network segment affiliation results in a high-speed cache to avoid repeatedly executing the matching algorithm for the same address.

[0094] For example, when processing data packets sent by cloud host vm1 (address 1.1.1.1), server 104 can obtain the cloud VPC network segment identifier from the system configuration, assuming it is configured as 1.1.1.0 / 24. Then, it matches the source IP address 1.1.1.1 with this network segment identifier, calculates the result of a bitwise AND operation between 1.1.1.1 and the subnet mask 255.255.255.0, which is 1.1.1.0. This result is completely consistent with the network segment address 1.1.1.0, therefore determining that the source address 1.1.1.1 belongs to the cloud virtual private cloud network segment. Server 104 can record the matching result and set the source address network segment to the cloud virtual private cloud network segment, and record the specific network segment information of the match, including the network segment name, the associated VPC identifier, the corresponding network interface, and other data. When server 104 processes a data packet from on-premises host vm2 (address 1.1.1.2), since this address does not belong to the cloud VPC network segment configuration range, server 104 can continue to match it with the on-premises network segment identifier. Assuming the on-premises network segment is configured as a sub-range of 1.1.1.0 / 24 or a different network segment, the same matching algorithm is used to determine that the network segment belongs to the on-premises network segment.

[0095] Step S304: Match the destination address with the virtual private cloud network segment identifier and the on-premises network segment identifier to obtain the destination address network segment affiliation.

[0096] For example, server 104 can extract the destination IP address as the matching object for the current step. This address represents the network identifier of the receiver of the network data packet or the final target host. If no cloud VPC network segment is matched at the destination address, server 104 continues to perform matching with the on-premises network segment identifier. Server 104 can use a recently used cache to store frequently accessed destination addresses and their network segment affiliation results in a fast access cache, reducing the overhead of repeated matching calculations. Server 104 can implement a parallel matching algorithm, using multi-threading to perform matching operations on cloud and on-premises network segments simultaneously when there are many network segments configured, thereby improving the overall matching speed.

[0097] Furthermore, for destination addresses that cannot be matched against any predefined network segment, server 104 can perform unknown address processing. Server 104 can mark the network segment to which such addresses belong as an unknown network segment and generate a detailed log of unmatched addresses, including address value, number of network segments attempted for matching, matching time, and other information. Server 104 can analyze the occurrence patterns of unmatched addresses and prompt the administrator whether it is necessary to update the network segment configuration or add new network segment identifiers.

[0098] In some embodiments, server 104 may employ a geolocation-based intelligent network segment matching method to establish a network segment geographic information database, recording attributes such as the physical location, operator information, and network characteristics of each network segment, and improving matching accuracy through address attribution analysis. Server 104 may implement a machine learning-based network segment identification algorithm, training an address classification model by analyzing historical network traffic data to automatically identify newly emerging network segment patterns.

[0099] Step S306: If the source address network segment belongs to the cloud virtual private cloud network segment and the destination address network segment belongs to the cloud-based network segment, the transmission direction is determined to be uplink traffic; if the source address network segment belongs to the cloud-based network segment and the destination address network segment belongs to the cloud virtual private cloud network segment, the transmission direction is determined to be downlink traffic.

[0100] Uplink traffic refers to the network traffic direction from the virtual private cloud network segment in the cloud to the on-premises network segment. It can represent a cloud host actively initiating communication with an on-premises host or responding to a request from an on-premises host. Downlink traffic refers to the network traffic direction from the on-premises network segment to the virtual private cloud network segment in the cloud. It can also represent an on-premises host actively initiating communication with a cloud host or responding to a request from a cloud host. For example, server 104 can establish a transmission direction determination rule table, which clearly defines the traffic direction classification corresponding to different network segment affiliations, including uplink traffic, downlink traffic, and possible undefined traffic types.

[0101] For example, server 104 can determine that the network segment with source address 1.1.1.1 belongs to the virtual private cloud network segment in the cloud, and the network segment with destination address 1.1.1.2 belongs to the on-premises network segment. According to the judgment rule that the source address belongs to the cloud and the destination address belongs to the on-premises network, server 104 can determine that the transmission direction of the data packet is uplink traffic and record the judgment result, including detailed data such as the traffic direction being uplink, the source and destination host information involved, and the data packet processing time, and increment the uplink traffic counter by 1. When server 104 processes the response data packet sent by on-premises host vm2 to cloud host vm1, according to the condition that the source address 1.1.1.2 belongs to the on-premises network segment and the destination address 1.1.1.1 belongs to the virtual private cloud network segment in the cloud, it determines that the transmission direction is downlink traffic and performs the corresponding recording and statistical update operations. When server 104 processes communication between on-premises host vm3 (address 1.1.1.3) and cloud host vm1, it can determine the direction of execution based on the network segment of the address, ensuring that all on-premises and cloud-cloud communication can be correctly classified as uplink or downlink traffic.

[0102] Through the above steps, server 104 achieves accurate transmission direction identification based on network segment ownership information, establishes a complete traffic direction classification system, and accurately distinguishes bidirectional traffic between the cloud and the on-premises network through a systematic direction determination logic, ensuring the accuracy of uplink and downlink traffic labeling.

[0103] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0104] Based on the same inventive concept, this application also provides a host fault detection device for implementing the host fault detection method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more host fault detection device embodiments provided below can be found in the limitations of the host fault detection method described above, and will not be repeated here.

[0105] In one exemplary embodiment, such as Figure 6 As shown, a host fault detection device is provided, including: a data acquisition module 502, a data update module 504, a data selection module 506, and a fault detection module 508, wherein:

[0106] The data acquisition module 502 is used to acquire network data packets passing through the Layer 2 connection gateway and parse the source and destination addresses of the network data packets;

[0107] The data update module 504 is used to determine the transmission direction of network data packets based on the source address and destination address, and update the traffic marker status corresponding to the source address and destination address in the Address Resolution Protocol (ARP) table entry according to the transmission direction.

[0108] The data selection module 506 is used to select the host to be detected based on the status of each traffic marker in the Address Resolution Protocol (ARP) table when the detection time arrives.

[0109] The fault detection module 508 is used to send an Address Resolution Protocol (ARP) request to each host to be detected, determine the fault detection result of the host to be detected based on the response to the ARP request, and update the ARP table entry based on the fault detection result.

[0110] In one embodiment, the fault detection module 508 is specifically used to obtain a preset number of probes and a single timeout duration; for each host to be detected, the probe counter is initialized according to the preset number of probes, an address resolution protocol request is sent and timing is started to obtain timing data; if the timing data is greater than the single timeout duration and no response is received, the value of the probe counter is decremented by 1, and the steps of sending the address resolution protocol request and starting timing to obtain timing data are repeated until the value of the probe counter is 0, and if the value of the probe counter is 0, it is determined that the host to be detected has failed.

[0111] In one embodiment, the fault detection module 508 is further configured to send an address resolution protocol request and start timing to obtain timing data by unicast when the value of the probe counter is greater than 1; and to send an address resolution protocol request and start timing to obtain timing data by broadcast when the value of the probe counter is equal to 1.

[0112] In one embodiment, the fault detection module 508 is further configured to extract the access control address corresponding to the host to be detected from the address resolution protocol entry; generate a unicast address resolution protocol request message based on the address of the host to be detected and the access control address; send the unicast address resolution protocol request message to the host to be detected through a Layer 2 connection gateway, and start timing to obtain timing data.

[0113] In one embodiment, the fault detection module 508 is further configured to generate a broadcast address resolution protocol request message based on the address of the host to be detected and the network segment address where the Layer 2 connection gateway is located; broadcast the broadcast address resolution protocol request message within the network segment through the Layer 2 connection gateway, and start timing to obtain timing data.

[0114] In one embodiment, the transmission direction includes uplink traffic and downlink traffic; the data update module 504 is specifically used to match the source address with the cloud virtual private cloud network segment identifier and the on-premises network segment identifier to obtain the source address network segment affiliation; match the destination address with the cloud virtual private cloud network segment identifier and the on-premises network segment identifier to obtain the destination address network segment affiliation; if the source address network segment affiliation belongs to the cloud virtual private cloud network segment and the destination address network segment affiliation belongs to the on-premises network segment, the transmission direction is determined to be uplink traffic; if the source address network segment affiliation belongs to the on-premises network segment and the destination address network segment affiliation belongs to the cloud virtual private cloud network segment, the transmission direction is determined to be downlink traffic.

[0115] Each module in the aforementioned host fault detection device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0116] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a host fault detection method.

[0117] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0118] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0119] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0120] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0121] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0122] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0123] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for detecting host computer faults, characterized in that, The method includes: Obtain network packets passing through the Layer 2 connection gateway, and parse the source and destination addresses of the network packets; The transmission direction of the network data packet is determined based on the source address and the destination address, and the traffic tag status corresponding to the source address and the destination address in the Address Resolution Protocol (ARP) entry is updated based on the transmission direction. When the detection time arrives, the host to be detected is selected according to the traffic marker status in the Address Resolution Protocol (ARP) table entry; For each host to be detected, an Address Resolution Protocol (ARP) request is sent. The fault detection result of the host to be detected is determined based on the response to the ARP request, and the ARP entry is updated based on the fault detection result.

2. The method according to claim 1, characterized in that, The step of sending an Address Resolution Protocol (ARP) request to each of the hosts to be detected and determining the fault detection result of the hosts to be detected based on the response to the ARP requests includes: Get the preset number of probes and the timeout duration for each probe; For each host to be detected, the detection counter is initialized according to the preset number of detections, an address resolution protocol request is sent, and timing is started to obtain timing data; If the timing data exceeds the single timeout duration and no response is received, the value of the probe counter is decremented by 1, and the steps of sending the address resolution protocol request and starting timing to obtain timing data are repeated until the value of the probe counter is 0. If the value of the probe counter is 0, it is determined that the host under test has malfunctioned.

3. The method according to claim 2, characterized in that, The step of sending an address resolution protocol request and starting timing to obtain timing data includes: If the value of the probe counter is greater than 1, an address resolution protocol request is sent by unicast and timing is started to obtain timing data; When the value of the probe counter is equal to 1, an address resolution protocol request is sent via broadcast and timing begins to obtain timing data.

4. The method according to claim 3, characterized in that, The step of sending an Address Resolution Protocol request and starting timing to obtain timing data using unicast includes: Extract the access control address corresponding to the host to be detected from the address resolution protocol entry; Generate a unicast address resolution protocol request message based on the address of the host to be detected and the access control address; The Layer 2 connection gateway sends a unicast address resolution protocol request message to the host under test and starts timing to obtain timing data.

5. The method according to claim 3, characterized in that, The step of sending an Address Resolution Protocol (ARP) request and starting timing to obtain timing data via broadcast includes: Based on the address of the host to be detected and the network segment address where the Layer 2 connection gateway is located, a broadcast address resolution protocol request message is generated; The Layer 2 connection gateway broadcasts the Broadcast Address Resolution Protocol (BRP) request message within the network segment and starts timing to obtain timing data.

6. The method according to any one of claims 1 to 5, characterized in that, The transmission direction includes uplink traffic and downlink traffic; determining the transmission direction of the network data packet based on the source address and the destination address includes: The source address is matched with the virtual private cloud network segment identifier and the on-premises network segment identifier to obtain the network segment affiliation of the source address; The destination address is matched with the virtual private cloud network segment identifier and the on-premises network segment identifier to obtain the destination address network segment affiliation. If the source address network segment belongs to the virtual private cloud network segment in the cloud and the destination address network segment belongs to the on-premises network segment, the transmission direction is determined to be uplink traffic. If the source address network segment belongs to the on-premises network segment and the destination address network segment belongs to the on-premises virtual private cloud network segment, the transmission direction is determined to be downlink traffic.

7. A host fault detection device, characterized in that, The device includes: The data acquisition module is used to acquire network data packets passing through the Layer 2 connection gateway and parse the source and destination addresses of the network data packets; The data update module is used to determine the transmission direction of the network data packet based on the source address and the destination address, and update the traffic marker status corresponding to the source address and the destination address in the Address Resolution Protocol (ARP) entry based on the transmission direction. The data selection module is used to select the host to be detected based on the traffic marker status in the Address Resolution Protocol (ARP) table when the detection time arrives. The fault detection module is used to send an Address Resolution Protocol (ARP) request to each of the hosts to be detected, determine the fault detection result of the host to be detected based on the response to the ARP request, and update the ARP entry based on the fault detection result.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images