Virtual network fault diagnosis method and device

Abstract

The application provides a virtual network fault diagnosis method and device, relates to the technical field of cloud computing and computer networks, and comprises the following steps: acquiring failure request metadata associated with a network fault; constructing at least one probe data packet according to the failure request metadata, and setting a diagnosis mark in the probe data packet; injecting the probe data packet carrying the diagnosis mark into a network from a network position corresponding to source network position information; intercepting the probe data packet carrying the diagnosis mark at at least one forwarding device on the way of the probe data packet, and generating corresponding event records; aggregating the event records with the same probe identifier, and reconstructing an actual forwarding path of the probe data packet according to sequence indication information; and determining a fault type and a fault position of the network fault based on the event records in the reconstructed actual forwarding path. Through the method provided by the application, on-demand triggering, non-intrusive and port-level-precision virtual network fault diagnosis are realized.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and computer network technology, and in particular to a method and apparatus for diagnosing virtual network faults. Background Technology

[0002] In cloud computing and virtualized network environments, network functions are implemented by software-defined components (such as virtual switches and virtual routers) running on shared physical hardware. This highly dynamic and complex network architecture is prone to various failures, which seriously affect the stability of upper-layer services.

[0003] For virtual network fault diagnosis, existing technologies mainly include two types of solutions: one is telemetry systems based on active probing, such as building a connectivity map by continuously sending Internet Control Message Protocol (ICMP) or User Datagram Protocol (UDP) probe packets through probes deployed across the entire network; the other is static configuration analysis tools, which formally verify network configurations to check for potential connectivity problems. However, existing technologies have significant drawbacks: telemetry systems rely on probe packets of fixed protocols, which cannot detect fine-grained configuration errors for specific protocol fields, resulting in a large number of user-reported faults not being effectively detected; at the same time, whether it is telemetry or static analysis, their diagnostic granularity is usually limited to the device or IP level, and cannot delve into the internal workings of virtual switches to identify port-level forwarding anomalies; in addition, continuous network-wide probing incurs huge computational and bandwidth overhead, and many solutions require modification of the underlying network device source code or rely on special hardware, making them difficult to deploy in heterogeneous and closed public cloud environments.

[0004] Therefore, there is an urgent need for a virtual network fault diagnosis method that can be triggered on demand, is non-intrusive, and has port-level accuracy. Summary of the Invention

[0005] This invention provides a method and apparatus for diagnosing virtual network faults, in order to overcome the deficiencies existing in the prior art.

[0006] This invention provides a method for diagnosing virtual network faults, comprising the following steps: Obtain failed request metadata associated with network failure; wherein, the failed request metadata includes source network location information; At least one probe packet is constructed based on the failed request metadata, and a diagnostic flag is set in the probe packet; wherein the diagnostic flag is used to identify the probe packet as diagnostic traffic; The probe data packet carrying the diagnostic marker is injected into the network from the network location corresponding to the source network location information; At at least one forwarding device along the path of the probe data packet, the probe data packet carrying the diagnostic tag is intercepted, and a corresponding event record is generated; wherein, the event record includes a probe identifier for identifying the probe data packet to which it belongs, and sequence indication information for indicating the order in which the events occur; Event records with the same probe identifier are aggregated, and the actual forwarding path of the probe data packet is reconstructed based on the sequence indication information; Based on the event records in the reconstructed actual forwarding path, the fault type and fault location of the network fault are determined.

[0007] According to a virtual network fault diagnosis method provided by the present invention, the failure request metadata further includes communication identification information for describing the characteristics of the failure traffic; The acquisition of failed request metadata associated with network failures includes: In response to receiving a fault notification, extract the context information associated with the network fault; The context information is parsed to obtain the communication identification information; wherein, the communication identification information includes a five-tuple consisting of the source Internet Protocol address, the destination Internet Protocol address, the source port, the destination port, and the protocol type.

[0008] According to a virtual network fault diagnosis method provided by the present invention, the step of constructing at least one probe data packet based on the failure request metadata includes: Based on the quintuple information, a probe data packet with the same network layer and transport layer header fields as the original data stream that caused the network failure is constructed.

[0009] According to a virtual network fault diagnosis method provided by the present invention, setting a diagnostic marker in the probe data packet includes: Obtain a preset magic number, a unique probe identifier, and an initialized sequence number; wherein, the magic number is used to identify the probe data packet as diagnostic traffic, the probe identifier is used to associate multiple probe data packets belonging to the same diagnostic process, and the sequence number is used to record the order in which the probe data packet is processed during forwarding; Write the magic number, the probe identifier, and the sequence number into the Internet Protocol Options field of the probe data packet.

[0010] According to a virtual network fault diagnosis method provided by the present invention, the step of setting a diagnostic marker in the probe data packet further includes: If the Internet Protocol Options field is unavailable or discarded by the network device, the magic number, the probe identifier, and the sequence number are written into the transport layer protocol options field or application layer payload of the probe data packet.

[0011] According to a virtual network fault diagnosis method provided by the present invention, the step of injecting a probe data packet carrying the diagnostic marker into the network from a network location corresponding to the source network location information includes: Based on the source network location information, determine the source type of the original data stream corresponding to the network fault; wherein, the source type includes virtual machines or containers; When the source type is a virtual machine or container, obtain the network namespace of the host machine where the virtual machine or container is located, and locate the virtual network device connected to the virtual network interface card of the virtual machine or container; wherein, the virtual network device is a tap device or a veth device; By using raw sockets, probe data packets carrying the diagnostic tags are written to the virtual network device to simulate the process of initiating data packet transmission from inside the virtual machine or container.

[0012] According to a virtual network fault diagnosis method provided by the present invention, the step of intercepting the probe data packet carrying the diagnostic marker at at least one forwarding device along the probe data packet path and generating a corresponding event record includes: An extended Berkeley packet filter probe program is pre-mounted on the kernel data processing path of the forwarding device. When the probe packet enters the forwarding device, the extended Berkeley packet filter probe program is triggered to parse the header field of the probe packet to identify whether the diagnostic flag exists; In the presence of the diagnostic marker, the probe identifier and the sequence indication information are read from the probe data packet, and the action information generated by the current forwarding device in processing the probe data packet is captured; wherein, the action information includes the inbound port name, the outbound port name, the processing action type, and the timestamp; The event record is generated by associating the probe identifier, the sequence indication information, the action information, and the device identifier of the current forwarding device, and the sequence indication information in the probe data packet is incremented according to a preset rule.

[0013] According to a virtual network fault diagnosis method provided by the present invention, the method further includes: When the probe data packet undergoes tunnel encapsulation during transmission, the extended Berkeley packet filter probe program triggered at the encapsulation point copies the diagnostic markers, probe identifiers, and sequence indication information from the probe data packet into the header field of the encapsulated new data packet, and increments the sequence indication information. When the probe data packet undergoes tunnel decapsulation during transmission, the extended Berkeley packet filter probe program triggered at the decapsulation point copies the diagnostic marker, probe identifier, and sequence indication information from the header field of the encapsulated data packet to the header field of the decapsulated inner data packet, and increments the sequence indication information.

[0014] According to a virtual network fault diagnosis method provided by the present invention, the aggregation of event records with the same probe identifier and the reconstruction of the actual forwarding path of the probe data packet based on the sequence indication information include: Event records generated from various forwarding devices are collected, and event records with the same probe identifier are grouped into the same event record set; Based on the size relationship of the sequence indication information in each event record, the event records in the event record set are sorted in ascending order; wherein, the smaller the value of the sequence indication information, the earlier the event occurred; The sorted event records are concatenated sequentially, and the forwarding device identifier, inbound port name, outbound port name, and processing action type corresponding to each event record are extracted to form a complete device sequence and port-level action sequence that the probe data packet passes through from the injection point to the final departure point, which serves as the actual forwarding path.

[0015] According to a virtual network fault diagnosis method provided by the present invention, before determining the fault type and fault location of the network fault based on event records in the reconstructed actual forwarding path, the method further includes: Obtain cloud platform configuration information for the virtual network; Based on the cloud platform configuration information, an expected forwarding path for the probe data packet to be transmitted in the virtual network is generated; wherein, the expected forwarding path is used to describe the sequence of devices and forwarding actions that the probe data packet should pass through according to the network configuration logic.

[0016] According to a virtual network fault diagnosis method provided by the present invention, determining the fault type and fault location of the network fault based on event records in the reconstructed actual forwarding path includes: When there are multiple actual forwarding paths for the same detection identifier, compare the length and endpoint of the multiple actual forwarding paths; If all actual forwarding paths terminate at the same forwarding device and the processing action type in the event log of the forwarding device is "drop", or if all actual forwarding paths fail to reach the destination network card, the fault type is determined to be disconnection, and the terminated forwarding device is located as the fault location. If all actual forwarding paths reach the destination completely, and the processing time on a certain path exceeds a preset threshold, the fault type is determined to be delay, and the forwarding device whose processing time exceeds the preset threshold is located as the fault location. If some of the actual forwarding paths reach the destination completely while others terminate midway, the fault type is determined to be packet loss, and the terminal forwarding device of the terminated actual forwarding path is located as the fault location. If the lengths of the multiple actual forwarding paths are inconsistent and all reach the destination completely, or if the reconstructed actual forwarding path is inconsistent with the expected forwarding path generated according to the cloud platform configuration, the fault type is determined to be path deviation.

[0017] The present invention also provides a virtual network fault diagnosis device, comprising the following modules: The acquisition module is used to acquire failed request metadata associated with network failures; wherein, the failed request metadata includes source network location information; A tagging module is configured to construct at least one probe data packet based on the failed request metadata, and set a diagnostic tag in the probe data packet; wherein the diagnostic tag is used to identify the probe data packet as diagnostic traffic; An injection module is used to inject probe data packets carrying the diagnostic markers into the network from a network location corresponding to the source network location information; The generation module is configured to intercept the probe data packet carrying the diagnostic tag at at least one forwarding device along the path of the probe data packet, and generate a corresponding event record; wherein the event record includes a probe identifier for identifying the probe data packet to which it belongs, and sequence indication information for indicating the order in which the events occur; The reconstruction module is used to aggregate event records with the same probe identifier and reconstruct the actual forwarding path of the probe data packet according to the sequence indication information; The diagnostic module is used to determine the fault type and location of the network fault based on the event records in the reconstructed actual forwarding path.

[0018] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the virtual network fault diagnosis method as described above.

[0019] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the virtual network fault diagnosis method as described above.

[0020] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the virtual network fault diagnosis method as described above.

[0021] This invention provides a virtual network fault diagnosis method and apparatus, which involves: acquiring failure request metadata associated with a network fault; wherein the failure request metadata includes source network location information; constructing at least one probe data packet based on the failure request metadata, and setting a diagnostic flag in the probe data packet; wherein the diagnostic flag is used to identify the probe data packet as diagnostic traffic; injecting the probe data packet carrying the diagnostic flag into the network from a network location corresponding to the source network location information; intercepting the probe data packet carrying the diagnostic flag at at least one forwarding device along the path of the probe data packet, and generating a corresponding event record; wherein the event record includes a probe identifier for identifying the probe data packet and sequence indication information for indicating the order of events; aggregating event records with the same probe identifier, and reconstructing the actual forwarding path of the probe data packet based on the sequence indication information; and determining the fault type and fault location of the network fault based on the event records in the reconstructed actual forwarding path. Therefore, this invention, by acquiring failed request metadata and constructing probe packets carrying diagnostic tags, injects them on demand from the same source network location as the original fault flow. This allows for accurate reproduction of protocol characteristics and forwarding paths in real fault scenarios, effectively overcoming the blind spot of traditional telemetry technology, which cannot detect specific field configuration errors due to the use of fixed probe protocols. Simultaneously, by intercepting tagged probe packets at the forwarding device and generating event records containing probe identifiers and sequence indication information, the actual forwarding path is reconstructed. This enables fault location granularity to penetrate to the specific forwarding device and port level, solving the problem that existing technologies can only locate faults at the device or IP level and cannot identify port-level anomalies within virtual switches. Furthermore, this invention triggers the diagnostic process only on demand after a fault occurs, without continuously sending probe traffic across the entire network, significantly reducing resource overhead. The entire process does not rely on modifying the underlying network device source code or special hardware support, exhibiting excellent non-intrusiveness and deployment compatibility. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a flowchart illustrating the virtual network fault diagnosis method provided by the present invention.

[0024] Figure 2 This is a complete flowchart of the virtual network fault diagnosis method provided by the present invention.

[0025] Figure 3 This is a schematic diagram of the structure of the virtual network fault diagnosis device provided by the present invention.

[0026] Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0028] The following description, in conjunction with the accompanying drawings, illustrates a method and apparatus for diagnosing virtual network faults according to the present invention.

[0029] With the widespread adoption of cloud computing technology, virtualization environments have become an important component of modern computing systems. In public cloud platforms (such as AWS and Azure) and private cloud environments (such as OpenStack and Kubernetes), virtual networks are implemented through software-defined components (such as virtual switches and virtual routers) running on shared physical hardware. This network environment is highly dynamic and complex, frequently being created, modified, or destroyed due to changes in IT services. In such environments, network failures occur frequently, severely impacting the stability of upper-layer services.

[0030] Several technologies exist for virtual network fault diagnosis. Traditional diagnostic tools primarily use simple Ping and Traceroute methods to probe IP layer connectivity. Another type is telemetry-based systems, which attempt to discover faults by deploying numerous probes throughout the network to build a network-wide connectivity map. A third type is static configuration analysis tools, such as AWS Reachability Analyzer, which formally verify network configurations to check connectivity.

[0031] The shortcomings of related technologies: First, telemetry technologies typically infer network health based on fixed probe protocols, thus failing to detect configuration errors targeting specific protocol fields. For example, suppose a user configures flow table rules on an OVS bridge on a gateway node to block TCP port traffic within a specific range, such as ports 8004 to 8007. However, due to an incorrect input, an incorrect port mask is applied (e.g., using a 0xfff8 mask), causing legitimate TCP packets not within that range (such as those on port 8000) to be unexpectedly dropped. In this case, probe packets sent by UDP-based telemetry tools (such as Zoonet) will not match the drop rule, thus incorrectly reporting that the path is open. Similarly, tools based on fixed ports or protocols, such as Pingmesh, will also struggle to detect this specific rule. This missed diagnosis due to mismatches in protocols, ports, or specific header fields leaves operations personnel helpless when facing such policy-based packet loss failures, forcing them to perform tedious manual troubleshooting.

[0032] Secondly, the diagnostic granularity of related technologies typically remains at the device or IP level, failing to delve into the internal workings of virtual switches to handle device port-level faults. Consider a large-scale compute node hosting numerous virtual machines connected via an OVS bridge. If an unexpected OVS database update causes a change in the logical port number associated with a virtual machine (e.g., from 7051 to 7054), but the physical or virtual link remains connected to the old port, communication to that virtual machine will be redirected by OVS to an incorrect or non-existent port and interrupted. Related tools can only report that communication between two IPs is not possible, or that probe packets disappear after reaching the node, but cannot pinpoint the specific cause. Maintenance personnel must manually check the network interface name corresponding to the virtual machine IP, the OVS port ID corresponding to the network interface, and the flow table forwarding actions, a process that is extremely time-consuming. The inability to precisely locate the specific virtual port fault is a major drawback.

[0033] Finally, telemetry requires continuous, fully interconnected probing across all devices to maintain topology updates, resulting in significant computational and bandwidth overhead that increases quadratically with network size. Furthermore, many telemetry schemes require inserting metadata into data packets, necessitating modifications to network device source code or reliance on specialized hardware, which is difficult to implement in heterogeneous and closed public cloud environments. While static analysis tools can detect configuration errors, they cannot detect runtime dynamic anomalies (such as buffer overflows) or reflect true data plane behavior.

[0034] Based on this, the present invention proposes a virtual network fault diagnosis method to solve at least one of the above problems.

[0035] Figure 1 This is a flowchart illustrating the virtual network fault diagnosis method provided by the present invention, as shown below. Figure 1 As shown, the method includes the following: Step 100: Obtain failure request metadata associated with network failure; wherein the failure request metadata includes source network location information.

[0036] Specifically, the first step is to obtain the failure request metadata associated with the network failure. This metadata is a set of information that can describe the characteristics of the original data stream that caused the failure. For example, the source network location information can be specifically represented as the name of the virtual machine that caused the failure, the container identifier, or the Internet Protocol address of the physical host, thereby clarifying which network node the failure stream originated from.

[0037] Step 200: Construct at least one probe data packet based on the failed request metadata, and set a diagnostic flag in the probe data packet; wherein the diagnostic flag is used to identify the probe data packet as diagnostic traffic.

[0038] Specifically, one or more probe packets are constructed based on this metadata. A probe packet is a packet that is highly similar to or even completely identical to the original faulty data stream in the network layer and transport layer header fields. For example, it has the same source Internet Protocol address, destination Internet Protocol address, source port, destination port, and protocol type. A diagnostic flag is set in the probe packet. The diagnostic flag is a special identifier used to distinguish between normal service traffic and diagnostic traffic. It can be embedded in the Internet Protocol Options field or other available fields of the packet in the form of a preset magic number, a unique probe identifier, and a sequence number used to record the forwarding order.

[0039] Step 300: Inject the probe data packet carrying the diagnostic marker into the network from the network location corresponding to the source network location information.

[0040] Specifically, the probe data packet carrying the diagnostic tag is injected into the network from the network location corresponding to the source network location information. For example, if the original fault originated from a virtual machine, it is simulated from the host machine where the virtual machine is located by writing to the tap device connected to the virtual machine's virtual network card, thereby ensuring that the probe data packet experiences the exact same network entry environment as the original fault.

[0041] Step 400: At at least one forwarding device along the path of the probe data packet, intercept the probe data packet carrying the diagnostic tag and generate a corresponding event record; wherein, the event record includes a probe identifier for identifying the probe data packet to which it belongs, and sequence indication information for indicating the order in which the events occur.

[0042] Specifically, when probe packets are transmitted in the network, at each forwarding device along their path, such as a virtual switch, virtual router, or Linux bridge, the system intercepts probe packets carrying diagnostic tags and generates corresponding event logs. Here, an event log is a structured piece of information containing multiple key fields. The probe identifier is a unique number that identifies all relevant probe packets in a diagnostic process, used to associate events scattered across different devices with the same diagnostic task. The sequence indicator is a monotonically increasing number used to indicate the order in which the same probe packet is processed by each forwarding device.

[0043] Step 500: Aggregate event records with the same probe identifier, and reconstruct the actual forwarding path of the probe data packet according to the sequence indication information.

[0044] Specifically, all event records with the same probe identifier are aggregated together and sorted in ascending order according to the numerical value of the sequence indication information, thereby reconstructing the complete actual forwarding path that the probe packet traversed in the virtual network. This path not only includes the identifiers of the forwarding devices passed through in sequence, but can also be accurate to the inbound port name and outbound port name of each device, such as the "tap32a" port or "vxlan_sys_4789" port of the virtual switch.

[0045] Step 600: Based on the event records in the reconstructed actual forwarding path, determine the fault type and fault location of the network fault.

[0046] Specifically, based on these event records in the reconstructed actual forwarding path, this embodiment can automatically determine the fault type and location of the network fault. For example, it can identify disconnection faults by judging whether the path terminates abnormally in the middle, determine whether there is a delay fault by calculating the timestamp difference between adjacent event records, or identify fault types such as packet loss or path deviation by comparing the consistency of multiple replay paths, and accurately locate the fault location to the specific forwarding device or even the specific virtual port of the device.

[0047] It's important to note that this method operates only on demand after a fault is detected, rather than performing continuous monitoring. This post-fault, reactive design means the central generator is idle most of the time. Therefore, scalability depends on the number of concurrent diagnostic sessions. For example, in a high-pressure scenario with 1000 concurrent diagnostic sessions (10 packets replay per session, 7 hops per packet, 200 bytes per event), the total generated data is 14MB. If these events are sent within one second, the required bandwidth is only 112 Mbps, which is negligible for data center networks. The CPU load for processing 70,000 events per second at peak times is also low. Therefore, this method has extremely high scalability in large-scale environments.

[0048] The above describes the steps of the virtual network fault diagnosis method provided by this invention. As can be seen from the above description, the virtual network fault diagnosis method provided by this invention involves: acquiring failure request metadata associated with a network fault; wherein the failure request metadata includes source network location information; constructing at least one probe data packet based on the failure request metadata, and setting a diagnostic flag in the probe data packet; wherein the diagnostic flag is used to identify the probe data packet as diagnostic traffic; injecting the probe data packet carrying the diagnostic flag into the network from a network location corresponding to the source network location information; intercepting the probe data packet carrying the diagnostic flag at at least one forwarding device along the path of the probe data packet, and generating a corresponding event record; wherein the event record includes a probe identifier for identifying the probe data packet and sequence indication information for indicating the order of events; aggregating event records with the same probe identifier, and reconstructing the actual forwarding path of the probe data packet based on the sequence indication information; and determining the fault type and fault location of the network fault based on the event records in the reconstructed actual forwarding path. Therefore, this invention, by acquiring failed request metadata and constructing probe packets carrying diagnostic tags, injects them on demand from the same source network location as the original fault flow. This allows for accurate reproduction of protocol characteristics and forwarding paths in real fault scenarios, effectively overcoming the blind spot of traditional telemetry technology, which cannot detect specific field configuration errors due to the use of fixed probe protocols. Simultaneously, by intercepting tagged probe packets at the forwarding device and generating event records containing probe identifiers and sequence indication information, the actual forwarding path is reconstructed. This enables fault location granularity to penetrate to the specific forwarding device and port level, solving the problem that existing technologies can only locate faults at the device or IP level and cannot identify port-level anomalies within virtual switches. Furthermore, this invention triggers the diagnostic process only on demand after a fault occurs, without continuously sending probe traffic across the entire network, significantly reducing resource overhead. The entire process does not rely on modifying the underlying network device source code or special hardware support, exhibiting excellent non-intrusiveness and deployment compatibility.

[0049] Based on the above embodiments, in this embodiment, the failed request metadata further includes communication identification information for describing the characteristics of failed traffic; Step 100: Obtain metadata about failed requests associated with network failures, including: Step 110: In response to receiving a fault notification, extract the context information associated with the network fault.

[0050] Step 120: Parse the context information to obtain the communication identification information; wherein, the communication identification information includes a five-tuple consisting of the source Internet Protocol address, the destination Internet Protocol address, the source port, the destination port, and the protocol type.

[0051] Specifically, in addition to the source network location information, the failed request metadata also includes communication identification information that describes the characteristics of the failed traffic. This communication identification information is a general term for the core fields that uniquely identify a data flow in the network.

[0052] In step 110, the system first responds to receiving a fault notification, such as an "issue_created" event pushed via HTTP webhook from a ticketing system like Jira or ServiceNow, or an alarm message issued by a monitoring system. The system extracts contextual information associated with the network fault from the fault notification. This contextual information may include the name, IP address, tenant identifier, and error description text of the faulty virtual machine reported by the user, or connection timeout logs and packet loss alarm records captured by the automated monitoring system.

[0053] Subsequently, in step 120, the system parses the extracted context information and extracts communication identification information. This communication identification information is specifically represented as a five-tuple consisting of five fields: source Internet Protocol address, destination Internet Protocol address, source port, destination port, and protocol type (e.g., TCP, UDP, or ICMP). This five-tuple information is of particular importance in a virtualized network environment because forwarding decisions in virtual switches (flow table matching), security group access control rules, load balancer distribution strategies, and ECMP equal cost multipath routing are mostly based on the values ​​of these five fields. Therefore, extracting the five-tuple information of the faulty flow provides the most crucial basis for constructing probe packets that are completely identical in protocol characteristics to the original faulty traffic.

[0054] It should be noted that when the above five fields can be completely parsed from the context information, they are directly used as the five-tuple information; if some fields are missing in the context (for example, only the IP address is available but no port information), the system can use the default value or supplement them through other telemetry methods according to the characteristics of the network environment, so as to ensure that the constructed probe data packet can reproduce the real fault scenario to the greatest extent.

[0055] The virtual network fault diagnosis method provided in this embodiment can accurately capture the core features that drive most forwarding decisions in the virtual network by extracting the five-tuple information of the fault flow, thereby providing a key basis for constructing probe data packets that strictly match the original fault in the protocol field.

[0056] Based on the above embodiments, in this embodiment, step 200, which involves constructing at least one probe data packet based on the failed request metadata, includes: Step 210: Based on the five-tuple information, construct a probe data packet that has the same network layer and transport layer header fields as the original data stream that caused the network failure.

[0057] Step 200 involves setting a diagnostic flag in the probe data packet, including: Step 220: Obtain the preset magic number, the unique probe identifier, and the initialized sequence number; wherein, the magic number is used to identify the probe data packet as diagnostic traffic, the probe identifier is used to associate multiple probe data packets belonging to the same diagnostic process, and the sequence number is used to record the order in which the probe data packet is processed during the forwarding process.

[0058] Step 230: Write the magic number, the probe identifier, and the sequence number into the Internet Protocol Options field of the probe data packet.

[0059] Step 240: If the Internet Protocol Options field is unavailable or discarded by the network device, write the magic number, the probe identifier, and the sequence number into the transport layer protocol options field or application layer payload of the probe data packet.

[0060] Specifically, in step 210, based on the five-tuple information obtained in the preceding steps, one or more probe packets are constructed. These probe packets maintain strict consistency with the original data flow that caused the network failure in the header fields of the network layer and transport layer. For example, they have the same protocol field in the IP header, the same port number field in the TCP or UDP header, and may even optionally copy more granular features such as TCP flags. This ensures that when the probe packets enter the virtual network, they can hit the exact same flow table entries, firewall rules, and load balancing policies as the original faulty flow.

[0061] Subsequently, in step 220, the system acquires three core elements for diagnostic labeling: a preset magic number, a unique probe identifier, and an initialized sequence number. The magic number is a fixed, special value that is unlikely to conflict with normal business data, such as 0x564E5041. Its function is to enable the extended Berkeley packet filter probe program along the route to quickly identify that the data packet belongs to diagnostic traffic rather than regular business traffic. The probe identifier is a randomly generated large integer, such as 1234567890123456789, used to associate multiple probe data packets that may be sent during the same diagnostic process with the same diagnostic task. The sequence number is an integer that increments from zero, used to record the order in which probe data packets flow between forwarding devices. Since the timestamps of each node in the cloud environment are difficult to synchronize precisely, this sequence number provides a sequence determination mechanism that does not rely on a global clock.

[0062] Finally, in step 230, the system writes the aforementioned magic number, probe identifier, and sequence number sequentially into the Internet Protocol Options field of the probe data packet. The Internet Protocol Options field is located after the standard IP header and before the transport layer header.

[0063] It should be noted that if some network devices in the user environment drop or specially process packets with IP options, the system can also choose to write diagnostic tags into the transport layer protocol option field (such as the TCP option field) or the application layer payload as an alternative to ensure the compatibility of the diagnostic mechanism.

[0064] The virtual network fault diagnosis method provided in this embodiment constructs a probe data packet with the same header fields as the original fault flow based on a five-tuple, and writes the magic number, probe identifier, and sequence number into the IP option field to form a unified diagnostic marker. This ensures that the probe traffic can accurately match the fine-grained forwarding rules triggered by the fault, and at the same time provides a sequential basis for subsequent distributed path reconstruction that does not depend on clock synchronization. This effectively overcomes the detection blind spots of traditional probe protocols and realizes accurate event correlation across devices.

[0065] Based on the above embodiments, in this embodiment, step 300, injecting the probe data packet carrying the diagnostic marker into the network from the network location corresponding to the source network location information, includes: Step 310: Determine the source type of the original data stream corresponding to the network fault based on the source network location information; wherein the source type includes virtual machines or containers.

[0066] Step 320: If the source type is a virtual machine or container, obtain the network namespace of the host machine where the virtual machine or container is located, and locate the virtual network device connected to the virtual network card of the virtual machine or container; wherein, the virtual network device is a tap device or a veth device.

[0067] Step 330: Write the probe data packet carrying the diagnostic marker into the virtual network device through the raw socket to simulate the process of sending data packets from inside the virtual machine or container.

[0068] Specifically, in step 310, the system determines the source type of the original data stream corresponding to the network failure based on the previously acquired source network location information. In cloud computing and containerized environments, the source type usually includes virtual machines or containers running on the host machine. Clarifying the source type helps to adopt the correct injection method in the future.

[0069] Next, in step 320, when the source type is confirmed to be a virtual machine or container, the system needs to obtain the network namespace of the host machine where the virtual machine or container resides. Network namespaces are a resource isolation mechanism provided by the Linux kernel. Each network namespace has its own independent network protocol stack, network devices, and routing table. The virtual network interface card (NIC) of a virtual machine or container actually resides within its own network namespace. Simultaneously, the system also needs to locate the virtual network device connected to the virtual network interface card of the virtual machine or container. Specifically, for a virtual machine, this virtual network device is typically a tap device; for a container, this virtual network device is typically a veth device.

[0070] Finally, in step 330, the raw socket is a programming interface that allows user-mode programs to directly construct and send link layer (layer 2) or network layer (layer 3) data packets, bypassing the local TCP / IP protocol stack, thereby enabling precise control over the content of the sent data packets. In this embodiment, probe data packets carrying diagnostic markers are directly written into the aforementioned located tap or veth devices. Since tap and veth devices are essentially virtual network devices, writing data packets to them is equivalent to sending the data packets from inside the associated virtual machine or container. Therefore, this process can perfectly simulate the process of initiating data packet transmission from inside the source of the original fault, without actually logging in or entering the user's virtual machine or container.

[0071] The virtual network fault diagnosis method provided in this embodiment locates the host network namespace and virtual network device according to the source type, and directly writes probe data packets to the tap or veth device using raw sockets. This method can accurately simulate the process of sending data packets from the original fault source without actually entering the user's virtual machine or container, thus balancing the accuracy of diagnosis with the security isolation requirements of the production environment.

[0072] Based on the above embodiments, in this embodiment, step 400 intercepts the probe data packet carrying the diagnostic tag at at least one forwarding device along the probe data packet path and generates a corresponding event record, including: Step 410: On the kernel data processing path of the forwarding device, pre-mount the extended Berkeley packet filter probe program.

[0073] Step 420: When the probe data packet enters the forwarding device, the extended Berkeley packet filter probe program is triggered to parse the header field of the probe data packet to identify whether the diagnostic flag exists.

[0074] Step 430: If the diagnostic marker is present, read the probe identifier and the sequence indication information from the probe data packet, and capture the action information generated by the current forwarding device processing the probe data packet; wherein, the action information includes the inbound port name, the outbound port name, the processing action type, and the timestamp.

[0075] Step 440: Associate the probe identifier, the sequence indication information, the action information, and the device identifier of the current forwarding device to generate the event record, and increment the sequence indication information in the probe data packet according to a preset rule.

[0076] Specifically, in step 410, the system needs to pre-mount the extended Berkeley packet filter probe program on the kernel data processing path of the forwarding device.

[0077] Extended Berkeley Packet Filter (eBPF) is a high-performance, secure, and programmable dynamic tracing technology provided by the Linux kernel. It allows users to inject custom bytecode programs into specific mount points in the kernel without modifying the kernel source code or rebooting the system. The mount point of the probe program varies depending on the type of forwarding device. For example, for Open vSwitch virtual switches, it can be mounted at tracepoint / openvswitch / ovs_do_execute_action; for Linux bridges, it is mounted at kprobe / br_handle_frame_finish; and for IP forwarding in the kernel protocol stack, it is mounted at kprobe / ip_forward.

[0078] Next, in step 420, when the probe packet enters the forwarding device and is processed by the kernel data processing path, the pre-mounted extended Berkeley packet filter probe program is automatically triggered. The probe program first parses the header fields of the probe packet, including the Ethernet header, the Internet Protocol header, and possibly the transport layer header, to check whether there are previously set diagnostic flags, that is, to check whether the Internet Protocol Options field contains a preset magic number.

[0079] In step 430, if the probe program successfully identifies the presence of a diagnostic marker, it reads the probe identifier and sequence indication information from the corresponding fields of the data packet, and captures the action information generated by the current forwarding device when processing the probe data packet. This action information specifically includes: the inbound port name (e.g., which port the data packet entered from in the virtual switch), the outbound port name (e.g., the port from which the data packet was forwarded, or "Dropped" if the data packet was dropped), the processing action type (e.g., forwarding, dropping, encapsulation, or decapsulation), and the timestamp.

[0080] Finally, in step 440, the probe program associates and assembles the probe identifier, sequence indication information, captured action information, and the unique device identifier (e.g., host ID or switch ID) of the current forwarding device to form a structured kernel event record. This event record is then efficiently transferred from kernel space to the user space agent program through the circular buffer mechanism of the extended Berkeley packet filter. At the same time, the probe program increments the sequence indication information in the probe data packet according to preset rules, for example, increasing the sequence number from 5 to 6. This way, when the data packet is forwarded to the next device, the probe program of the next device will read the updated sequence number, thus making the sequence numbers in the event records generated by all devices along the way form a strictly monotonically increasing integer sequence from the source to the destination.

[0081] Furthermore, the method also includes: When the probe data packet undergoes tunnel encapsulation during transmission, the extended Berkeley packet filter probe program triggered at the encapsulation point copies the diagnostic markers, probe identifiers, and sequence indication information from the probe data packet into the header field of the encapsulated new data packet, and increments the sequence indication information. When the probe data packet undergoes tunnel decapsulation during transmission, the extended Berkeley packet filter probe program triggered at the decapsulation point copies the diagnostic marker, probe identifier, and sequence indication information from the header field of the encapsulated data packet to the header field of the decapsulated inner data packet, and increments the sequence indication information.

[0082] Specifically, in cloud computing virtual network environments, in order to achieve tenant isolation and network expansion across the underlying physical network, tunneling technologies such as Virtual Scalable Local Area Networks or Universal Routing Encapsulation Protocols are often used. These technologies encapsulate a new Internet Protocol header and a tunnel header on the outer layer of the original probe data packet, thereby wrapping the original data packet in the inner layer.

[0083] When a probe packet encounters a tunnel encapsulation point during transmission, such as when the vxlan_xmit kernel function is executed on a virtual tunnel endpoint, the extended Berkeley packet filter probe program mounted on that function is triggered. This probe program needs to completely copy the diagnostic flags (i.e., magic number), probe identifier, and current sequence indication information carried in the Internet Protocol Options field of the original probe packet to the Internet Protocol header field of the newly generated encapsulated packet, and then increment the sequence indication information according to a preset rule. The purpose of this is to ensure that the diagnostic information is not blocked in the inner layer due to tunnel encapsulation, so that subsequent physical network devices or peer tunnel decapsulation points can still identify that the packet belongs to diagnostic traffic and continue to generate event records.

[0084] Similarly, when the encapsulated data packet transmitted through the tunnel arrives at the other end and undergoes tunnel decapsulation, such as when the vxlan_rcv kernel function is executed at the receiving end of the Virtual Scalable LAN, the extended Berkeley packet filter probe program mounted on this function will also be triggered. This probe program reads the magic number, probe identifier, and sequence indicator information from the Internet Protocol header field of the outer encapsulated data packet, and then copies this information to the Internet Protocol header field of the inner original data packet after decapsulation, and also increments the sequence indicator information.

[0085] The virtual network fault diagnosis method provided in this embodiment achieves zero-interference tracing of normal service traffic by pre-mounting an extended Berkeley packet filter probe program on the kernel data processing path. Event capture and sequence number increment are triggered only when a diagnostic flag is identified. At the same time, the monotonically increasing sequence number mechanism provides a reliable sequential basis for path reconstruction in a distributed environment without relying on global clock synchronization. By triggering the extended Berkeley packet filter probe program at the tunnel encapsulation and decapsulation points, the diagnostic flag and sequence indication information are copied and incremented between inner and outer layer data packets. This ensures that diagnostic traffic can still be continuously traced when crossing tunnels such as virtual scalable LANs or general route encapsulations, while maintaining the global monotonically increasing sequence number characteristic. Thus, it achieves complete reconstruction of the end-to-end path of multi-layer overlay networks without losing any intermediate hop information.

[0086] Based on the above embodiments, in this embodiment, step 500 aggregates event records with the same probe identifier and reconstructs the actual forwarding path of the probe data packet according to the sequence indication information, including: Step 510: Collect the generated event records from each forwarding device and group event records with the same probe identifier into the same event record set.

[0087] Step 520: Sort the event records in the event record set in ascending order according to the size relationship of the sequence indication information in each event record; wherein, the smaller the value of the sequence indication information, the earlier the event occurred.

[0088] Step 530: Concatenate the sorted event records in sequence, extract the forwarding device identifier, inbound port name, outbound port name, and processing action type corresponding to each event record, and form a complete device sequence and port-level action sequence that the probe data packet passes through from the injection point to the final departure point, as the actual forwarding path.

[0089] Specifically, in step 510, all generated event records are collected from the user-space agent programs deployed on each forwarding device. Each event record contains information such as probe identifier, sequence indication information, forwarding device identifier (e.g., host ID "host-01" or switch ID "switch-02"), inbound port name, outbound port name, processing action type, and timestamp. The system then groups events by probe identifier as the key, and categorizes all event records with the same probe identifier into the same event record set. This means that all event records generated by the same or the same batch of probe packets sent in the same diagnostic process are grouped together, while events from different diagnostic tasks or different probe packets are naturally isolated.

[0090] Next, in step 520, the system sorts the event records in each event record set in ascending order according to the size of the sequence indication information. Since the sequence indication information in the data packet is incremented once by the corresponding extended Berkeley packet filter probe program after passing through each forwarding device during the transmission of the data packet, the smaller the value of the sequence indication information, the earlier the event occurred and the closer it is to the injection point of the data packet, while the larger the value, the later the event occurred and the farther it is from the injection point of the data packet. Through this sorting based on sequence number, the system can accurately restore the order of events without relying on the clock synchronization between the forwarding devices.

[0091] Finally, in step 530, the system concatenates the sorted event records in ascending order of sequence number, and extracts key fields such as forwarding device identifier, inbound port name, outbound port name, and processing action type from each event record to form a complete, hop-by-hop descriptive information chain.

[0092] For example, the sorted sequence of events might show that: the probe packet is first sent from the source virtual NIC of the injection point, passes through the host's tap device into the port of the Open vSwitch bridge: tap32a, then leaves from port vxlan_sys_4789 and is encapsulated through a virtual extensible LAN tunnel, then is decapsulated on the remote host and enters another Open vSwitch bridge port vxlan_sys_4789, and finally leaves from port tap50b and reaches the virtual NIC of the destination virtual machine.

[0093] The virtual network fault diagnosis method provided in this embodiment aggregates scattered event records using probe identifiers as keywords and sorts and concatenates them using sequence indication information. Without relying on the clock synchronization of each forwarding device, it reconstructs the actual forwarding path containing complete device sequences and port-level action sequences, thereby refining the fault location granularity from the traditional device level or IP level to the specific port level of the virtual switch.

[0094] Based on the above embodiments, in this embodiment, before step 600 determines the fault type and fault location of the network fault based on the event records in the reconstructed actual forwarding path, the method further includes: Obtain cloud platform configuration information for the virtual network; Based on the cloud platform configuration information, an expected forwarding path for the probe data packet to be transmitted in the virtual network is generated; wherein, the expected forwarding path is used to describe the sequence of devices and forwarding actions that the probe data packet should pass through according to the network configuration logic.

[0095] Step 600, based on the event records in the reconstructed actual forwarding path, determines the fault type and location of the network fault, including: Step 610: When there are multiple actual forwarding paths for the same detection identifier, compare the length and destination of the multiple actual forwarding paths.

[0096] Step 620: If all actual forwarding paths terminate at the same forwarding device and the processing action type in the event log of the forwarding device is "drop", or if all actual forwarding paths fail to reach the destination network card, determine the fault type as "disconnection" and locate the terminated forwarding device as the fault location.

[0097] Step 630: If all actual forwarding paths have reached the destination completely, and the processing time on a certain path exceeds a preset threshold, the fault type is determined to be delay, and the forwarding device whose processing time exceeds the preset threshold is located as the fault location.

[0098] Step 640: If some actual forwarding paths reach the destination completely and some actual forwarding paths terminate midway in the multiple actual forwarding paths, the fault type is determined to be packet loss, and the end forwarding device of the actual forwarding path that terminates midway is located as the fault location.

[0099] Step 650: If the lengths of the multiple actual forwarding paths are inconsistent and all reach the destination completely, or if the reconstructed actual forwarding path is inconsistent with the expected forwarding path generated according to the cloud platform configuration, the fault type is determined to be path deviation.

[0100] It should be noted that the system obtains the cloud platform configuration information of the virtual network from the cloud platform's management components. This configuration information includes, but is not limited to, the routing table, security group rules, access control lists, and load balancing policies of the virtual private cloud. Based on this configuration information, the system can logically deduce the forwarding path that the probe data packets should take in the network according to the design intent, i.e., the expected forwarding path. This path describes the sequence of devices that should pass through from the source end to the destination end and the forwarding actions that should be performed on each device.

[0101] In the actual diagnostic phase, step 610 first determines whether there are multiple actual forwarding paths for the same probe identifier. This usually occurs when multiple probe packets are sent during the diagnostic process or when the same batch of probe packets takes different paths due to mechanisms such as equivalent multipath. If there are multiple paths, the lengths and destinations of these paths are compared.

[0102] Steps 620 to 650 determine the fault type based on different scenarios: If all actual forwarding paths terminate at the same forwarding device and the processing action type in the device's event log is "dropped," or if all paths fail to reach the destination network card, it is determined to be a disconnection fault, meaning there is a stable blocking point in the network, and the terminated forwarding device is identified as the fault location; if all actual forwarding paths reach the destination completely, but the calculated processing time on a certain path exceeds a user-preset threshold (e.g., 100 milliseconds), it is determined to be a latency fault, and the specific forwarding device with the excessive processing time is identified as the fault location; when multiple actual forwarding paths... If some paths in a network reach the destination completely while others terminate midway, it is considered a packet loss fault, usually caused by port congestion, link oscillation, or random packet loss. The end-of-path forwarding device of the terminated path is located as the fault location. Finally, if multiple actual forwarding paths have different lengths but all reach the destination completely, or if the reconstructed actual forwarding path is inconsistent with the expected forwarding path generated according to the cloud platform configuration, it is considered a path deviation fault. This diagnostic result suggests to maintenance personnel that either there are multiple feasible paths in the network and the current fault may have been recovered, or there is a hidden logical fault caused by static configuration errors or inconsistent forwarding table entries.

[0103] The virtual network fault diagnosis method provided in this embodiment generates expected forwarding paths by introducing cloud platform configuration information and compares them with the actual reconstructed paths in multiple dimensions. It can accurately distinguish four types of faults: disconnection, latency, packet loss, and path deviation. In particular, it can discover hidden logical faults caused by static configuration errors or inconsistent forwarding table entries, thereby providing operation and maintenance personnel with root cause localization capabilities far exceeding those of traditional connectivity detection.

[0104] Figure 2 This is a complete flowchart of the virtual network fault diagnosis method provided by the present invention. The following is a summary of the process. Figure 2 The present invention provides a complete description of the virtual network fault diagnosis method.

[0105] like Figure 2As shown, the top layer of the system architecture aggregates various raw data from the work order system, telemetry system, and end-to-end tracing system. Specifically, this includes user-reported fault work orders, telemetry logs, and existing end-to-end tracing data. This data is transmitted to the failure request metadata collector, which extracts key characteristics of the failed traffic by parsing the work order content or polling the telemetry interface. These characteristics include five-tuple information such as the name of the virtual machine or container that failed, the source and destination Internet Protocol addresses, the source and destination ports, and the protocol type. At the same time, the source network location information is also obtained. Subsequently, at the core execution layer, the failure request replay module constructs a probe packet that perfectly matches the original failure request in terms of protocol characteristics at the corresponding network location based on the extracted failure traffic characteristics. The module then writes the magic number, a unique probe identifier, and an initialized sequence number into the Internet Protocol Options field of the probe packet as diagnostic markers. The replay module then directly writes the probe packet carrying the diagnostic markers into the tap device or veth device connected to the source virtual machine or source container virtual network card through the raw socket. This simulates the process of sending data packets from the source end in a multi-node environment, thus accurately reproducing the failure request. As these probe packets are transmitted through the network and pass through various forwarding devices (such as virtual switches, virtual routers, Linux bridges, etc.), pre-deployed eBPF hooks within each node are triggered. These eBPF programs parse the header fields of the probe packets, confirm they are diagnostic traffic by identifying the magic number, read the probe identifier and current sequence number, and capture the action information generated by the forwarding device processing the packet. They then associate the probe identifier, sequence number, action information, and device identifier to generate an event record, incrementing the sequence number in the packet. These event records are temporarily stored in the eBPF event buffer. Agents (user-space agents) on multiple nodes are responsible for continuously pulling these event records from their respective node's kernel buffer and transmitting them out-of-band to the path generator via a dedicated management network. After receiving all event records, the path generator first aggregates them using the probe identifier as the key, grouping event records with the same probe identifier into the same set. Then, it sorts them in ascending order according to the sequence number in each event record and uses the monotonically increasing property of the sequence number to concatenate the event records in sequence. It extracts the forwarding device identifier, inbound port name, outbound port name, and processing action type corresponding to each event, thereby reconstructing the complete device sequence and port-level action sequence that the probe data packet passes through from the injection point to the final departure point, forming a visualized actual forwarding path of the failed request.Finally, the path generator compares the actual forwarding path with the expected forwarding path derived from the cloud platform configuration information, and combines the consistency analysis of multiple replay paths to automatically determine the fault type as disconnection, latency, packet loss or path deviation, and accurately locates the fault location to the specific forwarding device and its virtual port, thus clearly showing the propagation trajectory of the fault in the distributed environment and helping operation and maintenance personnel to quickly locate the root cause.

[0106] The virtual network fault diagnosis device provided by the present invention is described below. The virtual network fault diagnosis device described below can be referred to in correspondence with the virtual network fault diagnosis method described above.

[0107] Figure 3 This is a schematic diagram of the structure of the virtual network fault diagnosis device provided by the present invention, as shown below. Figure 3 As shown, the virtual network fault diagnosis device provided by the present invention includes: The acquisition module 301 is used to acquire failed request metadata associated with network failures; wherein, the failed request metadata includes source network location information; The tagging module 302 is configured to construct at least one probe data packet based on the failed request metadata, and set a diagnostic tag in the probe data packet; wherein the diagnostic tag is used to identify the probe data packet as diagnostic traffic; Injection module 303 is used to inject probe data packets carrying the diagnostic markers into the network from a network location corresponding to the source network location information; The generation module 304 is configured to intercept the probe data packet carrying the diagnostic tag at at least one forwarding device along the probe data packet path and generate a corresponding event record; wherein, the event record includes a probe identifier for identifying the probe data packet to which it belongs, and sequence indication information for indicating the order in which the events occur; The reconstruction module 305 is used to aggregate event records with the same probe identifier and reconstruct the actual forwarding path of the probe data packet according to the sequence indication information; The diagnostic module 306 is used to determine the fault type and fault location of the network fault based on the event records in the reconstructed actual forwarding path.

[0108] The virtual network fault diagnosis device provided by this invention acquires failure request metadata associated with a network fault, wherein the failure request metadata includes source network location information; constructs at least one probe data packet based on the failure request metadata, and sets a diagnostic flag in the probe data packet; wherein the diagnostic flag is used to identify the probe data packet as diagnostic traffic; injects the probe data packet carrying the diagnostic flag into the network from a network location corresponding to the source network location information; intercepts the probe data packet carrying the diagnostic flag at at least one forwarding device along the path of the probe data packet, and generates a corresponding event record; wherein the event record includes a probe identifier for identifying the probe data packet to which it belongs, and sequence indication information for indicating the order of events; aggregates event records with the same probe identifier, and reconstructs the actual forwarding path of the probe data packet based on the sequence indication information; and determines the fault type and fault location of the network fault based on the event records in the reconstructed actual forwarding path. Therefore, this invention, by acquiring failed request metadata and constructing probe packets carrying diagnostic tags, injects them on demand from the same source network location as the original fault flow. This allows for accurate reproduction of protocol characteristics and forwarding paths in real fault scenarios, effectively overcoming the blind spot of traditional telemetry technology, which cannot detect specific field configuration errors due to the use of fixed probe protocols. Simultaneously, by intercepting tagged probe packets at the forwarding device and generating event records containing probe identifiers and sequence indication information, the actual forwarding path is reconstructed. This enables fault location granularity to penetrate to the specific forwarding device and port level, solving the problem that existing technologies can only locate faults at the device or IP level and cannot identify port-level anomalies within virtual switches. Furthermore, this invention triggers the diagnostic process only on demand after a fault occurs, without continuously sending probe traffic across the entire network, significantly reducing resource overhead. The entire process does not rely on modifying the underlying network device source code or special hardware support, exhibiting excellent non-intrusiveness and deployment compatibility.

[0109] Based on the above embodiments, in this embodiment, the failed request metadata further includes communication identification information for describing the characteristics of failed traffic; The acquisition module 302 is specifically used for: In response to receiving a fault notification, extract the context information associated with the network fault; The context information is parsed to obtain the communication identification information; wherein, the communication identification information includes a five-tuple consisting of the source Internet Protocol address, the destination Internet Protocol address, the source port, the destination port, and the protocol type.

[0110] Based on the above embodiments, in this embodiment, the device further includes a construction module, specifically used for: Based on the quintuple information, a probe data packet with the same network layer and transport layer header fields as the original data stream that caused the network failure is constructed.

[0111] Based on the above embodiments, in this embodiment, the marking module 302 is specifically used for: Obtain a preset magic number, a unique probe identifier, and an initialized sequence number; wherein, the magic number is used to identify the probe data packet as diagnostic traffic, the probe identifier is used to associate multiple probe data packets belonging to the same diagnostic process, and the sequence number is used to record the order in which the probe data packet is processed during forwarding; Write the magic number, the probe identifier, and the sequence number into the Internet Protocol Options field of the probe data packet.

[0112] Based on the above embodiments, in this embodiment, the marking module 302 is further configured to: If the Internet Protocol Options field is unavailable or discarded by the network device, the magic number, the probe identifier, and the sequence number are written into the transport layer protocol options field or application layer payload of the probe data packet.

[0113] Based on the above embodiments, in this embodiment, the injection module 303 is specifically used for: Based on the source network location information, determine the source type of the original data stream corresponding to the network fault; wherein, the source type includes virtual machines or containers; When the source type is a virtual machine or container, obtain the network namespace of the host machine where the virtual machine or container is located, and locate the virtual network device connected to the virtual network interface card of the virtual machine or container; wherein, the virtual network device is a tap device or a veth device; By using raw sockets, probe data packets carrying the diagnostic tags are written to the virtual network device to simulate the process of initiating data packet transmission from inside the virtual machine or container.

[0114] Based on the above embodiments, in this embodiment, the generation module 304 is specifically used for: An extended Berkeley packet filter probe program is pre-mounted on the kernel data processing path of the forwarding device. When the probe packet enters the forwarding device, the extended Berkeley packet filter probe program is triggered to parse the header field of the probe packet to identify whether the diagnostic flag exists; In the presence of the diagnostic marker, the probe identifier and the sequence indication information are read from the probe data packet, and the action information generated by the current forwarding device in processing the probe data packet is captured; wherein, the action information includes the inbound port name, the outbound port name, the processing action type, and the timestamp; The event record is generated by associating the probe identifier, the sequence indication information, the action information, and the device identifier of the current forwarding device, and the sequence indication information in the probe data packet is incremented according to a preset rule.

[0115] Based on the above embodiments, in this embodiment, the device further includes an incrementing module, specifically used for: When the probe data packet undergoes tunnel encapsulation during transmission, the extended Berkeley packet filter probe program triggered at the encapsulation point copies the diagnostic markers, probe identifiers, and sequence indication information from the probe data packet into the header field of the encapsulated new data packet, and increments the sequence indication information. When the probe data packet undergoes tunnel decapsulation during transmission, the extended Berkeley packet filter probe program triggered at the decapsulation point copies the diagnostic marker, probe identifier, and sequence indication information from the header field of the encapsulated data packet to the header field of the decapsulated inner data packet, and increments the sequence indication information.

[0116] Based on the above embodiments, in this embodiment, the reconstruction module 305 is specifically used for: Event records generated from various forwarding devices are collected, and event records with the same probe identifier are grouped into the same event record set; Based on the size relationship of the sequence indication information in each event record, the event records in the event record set are sorted in ascending order; wherein, the smaller the value of the sequence indication information, the earlier the event occurred; The sorted event records are concatenated sequentially, and the forwarding device identifier, inbound port name, outbound port name, and processing action type corresponding to each event record are extracted to form a complete device sequence and port-level action sequence that the probe data packet passes through from the injection point to the final departure point, which serves as the actual forwarding path.

[0117] Based on the above embodiments, in this embodiment, the device further includes a predictive generation module, specifically used for: Before determining the fault type and location of the network fault based on the event records in the reconstructed actual forwarding path, Obtain cloud platform configuration information for the virtual network; Based on the cloud platform configuration information, an expected forwarding path for the probe data packet to be transmitted in the virtual network is generated; wherein, the expected forwarding path is used to describe the sequence of devices and forwarding actions that the probe data packet should pass through according to the network configuration logic.

[0118] Based on the above embodiments, in this embodiment, the diagnostic module 306 is specifically used for: When there are multiple actual forwarding paths for the same detection identifier, compare the length and endpoint of the multiple actual forwarding paths; If all actual forwarding paths terminate at the same forwarding device and the processing action type in the event log of the forwarding device is "drop", or if all actual forwarding paths fail to reach the destination network card, the fault type is determined to be disconnection, and the terminated forwarding device is located as the fault location. If all actual forwarding paths reach the destination completely, and the processing time on a certain path exceeds a preset threshold, the fault type is determined to be delay, and the forwarding device whose processing time exceeds the preset threshold is located as the fault location. If some of the actual forwarding paths reach the destination completely while others terminate midway, the fault type is determined to be packet loss, and the terminal forwarding device of the terminated actual forwarding path is located as the fault location. If the lengths of the multiple actual forwarding paths are inconsistent and all reach the destination completely, or if the reconstructed actual forwarding path is inconsistent with the expected forwarding path generated according to the cloud platform configuration, the fault type is determined to be path deviation.

[0119] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device can be a robot or other electronic device. This electronic device may include: a processor 410, a communications interface 420, a memory 430, and a communication bus 440. The processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can call logical instructions from the memory 430 to execute a virtual network fault diagnosis method, including: Obtain failed request metadata associated with network failure; wherein, the failed request metadata includes source network location information; At least one probe packet is constructed based on the failed request metadata, and a diagnostic flag is set in the probe packet; wherein the diagnostic flag is used to identify the probe packet as diagnostic traffic; The probe data packet carrying the diagnostic marker is injected into the network from the network location corresponding to the source network location information; At at least one forwarding device along the path of the probe data packet, the probe data packet carrying the diagnostic tag is intercepted, and a corresponding event record is generated; wherein, the event record includes a probe identifier for identifying the probe data packet to which it belongs, and sequence indication information for indicating the order in which the events occur; Event records with the same probe identifier are aggregated, and the actual forwarding path of the probe data packet is reconstructed based on the sequence indication information; Based on the event records in the reconstructed actual forwarding path, the fault type and fault location of the network fault are determined.

[0120] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0121] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program, the computer program being able to be stored on a non-transitory computer-readable storage medium, and when the computer program is executed by a processor, the computer being able to execute the virtual network fault diagnosis method provided by the above methods, including: Obtain failed request metadata associated with network failure; wherein, the failed request metadata includes source network location information; At least one probe packet is constructed based on the failed request metadata, and a diagnostic flag is set in the probe packet; wherein the diagnostic flag is used to identify the probe packet as diagnostic traffic; The probe data packet carrying the diagnostic marker is injected into the network from the network location corresponding to the source network location information; At at least one forwarding device along the path of the probe data packet, the probe data packet carrying the diagnostic tag is intercepted, and a corresponding event record is generated; wherein, the event record includes a probe identifier for identifying the probe data packet to which it belongs, and sequence indication information for indicating the order in which the events occur; Event records with the same probe identifier are aggregated, and the actual forwarding path of the probe data packet is reconstructed based on the sequence indication information; Based on the event records in the reconstructed actual forwarding path, the fault type and fault location of the network fault are determined.

[0122] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the virtual network fault diagnosis method provided by the methods described above, including: Obtain failed request metadata associated with network failure; wherein, the failed request metadata includes source network location information; At least one probe packet is constructed based on the failed request metadata, and a diagnostic flag is set in the probe packet; wherein the diagnostic flag is used to identify the probe packet as diagnostic traffic; The probe data packet carrying the diagnostic marker is injected into the network from the network location corresponding to the source network location information; At at least one forwarding device along the path of the probe data packet, the probe data packet carrying the diagnostic tag is intercepted, and a corresponding event record is generated; wherein, the event record includes a probe identifier for identifying the probe data packet to which it belongs, and sequence indication information for indicating the order in which the events occur; Event records with the same probe identifier are aggregated, and the actual forwarding path of the probe data packet is reconstructed based on the sequence indication information; Based on the event records in the reconstructed actual forwarding path, the fault type and fault location of the network fault are determined.

[0123] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0124] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0125] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for diagnosing virtual network faults, characterized in that, include: Obtain failed request metadata associated with network failure; wherein, the failed request metadata includes source network location information; At least one probe packet is constructed based on the failed request metadata, and a diagnostic flag is set in the probe packet; wherein the diagnostic flag is used to identify the probe packet as diagnostic traffic; The probe data packet carrying the diagnostic marker is injected into the network from the network location corresponding to the source network location information; At at least one forwarding device along the path of the probe data packet, the probe data packet carrying the diagnostic tag is intercepted, and a corresponding event record is generated; wherein, the event record includes a probe identifier for identifying the probe data packet to which it belongs, and sequence indication information for indicating the order in which the events occur; Event records with the same probe identifier are aggregated, and the actual forwarding path of the probe data packet is reconstructed based on the sequence indication information; Based on the event records in the reconstructed actual forwarding path, the fault type and fault location of the network fault are determined.

2. The virtual network fault diagnosis method according to claim 1, characterized in that, The failed request metadata also includes communication identification information used to describe the characteristics of the failed traffic; The acquisition of failed request metadata associated with network failures includes: In response to receiving a fault notification, extract the context information associated with the network fault; The context information is parsed to obtain the communication identification information; wherein, the communication identification information includes a five-tuple consisting of the source Internet Protocol address, the destination Internet Protocol address, the source port, the destination port, and the protocol type.

3. The virtual network fault diagnosis method according to claim 2, characterized in that, Constructing at least one probe packet based on the failed request metadata includes: Based on the quintuple information, a probe data packet with the same network layer and transport layer header fields as the original data stream that caused the network failure is constructed.

4. The virtual network fault diagnosis method according to claim 1, characterized in that, Setting diagnostic markers in the probe data packet includes: Obtain a preset magic number, a unique probe identifier, and an initialized sequence number; wherein, the magic number is used to identify the probe data packet as diagnostic traffic, the probe identifier is used to associate multiple probe data packets belonging to the same diagnostic process, and the sequence number is used to record the order in which the probe data packet is processed during forwarding; Write the magic number, the probe identifier, and the sequence number into the Internet Protocol Options field of the probe data packet.

5. The virtual network fault diagnosis method according to claim 4, characterized in that, Setting a diagnostic marker in the probe data packet further includes: If the Internet Protocol Options field is unavailable or discarded by the network device, the magic number, the probe identifier, and the sequence number are written into the transport layer protocol options field or application layer payload of the probe data packet.

6. The virtual network fault diagnosis method according to claim 1, characterized in that, The step of injecting the probe data packet carrying the diagnostic marker into the network from the network location corresponding to the source network location information includes: Based on the source network location information, determine the source type of the original data stream corresponding to the network fault; wherein, the source type includes virtual machines or containers; When the source type is a virtual machine or container, obtain the network namespace of the host machine where the virtual machine or container is located, and locate the virtual network device connected to the virtual network interface card of the virtual machine or container; wherein, the virtual network device is a tap device or a veth device; By using raw sockets, probe data packets carrying the diagnostic tags are written to the virtual network device to simulate the process of initiating data packet transmission from inside the virtual machine or container.

7. The virtual network fault diagnosis method according to claim 1, characterized in that, The step of intercepting the probe data packet carrying the diagnostic tag at at least one forwarding device along the probe data packet path and generating a corresponding event record includes: An extended Berkeley packet filter probe program is pre-mounted on the kernel data processing path of the forwarding device. When the probe packet enters the forwarding device, the extended Berkeley packet filter probe program is triggered to parse the header field of the probe packet to identify whether the diagnostic flag exists; In the presence of the diagnostic marker, the probe identifier and the sequence indication information are read from the probe data packet, and the action information generated by the current forwarding device in processing the probe data packet is captured; wherein, the action information includes the inbound port name, the outbound port name, the processing action type, and the timestamp; The event record is generated by associating the probe identifier, the sequence indication information, the action information, and the device identifier of the current forwarding device, and the sequence indication information in the probe data packet is incremented according to a preset rule.

8. The virtual network fault diagnosis method according to claim 7, characterized in that, The method further includes: When the probe data packet undergoes tunnel encapsulation during transmission, the extended Berkeley packet filter probe program triggered at the encapsulation point copies the diagnostic markers, probe identifiers, and sequence indication information from the probe data packet into the header field of the encapsulated new data packet, and increments the sequence indication information. When the probe data packet undergoes tunnel decapsulation during transmission, the extended Berkeley packet filter probe program triggered at the decapsulation point copies the diagnostic marker, probe identifier, and sequence indication information from the header field of the encapsulated data packet to the header field of the decapsulated inner data packet, and increments the sequence indication information.

9. The virtual network fault diagnosis method according to claim 1, characterized in that, The aggregation of event records with the same probe identifier, and the reconstruction of the actual forwarding path of the probe data packet based on the sequence indication information, includes: Event records generated from various forwarding devices are collected, and event records with the same probe identifier are grouped into the same event record set; Based on the size relationship of the sequence indication information in each event record, the event records in the event record set are sorted in ascending order; wherein, the smaller the value of the sequence indication information, the earlier the event occurred; The sorted event records are concatenated sequentially, and the forwarding device identifier, inbound port name, outbound port name, and processing action type corresponding to each event record are extracted to form a complete device sequence and port-level action sequence that the probe data packet passes through from the injection point to the final departure point, which serves as the actual forwarding path.

10. The virtual network fault diagnosis method according to claim 1, characterized in that, Before determining the fault type and location of the network fault based on the event records in the reconstructed actual forwarding path, the method further includes: Obtain cloud platform configuration information for the virtual network; Based on the cloud platform configuration information, an expected forwarding path for the probe data packet to be transmitted in the virtual network is generated; wherein, the expected forwarding path is used to describe the sequence of devices and forwarding actions that the probe data packet should pass through according to the network configuration logic.

11. The virtual network fault diagnosis method according to claim 10, characterized in that, The event records in the reconstructed actual forwarding path are used to determine the fault type and location of the network fault, including: When there are multiple actual forwarding paths for the same detection identifier, compare the length and endpoint of the multiple actual forwarding paths; If all actual forwarding paths terminate at the same forwarding device and the processing action type in the event log of the forwarding device is "drop", or if all actual forwarding paths fail to reach the destination network card, the fault type is determined to be disconnection, and the terminated forwarding device is located as the fault location. If all actual forwarding paths reach the destination completely, and the processing time on a certain path exceeds a preset threshold, the fault type is determined to be delay, and the forwarding device whose processing time exceeds the preset threshold is located as the fault location. If some of the actual forwarding paths reach the destination completely while others terminate midway, the fault type is determined to be packet loss, and the terminal forwarding device of the terminated actual forwarding path is located as the fault location. If the lengths of the multiple actual forwarding paths are inconsistent and all reach the destination completely, or if the reconstructed actual forwarding path is inconsistent with the expected forwarding path generated according to the cloud platform configuration, the fault type is determined to be path deviation.

12. A virtual network fault diagnosis device, characterized in that, include: The acquisition module is used to acquire failed request metadata associated with network failures; wherein, the failed request metadata includes source network location information; A tagging module is configured to construct at least one probe data packet based on the failed request metadata, and set a diagnostic tag in the probe data packet; wherein the diagnostic tag is used to identify the probe data packet as diagnostic traffic; An injection module is used to inject probe data packets carrying the diagnostic markers into the network from a network location corresponding to the source network location information; The generation module is configured to intercept the probe data packet carrying the diagnostic tag at at least one forwarding device along the path of the probe data packet, and generate a corresponding event record; wherein the event record includes a probe identifier for identifying the probe data packet to which it belongs, and sequence indication information for indicating the order in which the events occur; The reconstruction module is used to aggregate event records with the same probe identifier and reconstruct the actual forwarding path of the probe data packet according to the sequence indication information; The diagnostic module is used to determine the fault type and location of the network fault based on the event records in the reconstructed actual forwarding path.

Images