A network service fault tracing method and device, electronic equipment and program product

Abstract

The application discloses a network service fault tracing method and device, electronic equipment and program product. The method comprises the following steps: acquiring a multi-branch forwarding data packet through a network node, generating a branch identifier for each outgoing interface of the network node; performing IOAM information encapsulation processing on the data packet based on the branch identifier to obtain an initial packet, and transmitting the initial packet to a downstream node; performing encapsulation processing on the initial packet by using a hierarchical coding rule through the downstream node to obtain a target packet; and performing path analysis and fault positioning processing on the target packet to obtain a fault path report. The application embodiment can improve the fault tracing efficiency of the network service, and can be widely applied to the intelligent operation and maintenance technical field.

Description

Technical Field

[0001] This application relates to the field of intelligent operation and maintenance technology, and in particular to a method, device, electronic device and program product for tracing network service faults. Background Technology

[0002] With the rapid development of cloud computing and the Industrial Internet, multicast services and unicast forwarding scenarios are becoming increasingly common, significantly increasing the dependence of service traffic on link reliability. Among related technologies, flow-following detection is used for node-level fault monitoring. However, in practical applications, it has been found that these technologies can only locate branch nodes and cannot distinguish specific branch links, affecting the efficiency of fault analysis for network services.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, electronic device, and program product for tracing network service faults, which can improve the efficiency of handling network service faults.

[0005] To achieve the above objectives, one aspect of this application proposes a method for tracing network service faults, the method comprising: Data packets forwarded by multiple branches are obtained through network nodes, and a branch identifier is generated for each outgoing interface of the network node; The data packet is encapsulated with IOAM information based on the branch identifier to obtain an initial packet, and the initial packet is transmitted to the downstream node. The initial message is encapsulated by the downstream node using a hierarchical encoding rule to obtain the target message; The target message is subjected to path analysis and fault location processing to obtain a fault path report.

[0006] In some embodiments, obtaining multi-branch forwarded data packets through network nodes and generating branch identifiers for each outgoing interface of the network node includes the following steps: When the network node detects that the data packet has multi-branch forwarding behavior, it determines the outgoing interface used to forward the data packet; The physical identifier string of the outgoing interface is encoded and converted into a byte stream, and the byte stream is hashed and compressed to obtain the branch identifier.

[0007] In some embodiments, the step of encapsulating the data packet with IOAM information based on the branch identifier to obtain an initial packet, and transmitting the initial packet to the downstream node, includes the following steps: The option unit is constructed based on the branch identifier and the status bit. The option unit, combined with IOAM information, is embedded into the destination option header of the data packet, encapsulated to obtain an initial packet, and the initial packet is transmitted to the downstream node.

[0008] In some embodiments, the encapsulation of the initial packet using a hierarchical encoding rule at the downstream node to obtain the target packet includes the following steps: The outgoing interface of the downstream node is determined based on the initial message; The sub-branch identifier is obtained by identifying the output interface of the downstream node; The sub-branch identifier and the branch identifier of the initial message are combined to obtain a hierarchical identifier, and the initial message is encapsulated according to the hierarchical identifier to obtain the target message.

[0009] In some embodiments, the step of performing path analysis and fault location processing on the target message to obtain a fault path report includes the following steps: The identifier field of the target message is parsed to obtain identifier data for different paths; The hierarchical relationship of the identification data is identified to generate a path mapping table; A multi-branch tree structure is constructed based on the path mapping table, and the multi-branch tree structure is associated with the network topology to obtain an association mapping table; Based on the association mapping table, time sequence analysis and fault location are performed on target messages with the same identifier data to obtain the fault path report.

[0010] In some embodiments, the step of performing time-series analysis and fault location on target packets with the same identifier data based on the association mapping table to obtain the fault path report includes the following steps: The transmission link of target messages with the same identifier data is determined based on the association mapping table; The transmission link is split into branch links, and time-series data is obtained by collecting data from the branch links. The time series data is analyzed and compared to obtain the fault location results; Generate a report title and basic information based on the fault location results; Based on the fault location results, the fault path is extracted, and the fault path is visualized topologically to obtain an abnormal branch details table; The fault location results are analyzed for fault causes, and the fault path report is generated by combining the report title, basic information and the abnormal branch details table for visualization.

[0011] In some embodiments, the step of performing time-series analysis and comparison on the time-series data to obtain fault location results includes the following steps: A time series trend chart is drawn based on the time series data; Based on the time-series trend chart, anomalies are compared between adjacent link segments to locate the fault initiation position. The fault location result is obtained by performing link location on the fault starting position according to the association mapping table.

[0012] To achieve the above objectives, another aspect of this application provides a network service fault tracing device, the device comprising: The identifier generation module is used to obtain multi-branch forwarded data packets through network nodes and generate a branch identifier for each outgoing interface of the network node. An initial encapsulation module is used to encapsulate the data packet with IOAM information based on the branch identifier to obtain an initial packet, and transmit the initial packet to the downstream node; The layered encapsulation module is used to encapsulate the initial message using layered encoding rules through the downstream node to obtain the target message; The fault location module is used to perform path analysis and fault location processing on the target message to obtain a fault path report.

[0013] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0014] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0015] To achieve the above objectives, another aspect of this application provides a computer program product that, when executed by a processor, implements the aforementioned method.

[0016] The embodiments of this application include at least the following beneficial effects: This application provides a network service fault tracing method, apparatus, electronic device, and program product. This application obtains multi-branch forwarded data packets through network nodes, generates branch identifiers for each outgoing interface of the network node, and can lock the information of the packet on the entire forwarding link through the branch identifiers. Furthermore, this application performs IOAM information encapsulation processing on the data packets based on the branch identifiers to obtain the initial packet, and transmits the initial packet to the downstream node; the downstream node encapsulates the initial packet using hierarchical coding rules to obtain the target packet, which can identify the multi-branch scenario path, establish end-to-end mapping, and improve the granularity of fault location; this application performs fault location and root cause tracing through branch identifiers, which can improve the efficiency of fault handling for network services. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of an implementation environment provided in the embodiments of this application; Figure 2 This is a flowchart of a network service fault tracing method provided in an embodiment of this application; Figure 3 yes Figure 2 The flowchart of step S201 in the text; Figure 4 yes Figure 2 The flowchart of step S202 in the document; Figure 5 yes Figure 2 The flowchart of step S203 in the process; Figure 6 This is a schematic diagram of a recursive analysis provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a network service fault tracing device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0019] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0020] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0023] 1) In-band Operation, Administration, and Maintenance (iOAM): This is a network measurement and monitoring technology. It samples service traffic in real time and at high speed, adds IOAM information (metadata, including device ID, ingress / egress interface, timestamp, etc.) to the sampled data, and then actively sends the sampled data to an analyzer for analysis, thereby achieving real-time perception and monitoring of the network's operating status.

[0024] 2) Ethernet Virtual Private Network (EVPN): It is a Layer 2 VPN technology based on the BGP protocol (Border Gateway Protocol). Its core is to realize flexible deployment and efficient management of Ethernet services through the control plane.

[0025] 3) Cyclic Redundancy Check 8-bit (CRC-8) Algorithm: CRC-8 is a lightweight branch of the Cyclic Redundancy Check (CRC) family of technologies. Its core function is to map input data of arbitrary length (such as strings or byte streams) into a fixed 8-bit (1 byte) output value (usually called "CRC value", "hash value" or "check code") through specific mathematical operations. It has both data integrity verification and lightweight data compression capabilities, and is widely used in network protocols, device identification generation, and stored data verification scenarios.

[0026] With the rapid development of cloud computing and the Industrial Internet, multicast services (such as video conferencing multicast distribution and industrial control command cluster transmission) and unicast branch forwarding scenarios (such as EVPN multi-tenant network branch routing) are becoming increasingly common. Network topologies are exhibiting characteristics of "multi-branch and highly dynamic," and the dependence of service traffic on link reliability has significantly increased. Against this backdrop, operation and maintenance work faces higher requirements: not only must end-to-end fault detection be achieved, but also the precise location of specific faulty links in branch forwarding scenarios must be ensured to guarantee the continuous operation of critical services.

[0027] Among related technologies, iOAM (In-Stream Detection) technology can achieve node-level fault monitoring, but it has significant shortcomings in multicast replication or unicast branch forwarding scenarios: 1. Coarse-grained fault location: It can only locate branch nodes (such as group replication devices) and cannot distinguish specific branch links (such as downstream paths corresponding to different egress interfaces). 2. Lack of cross-branch data association: The lack of a hop-by-hop data association mechanism for each sub-path after a branch makes it difficult to troubleshoot multi-link failures under the same branch node; 3. Insufficient overhead control: Traditional solutions improve positioning accuracy by adding header fields or high-frequency sampling, which leads to a significant increase in network overhead.

[0028] These problems severely restrict the improvement of operation and maintenance capabilities and fail to meet the core requirements of "precise, low-cost, and highly compatible" fault tracing in high-reliability and sensitive scenarios such as cloud networks and industrial control.

[0029] In view of this, this application provides a network service fault tracing method, device, electronic device, and program product. This application generates a branch identifier for each outgoing interface of a network node and inherits and extends the identifier to downstream nodes. It adopts a lightweight interaction mechanism that encapsulates packets using hierarchical encoding rules. Combined with dynamic hash compression technology and iOAM header reserved field reuse design, it refines fault location from "branch node" to "specific branch link". At the same time, it controls extremely low network overhead and ensures smooth deployment of IPv4 / IPv6 networks. It can provide an efficient fault tracing solution for reliability-sensitive scenarios such as cloud networks and industrial control.

[0030] This application provides a method for tracing network service faults, relating to the field of intelligent operation and maintenance technology. The method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited thereto. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the network service fault tracing method, but is not limited to the above forms.

[0031] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0032] Figure 1 This is a schematic diagram illustrating the implementation environment of a method provided in this application. (Refer to...) Figure 1The main hardware and software components of this implementation environment include a terminal 101 and a server 102, which are communicatively connected. The method can be executed based on the interaction between the terminal 101 and the server 102. Furthermore, the terminal 101 and the server 102 can be nodes in a blockchain; this embodiment does not specifically limit this.

[0033] Figure 2 This is an optional flowchart of a network service fault tracing method provided in an embodiment of this application. Figure 2 The method may include, but is not limited to, steps S201 to S204.

[0034] Step S201: Obtain multi-branch forwarded data packets through network nodes, and generate branch identifiers for each outgoing interface of the network nodes; Step S202: Based on the branch identifier, the data packet is encapsulated with IOAM information to obtain an initial packet, and the initial packet is transmitted to the downstream node; Step S203: The initial message is encapsulated by the downstream node using a hierarchical coding rule to obtain the target message; Step S204: Perform path analysis and fault location processing on the target message to obtain a fault path report.

[0035] Steps S201 to S204, as illustrated in this embodiment, involve obtaining multi-branch forwarding data packets through network nodes. Parsing the data packets reveals that they are forwarded through the network node's outgoing interface, generating a corresponding branch identifier for that interface. This branch identifier determines the data packet's transmission node. After generating the branch identifier, the data packet is encapsulated with IOAM information to obtain an initial packet. This initial packet is forwarded to downstream nodes via the network node's outgoing interface. Downstream nodes receive this initial packet and parse it to determine the outgoing interface used for forwarding it. They then encapsulate the initial packet using hierarchical coding, appending a sub-branch ID to the original branch identifier to obtain the target packet. The target packet carrying the branch identifier is transmitted with the service flow until it reaches the terminal or data collector. The terminal or data receiver performs path analysis and fault location on the target packet based on the branch identifier, generating a corresponding fault path report.

[0036] One of the above technical solutions has the following advantages or beneficial effects: In this application embodiment, the network node obtains data packets forwarded through multiple branches, generates a branch identifier for each outgoing interface of the network node, and can identify the transmission node of the data packet based on the branch identifier, simplifying the complexity of identifying different nodes during transmission. Furthermore, this application embodiment encapsulates the data packet with IOAM information based on the branch identifier, and encapsulates the initial packet using a hierarchical coding rule by the downstream node. This allows for fault analysis based on IOAM information, and can form a specific link identifier by combining the identifier of the downstream node, improving the efficiency of path association in multi-branch scenarios and increasing the efficiency of fault location. This application embodiment constructs a fault tracing mechanism with higher accuracy and lower overhead, which can be used for multi-branch scenario path association and fault node location analysis of network services.

[0037] Please see Figure 3 In step S201 of some embodiments, obtaining multi-branch forwarded data packets through network nodes and generating branch identifiers for each outgoing interface of the network node includes the following steps: Step S301: When the network node detects that the data packet has multi-branch forwarding behavior, it determines the outgoing interface used to forward the data packet. Step S302: Encode the physical identifier string of the outgoing interface into a byte stream, and perform hash compression calculation on the byte stream to obtain the branch identifier.

[0038] In this embodiment, network nodes detect whether multi-branch forwarding behavior exists in data packets. If multi-branch forwarding behavior exists, a data report is obtained, and the outgoing interface in the network node used to forward the data packets is identified, generating a corresponding branch identifier. Multi-branch forwarding behavior includes multicast packet replication and unicast branch forwarding behavior.

[0039] In step S301 of some embodiments, the present application embodiments identify the forwarding behavior of data packets. When it is identified as normal forwarding, forwarding and detection are performed through the IOAM mechanism. When the forwarding behavior of the data packet is identified as multi-branch forwarding, the data packet is parsed to obtain the outgoing interface in the network node used for forwarding the data packet. Here, the outgoing interface is the physical or logical interface in the network device used to send data packets. In routing configuration, the outgoing interface refers to the interface used when the data packet leaves the router or switch.

[0040] In step S302 of some embodiments, the physical identifier string of the outgoing interface is encoded and converted into a byte stream. For example, the physical ID string of the interface (such as SW-01-SLOT02-PORT05) is encoded into a binary byte stream using UTF-8, where each character corresponds to 1 byte, for a total of 18 bytes. Then, hash compression calculation is performed according to the CRC-8 algorithm rules. By following the standard CRC-8 calculation, there is no input-output reflection and no post-XOR operation, thereby converting the string-format physical ID into 8 bits. Specifically, by processing the first byte 0x53 (binary 01010011): CRC^=0x53→0x00^0x53=0x53; 0x53 is subjected to 8 shift-XOR operations: processed sequentially from the most significant bit (bit7) to the least significant bit (bit0). After each shift, if the most significant bit is 1, it is XORed with the polynomial 0x07, finally obtaining the intermediate CRC value 0x1A; the remaining 17 bytes are processed sequentially, and after the final iteration, the CRC register value is 0x7C. It should be noted that this embodiment of the application also performs a uniqueness check on the calculated branch identifier. By maintaining the interface physical ID-branch identifier mapping table locally, it is checked whether 0x7C has been allocated. If 0x7C is not occupied, it is determined to be the unique branch identifier of the interface. If a conflict occurs, such as different physical IDs calculating the same CRC value in extreme scenarios, the lower 2 bits of the interface priority are appended, such as priority 3→0b11, and CRC-8 is recalculated, that is, 0x03 is appended to the physical ID and then compressed to ensure the uniqueness of the identifier.

[0041] For example, when a network node detects multicast packet replication or unicast branch forwarding behavior, it generates a unique branch identifier for each egress interface, and uses a hash compression algorithm of the interface physical ID to ensure the uniqueness of the identifier, with the control field length ≤ 8 bits.

[0042] One of the above technical solutions has the following advantages or beneficial effects: By generating branch identifiers for the outgoing interfaces of network nodes, the outgoing interfaces of network nodes can be identified through the branch identifiers in fault analysis, providing a data foundation for subsequent fault analysis.

[0043] Please see Figure 4 In step S202 of some embodiments, the step of encapsulating the data packet with IOAM information based on the branch identifier to obtain an initial packet, and transmitting the initial packet to the downstream node, includes the following steps: Step S401: Construct an option unit based on the branch identifier and the status bit; Step S402: The option unit is embedded into the destination option header of the data packet in combination with IOAM information, encapsulated to obtain an initial packet, and the initial packet is transmitted to the downstream node.

[0044] In this embodiment, an option unit, i.e., the Option unit in the data packet, is constructed based on the branch identifier. This unit is the core of the extension. RFC8321 specifies that the fixed structure of each Option unit is [OptionType (1 byte)] + [OptionLength (1 byte)] + [OptionValue (variable byte)]. OptionType identifies the Option function, OptionLength simply represents the length of OptionValue, and OptionValue is the specific data of the extended function. Finally, the option unit, combined with IOAM information, is embedded into the destination option header of the data packet, which encapsulates the initial packet. This initial packet is then transmitted to the downstream node through the network node's outgoing interface. The IOAM information may include metadata such as device ID, ingoing / outgoing interface, and timestamp.

[0045] In step S401 of some embodiments, this application embodiment defines the status bit of the branch node as a separate 1 byte allocated as a status field in OptionValue, stipulating that bit 5 is the "branch node flag bit", and other bits are set to 0 and reserved to avoid conflicts with future expansion. That is, bit 5=1: indicates that the current node is a "branch node" and has performed multicast replication or unicast branch forwarding behavior; if bit 5=0: indicates that it is not a branch node and is only used for transparent transmission identification. According to the Option structure, this application embodiment assembles an option unit containing a branch identifier and a status bit. The values ​​of each field in the option unit are as follows: OptionType is 0x1E, used to reuse the OptionType reserved in RFC8321, indicating that the Option is a "branch information extension". OptionLength is 0x02, indicating that the OptionValue length is 2 bytes, including 1 byte of branch identifier and 1 byte of status bit. OptionValue is 0x7C+0x20, where the first byte is the branch identifier 0x7C; the second byte is the status bit 0x20. At this point, the complete hexadecimal string representation of the option unit is 0x1E0x020x7C0x20.

[0046] In step S402 of some embodiments, the embodiments of this application combine the basic fields and option units in the IOAM information to generate the IOAM header. The complete header fields of the IOAM header are broken down as follows: Version field, meaning: 4-bit version (0) + 4-bit IOAMType (0), conforming to the RFC8321 standard. The Length field means that the total length of the header is 1 (Version) + 1 (Length) + 1 (Flags) + 4 (Option unit) = 7 bytes, so the value is 0x07. The Flags field means that the standard reserved bit has no special mark (E=0, indicating that there are no other iOAM fields later). The OptionType field means that the reserved OptionType is reused to identify the branch information extension. The OptionLength field means that the OptionValue length is 2 bytes. The OptionValue[0] field means that the branch identifier is the interface unique identifier generated by CRC-8 mentioned above. The OptionValue[1] field means that the branch node status bit is taken as binary 00100000, bit5=1, indicating that the current node is a branch node.

[0047] The IOAM header is embedded into the destination options header of the datagram, and the initial packet is encapsulated. The complete data packet structure of the initial packet is as follows: The first layer is the IPv6 header, which includes the source address, destination address, traffic class, and next header. The next header is set to 0x3B, indicating that the following is the destination options header. The second layer is the destination options header, which includes the next header and an options list. The next header is set to 0x06, indicating that the following is a TCP or UDP service layer. The options list includes the aforementioned IOAM header. The third layer is the IOAM header, which is 0x000x070x000x1E0x020x7C0x20 constructed in the previous steps. The fourth layer is the service layer data, including multicast / unicast service data, such as industrial control commands and video streams.

[0048] One of the above technical solutions has the following advantages or beneficial effects: The encapsulation method of this application fully complies with the "iOAM header embedding rules" of RFC8321. Existing network devices that support IPv6 can normally parse the IPv6 header and destination option header, and will not drop data packets due to the addition of iOAM extensions, thus reducing network overhead.

[0049] Please see Figure 5 In step S203 of some embodiments, the encapsulation of the initial message by the downstream node using hierarchical coding rules to obtain the target message includes the following steps: Step S501: Determine the outgoing interface of the downstream node based on the initial message; Step S502: Identify the outgoing interface of the downstream node to obtain the sub-branch identifier; Step S503: Combine the sub-branch identifier and the branch identifier of the initial message to obtain a hierarchical identifier, and encapsulate the initial message according to the hierarchical identifier to obtain the target message.

[0050] In this embodiment, the outgoing interface of the downstream node can be determined by parsing the initial message; that is, the outgoing interface of the downstream node used to transmit the initial message. This embodiment also identifies the outgoing interface of the downstream node to obtain a sub-branch identifier, and encapsulates the initial message using a hierarchical encoding rule to obtain the target message. Specifically, the secondary branch node appends a sub-branch ID to the original branch identifier, which can be achieved by combining the parent identifier with the sub-interface number, using a hierarchical encoding rule such as "main branch.sub-branch.grandchild branch" to avoid identifier conflicts. Finally, the target message carrying the branch identifier is transmitted with the service flow until it reaches the terminal or data collector.

[0051] In step S501 of some embodiments, the outgoing interface of the downstream node can be determined by parsing the initial message; that is, the outgoing interface of the downstream node used to transmit the initial message. It should be noted that for non-branch nodes, the branch identifier can be directly transmitted, only verifying the integrity of the identifier without modifying the field content. For example, if the downstream node of the network node is the target device, the branch identifier is directly transmitted without further processing.

[0052] In step S502 of some embodiments, based on the example of the first branch node, such as the first branch node SW-01: physical interface SW-01-SLOT02-PORT05, a unique branch identifier 0x7C is generated, embedded in the iOAM header, and transmitted downstream. Now, processing is performed on the second branch node. The downstream node of PORT05 of the first branch node SW-01 is connected to the industrial switch of the second branch node SW-02. It needs to copy the multicast packets from SW-01 to its two egress interfaces: SW-02-SLOT01-PORT03 and SW-02-SLOT01-PORT04. A sub-branch ID needs to be appended to the first branch identifier, i.e., the parent identifier 0x7C, to achieve a unique "main branch.sub-branch" identifier through hierarchical encoding, avoiding conflicts between multiple sub-interfaces.

[0053] Specifically, this embodiment follows a hierarchical structure of "main branch (initial identifier). sub-branch (secondary ID)". To control overhead and maintain compatibility with the existing iOAM header Option field (originally 1 byte identifier + 1 byte status), the hierarchical identifier is extended to 2 bytes (16 bits), specifically allocated as follows: High 8 bits: Parent identifier, i.e., the unique identifier generated by the initial branch node, such as 0x7C. Low 8 bits: Sub-branch ID, i.e., the unique ID generated by the secondary branch node for the egress interface, generated through hash compression of the interface physical ID, ensuring no conflict with sub-interfaces within the same secondary node. At this point, the data collector can use the high 8 bits to match the parent path and the low 8 bits to locate the sub-path, thus resolving the hierarchical relationship.

[0054] The sub-branch ID generation rule uses a CRC-8 hash compression algorithm, but only the lower 8 bits of the hash result are used. Specifically, the physical ID of the secondary branch node's exit interface is extracted, converted into a UTF-8 byte stream, and a CRC-8 calculation is performed. The lower 8 bits of the CRC-8 result are used as the sub-branch ID. Since the number of secondary node interfaces is usually ≤256, 8 bits are sufficient to avoid collisions.

[0055] In step S503 of some embodiments, this application embodiment combines the hierarchical identifier to construct the Option unit for the secondary branch scenario, and adjusts the OptionLength field in the Option unit. Because the identifier is extended to 2 bytes, the OptionValue length increases by 1 byte. At this time, the packet encapsulation structure of the secondary branch scenario is consistent with that of the first branch, with only the Option unit length in the IOAM header changing, without violating the IPv6 extension header rules.

[0056] One of the above technical solutions has the following advantages or beneficial effects: By identifying the downstream nodes, the transmission path of the data packet can be identified, thereby recognizing multi-branch scenarios.

[0057] In step S204 of some embodiments, the step of performing path analysis and fault location processing on the target message to obtain a fault path report includes the following steps: The identifier field of the target message is parsed to obtain identifier data for different paths; The hierarchical relationship of the identification data is identified to generate a path mapping table; A multi-branch tree structure is constructed based on the path mapping table, and the multi-branch tree structure is associated with the network topology to obtain an association mapping table; Based on the association mapping table, time sequence analysis and fault location are performed on target messages with the same identifier data to obtain the fault path report.

[0058] In this embodiment, the data collector receives target packets with branch identifiers and can construct a multi-branch tree structure based on the identifiers to map the hierarchical relationship between the main path and each branch sub-path. It performs time-series analysis on hop-by-hop data under the same branch identifier, and locates the fault initiation node and its corresponding branch link by comparing node packet loss rate and latency mutation points. This embodiment can perform recursive analysis of multi-level branch scenarios, automatically filter non-faulty branches, and generate a visualized fault path report.

[0059] Specifically, in this embodiment, the identifier field of the target packet is parsed to obtain identifier data for different paths. The data collector is deployed on the mirror port of the core node SW-Core, receiving target packets forwarded across the entire network in real time, parsing the branch identifier field of each packet, and extracting identifier data for different paths. The data collector disassembles the identifiers by using "." separators, identifies the hierarchy and parent-child relationships of each identifier, and generates an "identifier-hierarchy-parent identifier" mapping table to obtain the path mapping table.

[0060] The path mapping table is shown in Table 1 below:

[0061] Table 1 Path Mapping Table This embodiment of the application also uses the main path as the root node and the branch identifier as the child node to construct a multi-branch tree layer by layer. Each tree node contains three core attributes: "identifier, corresponding device interface, and IOAM performance data". The specific tree structure is shown in Table 2 below:

[0062] Table 2 Tree Structure This application's embodiments associate multi-branch tree nodes with the actual network topology, generating a tree structure-physical topology association mapping table, clearly defining the end-to-end path corresponding to each branch identifier. The association mapping table is shown in the table below:

[0063] Table 3 Association Mapping Table Finally, this application embodiment performs timing analysis and fault location on target messages with the same identifier data based on the association mapping table, and can obtain a fault path report.

[0064] One of the above technical solutions has the following advantages or beneficial effects: According to the embodiment of this application, path analysis and fault location can be performed on the target message based on the identifier, thereby improving the efficiency of fault analysis.

[0065] In some embodiments, the step of performing time-series analysis and fault location on target packets with the same identifier data based on the association mapping table to obtain the fault path report includes the following steps: The transmission link of target messages with the same identifier data is determined based on the association mapping table; The transmission link is split into branch links, and time-series data is obtained by collecting data from the branch links. The time series data is analyzed and compared to obtain the fault location results; Generate a report title and basic information based on the fault location results; Based on the fault location results, the fault path is extracted, and the fault path is visualized topologically to obtain an abnormal branch details table; The fault location results are analyzed for fault causes, and the fault path report is generated by combining the report title, basic information and the abnormal branch details table for visualization.

[0066] In this embodiment, time-series analysis and fault location are performed on hop-by-hop data under the same branch identifier. The link corresponding to branch identifiers 0x7C and 0x8B is split into three "node-next-hop" links, and time-series data for each segment is collected. This time-series data may include latency, packet loss rate, and other data. This embodiment performs time-series analysis and comparison based on the time-series data, such as drawing corresponding time-series trend charts, marking visually abnormal mutation points, and obtaining fault location results. This embodiment can also combine large language models to generate report titles and basic information, including report generation time, data collection cycle, anomaly judgment criteria, and analysis scope. Based on the fault location results, this embodiment extracts the fault path. Combined with a branch tree structure, the hierarchical relationship of main path → first-level branch → second-level branch can be intuitively displayed, quickly locating the physical link corresponding to any identifier. Anomaly analysis can also be performed on branches based on anomaly indicators to obtain an anomaly branch details table or anomaly indicator time-series trend chart. Fault cause analysis can be performed using large language models to generate corresponding processing suggestions.

[0067] One of the above technical solutions has the following advantages or beneficial effects: the embodiments of this application can quickly locate abnormal branches in the transmission path through branch identifiers, thereby improving the efficiency of tracing the source of network service faults.

[0068] In some embodiments, the step of performing time-series analysis and comparison on the time-series data to obtain fault location results includes the following steps: A time series trend chart is drawn based on the time series data; Based on the time-series trend chart, anomalies are compared between adjacent link segments to locate the fault initiation position. The fault location result is obtained by performing link location on the fault starting position according to the association mapping table.

[0069] In this embodiment, a time-series trend chart can be drawn based on time-series data, thereby visually displaying the changes in indicators of each link segment and highlighting anomalous change points. By adopting the logic of "upstream-downstream comparison", the abnormal time and indicators of adjacent link segments are compared to rule out upstream node failures and locate the fault initiation position. Specifically, if an upstream link fails, it will cause all downstream links to synchronously fail; if only segment 3 in the link is abnormal, and segment 2 is normal, and the upstream entry of segment 3 (SW-A1 entry) is normal, it indicates that the fault initiation node is SW-A1, and the faulty link is the exit link of SW-A1. This embodiment also determines the position of the fault initiation position in the network topology based on the association mapping table. For example, the downstream of the interface at the fault initiation position is connected to terminals PC1 and PC2, so the faulty link covers SW-A1→PC1 and SW-A1→PC2.

[0070] One of the above technical solutions has the following advantages or beneficial effects: This application embodiment performs node fault analysis by acquiring time series data, which can analyze the fault results and determine the corresponding fault path based on the branch identifier.

[0071] The solutions of this application embodiment will be described in detail and explained below with reference to specific application examples: This application's embodiments can be applied to the field of intelligent operation and maintenance technology, and are suitable for fault analysis scenarios in network services. This application's embodiments can transmit and analyze data packets of network services, improving the efficiency of fault tracing. This application's embodiments, by identifying branches in data packets under multi-branch forwarding scenarios, can perform recursive analysis based on the branch identifiers, thereby tracing the fault source. Please refer to... Figure 6 This embodiment of the application starts from the root node of a multi-branch tree and traverses the sub-branches layer by layer downwards, performing full-link analysis through indicator judgment, branch filtering, and sub-branch recursion. Specifically, root node analysis is performed. At this point, the node information is unidentified, the link is SW-Core→SW-A, and the indicator is 1.2ms / 0%. The indicator can be determined to be normal, and the normal branch is marked, but the root node is not filtered. Recursion is then triggered to traverse the sub-branches 0x7C and 0x19 of the root node.

[0072] Branch 0x19, with a latency of 2.3ms / 0%, is marked as a normal branch, and its sub-branch 0x19.0x2D is not recursively traversed. Branch 0x7C, with a latency of 2.5ms / 0%, is also marked as a normal branch, but its sub-branch 0x7C.0x8B needs to be recursively traversed, as its sub-branch may be abnormal. Analyzing the second-level branch 0x7C.0x8B, the node information is identified as 0x7C.0x8B, the link is SW-A1→SW-A11, and the latency is 8.5ms / 5.2%. It can be determined that both latency and packet loss rate exceed the threshold, so it is marked as an abnormal branch. Recursion is then triggered to traverse its sub-branches 0x7C.0x8B.0x4E and 0x7C.0x8B.0x6F. At this point, the latency of branch 0x7C.0x8B.0x4E is 13.2ms / 12.1%, marking it as an abnormal branch. Since this branch has no sub-branches, the recursion ends. Similarly, the metrics for branch 0x7C.0x8B.0x6F are 14.5ms / 13.8%, which are marked as abnormal branches. If there are no child branches, the recursion ends.

[0073] Please see Figure 7 This application also provides a network service fault tracing device, which can implement the above-mentioned network service fault tracing method. The device includes: The identifier generation module 701 is used to obtain multi-branch forwarded data packets through network nodes and generate a branch identifier for each outgoing interface of the network node. The initial encapsulation module 702 is used to perform IOAM information encapsulation processing on the data packet based on the branch identifier to obtain an initial packet, and transmit the initial packet to the downstream node; The layered encapsulation module 703 is used to encapsulate the initial message using layered encoding rules through the downstream node to obtain the target message; The fault location module 704 is used to perform path analysis and fault location processing on the target message to obtain a fault path report.

[0074] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0075] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0076] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0077] Please see Figure 8 , Figure 8 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 801 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 802 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 802 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 802 and is called and executed by the processor 801. The 803 input / output interface is used to implement information input and output. The communication interface 804 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 805 transmits information between various components of the device (e.g., processor 801, memory 802, input / output interface 803, and communication interface 804); The processor 801, memory 802, input / output interface 803, and communication interface 804 are connected to each other within the device via bus 805.

[0078] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0079] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0080] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0081] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0082] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0083] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; 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.

[0084] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0085] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0086] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0087] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0088] The units described above 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0089] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0090] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 multiple 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 of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0091] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for tracing the source of network service faults, characterized in that, The method includes the following steps: Data packets forwarded by multiple branches are obtained through network nodes, and a branch identifier is generated for each outgoing interface of the network node; The data packet is encapsulated with IOAM information based on the branch identifier to obtain an initial packet, and the initial packet is transmitted to the downstream node. The initial message is encapsulated by the downstream node using a hierarchical encoding rule to obtain the target message; The target message is subjected to path analysis and fault location processing to obtain a fault path report.

2. The method according to claim 1, characterized in that, The process of obtaining multi-branch forwarded data packets through network nodes and generating branch identifiers for each outgoing interface of the network nodes includes the following steps: When the network node detects that the data packet has multi-branch forwarding behavior, it determines the outgoing interface used to forward the data packet; The physical identifier string of the outgoing interface is encoded and converted into a byte stream, and the byte stream is hashed and compressed to obtain the branch identifier.

3. The method according to claim 1, characterized in that, The step of encapsulating the data packet with IOAM information based on the branch identifier to obtain an initial packet, and then transmitting the initial packet to the downstream node, includes the following steps: The option unit is constructed based on the branch identifier and the status bit. The option unit, combined with IOAM information, is embedded into the destination option header of the data packet, encapsulated to obtain an initial packet, and the initial packet is transmitted to the downstream node.

4. The method according to claim 1, characterized in that, The process of encapsulating the initial message using a hierarchical encoding rule at the downstream node to obtain the target message includes the following steps: The outgoing interface of the downstream node is determined based on the initial message; The sub-branch identifier is obtained by identifying the output interface of the downstream node; The sub-branch identifier and the branch identifier of the initial message are combined to obtain a hierarchical identifier, and the initial message is encapsulated according to the hierarchical identifier to obtain the target message.

5. The method according to claim 1, characterized in that, The step of performing path analysis and fault location processing on the target message to obtain a fault path report includes the following steps: The identifier field of the target message is parsed to obtain identifier data for different paths; The hierarchical relationship of the identification data is identified to generate a path mapping table; A multi-branch tree structure is constructed based on the path mapping table, and the multi-branch tree structure is associated with the network topology to obtain an association mapping table; Based on the association mapping table, time sequence analysis and fault location are performed on target messages with the same identifier data to obtain the fault path report.

6. The method according to claim 5, characterized in that, The step of performing time-series analysis and fault location on target packets with the same identifier data based on the association mapping table to obtain the fault path report includes the following steps: The transmission link of target messages with the same identifier data is determined based on the association mapping table; The transmission link is split into branch links, and time-series data is obtained by collecting data from the branch links. The time series data is analyzed and compared to obtain the fault location results; Generate a report title and basic information based on the fault location results; Based on the fault location results, the fault path is extracted, and the fault path is visualized topologically to obtain an abnormal branch details table; The fault location results are analyzed for fault causes, and the fault path report is generated by combining the report title, basic information and the abnormal branch details table for visualization.

7. The method according to claim 6, characterized in that, The process of performing time-series analysis and comparison on the time-series data to obtain fault location results includes the following steps: A time series trend chart is drawn based on the time series data; Based on the time-series trend chart, anomalies are compared between adjacent link segments to locate the fault initiation position. The fault location result is obtained by performing link location on the fault starting position according to the association mapping table.

8. A network service fault tracing device, characterized in that, The device includes: The identifier generation module is used to obtain multi-branch forwarded data packets through network nodes and generate a branch identifier for each outgoing interface of the network node. An initial encapsulation module is used to encapsulate the data packet with IOAM information based on the branch identifier to obtain an initial packet, and transmit the initial packet to the downstream node; The layered encapsulation module is used to encapsulate the initial message using layered encoding rules through the downstream node to obtain the target message; The fault location module is used to perform path analysis and fault location processing on the target message to obtain a fault path report.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

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

Images