A network fault repair method and system based on multi-protocol detection

Abstract

The application provides a network fault repair method and system based on multi-protocol detection, and relates to the technical field of network communication, which comprises the following steps: collecting link layer discovery protocol, address resolution protocol, routing table and bidirectional forwarding detection session state information; constructing a directed graph model comprising a plurality of nodes and links; identifying a primary path of current traffic according to the bidirectional forwarding detection session state information, and determining a fault link segment according to the primary path; generating a dynamic state identifier set according to the address resolution protocol, the routing table and the fault link segment; and generating a candidate optimized path according to the directed graph model and the dynamic state identifier set. Three key states, i.e., forwarding reachability, policy blocking and link fault, are accurately identified. The dynamic state identifier set truly reflects the actual carrying capacity of a link to service traffic, and fundamentally avoids the problem of traffic black hole after switching caused by misjudgment of routing reachability, i.e., forwarding reachability.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a network fault repair method and system based on multi-protocol detection. Background Technology

[0002] In modern data centers, wide area networks (WANs), and mission-critical networks, high availability and fault-healing capabilities have become core requirements for ensuring business continuity. If a link or node failure cannot be resolved within seconds or even sub-seconds, it can lead to serious consequences such as network outages, real-time communication disruptions, and loss of industrial control connectivity. Therefore, achieving rapid, accurate, and automated network fault location and repair is a critical technical challenge that urgently needs to be addressed in the field of network operations and maintenance.

[0003] Currently, the mainstream fault recovery technologies in the industry mainly fall into the following categories, but all have significant limitations. The first category relies on the convergence mechanism of traditional routing protocols (such as OSPF, IS-IS, and BGP). This type of solution detects neighbor status by periodically sending Hello messages. When a link is interrupted, it requires waiting for multiple timeout periods (usually tens of seconds) to determine if a neighbor has failed, thus triggering complex route recalculation and network-wide synchronization. The entire process is too time-consuming and cannot meet the needs of high real-time services. The second category uses Bidirectional Forwarding Detection (BFD) protocols in conjunction with routing protocols to accelerate fault detection. While BFD can shorten link fault detection time to milliseconds, it only solves the problem of fast detection. The bottleneck of fault recovery still lies in the slow convergence and configuration distribution process of upper-layer routing protocols. The overall recovery time remains in the seconds range, and frequent route oscillations may impact network stability. The third category is link aggregation or device-level fast rerouting (FRR) technology. Such solutions can achieve millisecond-level switching on local devices, but their applicability is extremely limited: link aggregation is only suitable for point-to-point scenarios where there are multiple directly connected physical links between devices; while traditional FRR (such as LFA, Loop-Free Alternate) usually calculates alternative paths based on local topology information, lacking a global perspective, and is prone to problems such as suboptimal paths, temporary loops, or incomplete protection coverage, making it difficult to cope with non-directly connected link failures in complex network topologies. The fourth type is the operation and maintenance mode that relies on manual intervention. After receiving alarms through the network management system (NMS), network administrators need to manually log in to the devices to diagnose and locate the problem, and modify static routes or policies to restore services. This method has a slow response time, low efficiency, is highly dependent on personnel experience, and has a response vacuum period at night or on holidays, making reliability unreliable.

[0004] More fundamentally, existing automated fault recovery solutions suffer from a dual deficiency in the generation and evaluation of candidate paths: Firstly, their path calculations generally rely solely on static routing tables or limited BFD states, failing to accurately determine the true forwarding capability of non-primary egress links. For example, a link may be marked as reachable in the routing table, but may actually be unable to forward traffic to a specific destination due to security policy blocking, missing ARP entries, or misconfigured intermediate devices, resulting in a traffic black hole after the switchover. Secondly, even if a potential backup path is identified, if the path contains historically unstable links, existing solutions often adopt a coarse-grained approach of using or discarding all links. This approach fails to quantify the local risks of the path and lacks the ability to intelligently harden repairable paths, i.e., only replacing unreliable link segments while retaining the remaining healthy parts, thus missing the opportunity to improve path reliability at minimal cost. Summary of the Invention

[0005] This application aims to at least partially address one of the technical problems in the related art.

[0006] To achieve the above objectives, this application proposes a network fault repair method based on multi-protocol detection, comprising the following steps:

[0007] Step 1: Collect link layer discovery protocol, address resolution protocol, routing table, and bidirectional forwarding detection session state information;

[0008] Step 2: Based on the link layer discovery protocol, address resolution protocol, routing table, and bidirectional forwarding detection session state information, construct a directed graph model including several nodes and links;

[0009] Step 3: Identify the primary path of the current traffic based on the bidirectional forwarding detection session state information, and determine the faulty link segment based on the primary path;

[0010] Step 4: Generate a dynamic status identifier set based on the address resolution protocol, routing table, and faulty link segment;

[0011] Step 5: Generate candidate optimization paths based on the directed graph model and the dynamic state identifier set;

[0012] Step 6: Determine and execute network configuration instructions based on the candidate optimized paths to obtain the repair strategy.

[0013] Further, generating a dynamic state flag set includes the following steps:

[0014] Step 41: Extract the destination IP prefix corresponding to the primary path based on the routing table, and determine the upstream node of the faulty link segment;

[0015] Step 42: Query all adjacent links of the upstream node in the directed graph model to obtain the set of adjacent links;

[0016] Step 43: Based on the destination IP prefix, query the routing table of the upstream node to determine the next-hop node, and determine the outgoing interface used by the upstream node to the next-hop node;

[0017] Step 44: Mark the adjacent links corresponding to the outgoing interface as primary direction links, and remove the primary direction links from the set of adjacent links to obtain a set of non-primary adjacent links;

[0018] Step 45: Query the active host address corresponding to the destination IP prefix based on the address resolution protocol, and construct a probe packet based on the active host address;

[0019] Step 46: Based on the upstream node, send the probe message through each non-primary adjacent link in the set of non-primary adjacent links to obtain the round-trip delay sequence;

[0020] Step 47: If a non-primary adjacent link receives a response data packet within a preset time, the non-primary adjacent link is marked as reachable for forwarding; extract the bidirectional forwarding detection session state information corresponding to the non-primary adjacent link; if the non-primary adjacent link does not receive a response data packet within a preset time and the bidirectional forwarding detection session state information is normal, the non-primary adjacent link is marked as blocked by policy; if the non-primary adjacent link does not receive a response data packet within a preset time and the bidirectional forwarding detection session state information is interrupted, the non-primary adjacent link is marked as a link failure.

[0021] Step 48: The forwarding reachability, policy blocking, and link failure are used as status labels for non-primary adjacent links and integrated into a dynamic status label set.

[0022] Furthermore, based on the directed graph model and the dynamic state identifier set, candidate optimization paths are generated, including the following steps:

[0023] Step 51: Extract the path endpoint node based on the primary path, define the upstream node of the faulty link segment as the path starting node, and search all connected paths from the path starting node to the path endpoint node without passing through the faulty link segment based on the directed graph model to form an initial path set.

[0024] Step 52: Traverse each connected path in the initial path set, and identify the first hop link starting from the path's starting node based on the current initial path; if the first link is a non-primary adjacent link and its status label is link failure or policy blocking, then remove the current initial path.

[0025] Step 53: Mark the remaining initial paths after elimination as remaining paths, identify the status labels of the remaining paths that can be forwarded, and obtain the set of paths to be evaluated;

[0026] Step 54: For each remaining path in the set of paths to be evaluated, perform path stability evaluation to generate candidate optimized paths.

[0027] Furthermore, for each remaining path in the set of paths to be evaluated, a path stability assessment is performed, including the following steps:

[0028] Step 541: Extract the bidirectional forwarding detection session status information within the most recent monitoring period for each link of the remaining path, and obtain the number of session interruptions;

[0029] Step 542: Determine the time delay fluctuation index based on the round-trip time delay sequence;

[0030] Step 543: If any link satisfies the following condition, then mark the current remaining path as the first stable path and proceed to the next step; otherwise, mark the current remaining path as the second stable path and add it to the candidate path subset.

[0031] The specific conditions are: the number of session interruptions is greater than a preset number, and the latency fluctuation index is greater than a preset index;

[0032] Step 544: Identify the adjacent links between adjacent nodes in the first stable path. If there are N adjacent links whose status labels are forwarding reachable, mark the remaining path as a path to be reinforced, reinforce the path to be reinforced and add it to the candidate subset; otherwise, remove the remaining path; where N≥2.

[0033] Step 545: Generate candidate optimization paths based on the candidate subset.

[0034] Furthermore, the path to be reinforced is reinforced and added to the candidate subset, including:

[0035] Identify the links to be reinforced in the path to be reinforced based on the status labels of N adjacent links;

[0036] The upstream and downstream reinforcement nodes are determined based on the link to be reinforced.

[0037] Starting from the upstream reinforcement node and ending at the downstream reinforcement node, a connected path that does not pass through the link to be reinforced is searched in the directed graph model and marked as an alternative sub-path.

[0038] Filter out alternative sub-paths whose status labels are reachable by forwarding and define them as filter paths;

[0039] The paths to be reinforced are reconstructed based on the filtered paths, and the reinforced paths are added to the candidate subset.

[0040] Further, the path to be reinforced is reconstructed according to the selected path to obtain the reinforced path, including: taking the part of the path to be reinforced before the upstream reinforced node as the front path, taking the part of the path to be reinforced after the downstream reinforced node as the back path, and sequentially splicing the front path, any of the selected paths, and the back path to generate the reinforced path.

[0041] Further, based on the second stable path and the reinforced path of the candidate subset, the number of links is identified; for the second stable path and the reinforced path, they are arranged in ascending order according to the number of links to obtain a permutation set, all second stable paths are placed before the reinforced paths, and the first k second stable paths and / or reinforced paths in the permutation set are taken as candidate optimization paths, k≥2.

[0042] Further, determining network configuration instructions based on the candidate optimization paths includes: determining the target optimization path based on the candidate optimization paths, parsing the node sequence of the target repair path, extracting the outgoing interfaces between adjacent nodes, and generating local forwarding configuration instructions for each node based on the outgoing interfaces.

[0043] This invention also discloses a network fault repair system based on multi-protocol detection, comprising the following modules:

[0044] Data acquisition module: used to collect link layer discovery protocol, address resolution protocol, routing table and bidirectional forwarding detection session state information;

[0045] Graph construction module: used to construct a directed graph model including several nodes and links based on link layer discovery protocol, address resolution protocol, routing table and bidirectional forwarding detection session state information;

[0046] Fault location module: used to identify the primary path of the current traffic based on the bidirectional forwarding detection session state information, and to determine the faulty link segment based on the primary path;

[0047] Status Identification Module: Used to generate a dynamic status identification set based on the address resolution protocol, routing table, and faulty link segments;

[0048] Optimization module: used to generate candidate optimization paths based on the directed graph model and dynamic state flag set;

[0049] Repair module: used to determine and execute network configuration instructions based on the candidate optimized paths to obtain a repair strategy.

[0050] Compared with existing technologies, this application provides a network fault repair method and system based on multi-protocol detection. It constructs a directed graph model using link-layer discovery protocols, address resolution protocols, routing tables, and bidirectional forwarding detection session state information. It also considers that the upstream node of the faulty link determines non-primary adjacent links and sends probe packets to obtain corresponding state labels. This invention is no longer limited to a rough judgment of link reachability based on static routing tables or a single bidirectional forwarding detection state. Instead, for each non-primary egress link, it constructs and actually sends probe packets based on the destination IP prefix, combining the probe response results with bidirectional forwarding detection session state information for verification, thereby accurately identifying three key states: forwarding reachable, policy blocking, and link fault. This dynamic state label set truly reflects the actual carrying capacity of the link for service traffic, fundamentally avoiding the post-switch traffic black hole problem caused by misjudging routing reachability as forwarding reachability.

[0051] This application, after eliminating paths based on the initial path's status labels, identifies first and second stable paths by considering session interruption counts and latency fluctuation indicators. The first stable path is then reinforced to obtain candidate optimized paths. Instead of treating paths as indivisible wholes, it identifies local stability risks within the path based on session interruption counts and latency fluctuation indicators. For repairable paths, unreliable link segments are precisely located, and only these segments are replaced via detours, preserving the remaining healthy parts. This transforms the path into a highly available candidate optimized path with minimal topology changes. This method effectively avoids the waste of resources by abandoning entire potentially high-quality paths due to local instability, significantly expands the coverage of available repairable paths, and ensures that the final deployed path possesses both high reliability and high efficiency, significantly improving the granularity and effectiveness of fault recovery. Attached Figure Description

[0052] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0053] Figure 1 A flowchart illustrating a network fault repair method based on multi-protocol detection provided in this application embodiment;

[0054] Figure 2 This application provides a structural diagram of a network fault repair system based on multi-protocol detection.

[0055] Figure 3 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0056] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0057] The following description, with reference to the accompanying drawings, illustrates a network fault repair method and system based on multi-protocol detection, according to an embodiment of this application.

[0058] like Figure 1 As shown, a network fault repair method based on multi-protocol detection includes the following steps:

[0059] Step 1: Collect link layer discovery protocol, address resolution protocol, routing table and bidirectional forwarding detection session state information.

[0060] This embodiment describes a typical network topology consisting of four routers, R1, R2, R3, and R4. After the network fault self-healing center is activated, it logs into the four devices (R1, R2, R3, and R4) concurrently through the standard network management interface and performs the synchronous collection of the following four types of information:

[0061] First, the link-layer discovery protocol (LLP) is collected: The self-healing center reads the adjacency relationships from the LLP neighbor table of each device and obtains the following results: R1 reports that it has LLP neighbors with R2 and R3; R2 reports that it has LLP neighbors with R1 and R4; R3 reports that it has LLP neighbors with R1 and R4; R4 reports that it has LLP neighbors with R2 and R3. Therefore, it can be determined that there are four physical links in the network: L12 (R1–R2), L24 (R2–R4), L13 (R1–R3), and L34 (R3–R4).

[0062] Secondly, the Address Resolution Protocol (ARP) is collected: the self-healing center extracts the mapping relationship between IP addresses and MAC addresses from the ARP table of each device. For example, on R1, the valid MAC addresses corresponding to the IP addresses of interfaces R2 and R3 can be found, indicating that the Layer 2 communication between R1 and R2 / R3 is normal.

[0063] Third, the routing table is collected: The self-healing center reads the IPv4 routing table of each device to obtain fields such as destination network segment, next-hop address, outgoing interface, and routing protocol type. For example, R1's routing table contains multiple route entries to different destination network segments, each of which explicitly specifies the next-hop IP and outgoing interface.

[0064] Fourth, collect bidirectional forwarding detection session status information: The self-healing center queries the list of configured bidirectional forwarding detection sessions on each device to obtain parameters such as the session local identifier, remote identifier, current status, detection time interval, and historical interruption count. For example, a bidirectional forwarding detection session is found on R1, with its remote address being the interface IP of R2, its current status being Up, and the number of interruptions in the last 5 minutes being 0; no bidirectional forwarding detection session is found on R3, indicating that bidirectional forwarding detection monitoring is not enabled on this device.

[0065] Step 2: Based on the link layer discovery protocol, address resolution protocol, routing table, and bidirectional forwarding detection session state information, construct a directed graph model including several nodes and links.

[0066] The self-healing center abstracts all managed routers in the network as nodes in a directed graph. In this example, the node set is {R1, R2, R3, R4}. It determines the physical adjacency relationships between devices based on link-layer discovery protocol information and establishes directed edges accordingly: for example, if R1's link-layer discovery protocol neighbor table contains R2, then a directed edge R1→R2 is added to the graph; similarly, based on the link-layer discovery protocols reported by each device, directed edges such as R2→R1, R1→R3, R3→R1, R2→R4, R4→R2, R3→R4, and R4→R3 are generated, forming the basic topology of the graph.

[0067] The self-healing center collects address resolution protocol, routing table, and bidirectional forwarding detection session state information, and associates it as attribute data with the corresponding nodes and links. For example:

[0068] Associate the entire address resolution protocol table of R1 with node R1;

[0069] Associate the route entry for destination network segment D in the routing table of R1 with node R1;

[0070] Associate the current state, session identifier, and configuration parameters of the bidirectional forwarding detection session configured between R1 and R2 with links R1→R2 and R2→R1.

[0071] Through the above processing, the constructed directed graph model not only expresses the topological connections of the network, but also includes raw state information from multiple protocol sources for each node and each link.

[0072] Step 3: Identify the primary path of the current traffic based on the bidirectional forwarding detection session state information, and determine the faulty link segment based on the primary path.

[0073] In this embodiment, the self-healing center analyzes the collected bidirectional forwarding detection session status information. Assume the system detects that the current state of the bidirectional forwarding detection session configured between R1 and R2 changes from normal to interrupted, and the monitoring object associated with this session is link L12 (i.e., the physical connection between R1 and R2). Since this bidirectional forwarding detection session is used to monitor the critical links of the primary forwarding path in real time, its status change is used as a fault trigger signal.

[0074] Furthermore, the self-healing center combines routing table information to confirm the actual forwarding path of the current traffic: for example, R1's routing table shows that the optimal next hop to the target network segment D is R2, and R2's routing table shows that the next hop is R4. From this, it can be inferred that the current primary path is R1 → R2 → R4. Since the only link in this path with a bidirectional forwarding detection session deployed is L12 (R1–R2), and this session has been reported as interrupted, the self-healing center determines that the faulty link segment is L12, that is, the link segment from R1 to R2 in the primary path has failed.

[0075] Step 4: Generate a dynamic state identifier set based on the address resolution protocol, routing table, and failed link segment, including the following steps:

[0076] Step 41: Extract the destination IP prefix corresponding to the primary path based on the routing table, and determine the upstream node of the faulty link segment.

[0077] The self-healing center retrieves the optimal route entry for forwarding service traffic from the routing table of the primary path's originating device and extracts the destination IP prefix matching that entry. This destination IP prefix represents the target service network segment affected by the fault and will serve as the traffic identifier for subsequent probing and path calculation. Based on the data flow direction of the primary path, the self-healing center analyzes the two endpoints of the faulty link segment: the node located at the front end of the data flow direction and responsible for sending traffic to the faulty link is identified as the upstream node of that faulty link segment.

[0078] Step 42: Query all adjacent links of the upstream node in the directed graph model to obtain the set of adjacent links.

[0079] Step 43: Based on the destination IP prefix, query the routing table of the upstream node to determine the next-hop node, and determine the outgoing interface used by the upstream node to the next-hop node.

[0080] The self-healing center performs longest prefix matching in the routing table of the upstream node to find a routing entry that matches the destination IP prefix. If a match is found, the IP address of the next-hop node is extracted from that routing entry and used as the forwarding target immediately following the upstream node in the primary path. Simultaneously, the self-healing center obtains the corresponding outgoing interface information from the same routing entry; this outgoing interface is the physical or logical interface actually used by the upstream node when forwarding traffic to the next-hop node.

[0081] Step 44: Mark the adjacent links corresponding to the outgoing interface as primary direction links, and remove the primary direction links from the set of adjacent links to obtain a set of non-primary adjacent links.

[0082] Step 45: Query the active host address corresponding to the destination IP prefix based on the address resolution protocol, and construct a probe packet based on the active host address.

[0083] From the collected Address Resolution Protocol (ARP) entries, entries whose IP addresses fall within the range of the destination IP prefix are selected. Since the continued existence of ARP entries typically indicates that the corresponding host is currently active and has Layer 2 reachability, these IP addresses are identified as active host addresses in the network segment. The self-healing center constructs a network layer probe packet for link probing based on the acquired active host addresses. One of the active host addresses is used as the destination IP address of the probe packet, and the IP address of the upstream node on the corresponding outgoing interface is used as the source IP address. This is then encapsulated into a standard Layer 3 probe packet (e.g., an ICMP Echo Request packet or a UDP packet on a specified port). The purpose of this packet is to simulate the forwarding behavior of real business traffic, triggering normal routing and forwarding processing by devices along the path. The actual carrying capacity of the non-primary adjacent link for real business traffic is determined by whether a response is received.

[0084] Step 46: Based on the upstream node, send the probe message through each non-primary adjacent link in the set of non-primary adjacent links to obtain the round-trip delay sequence.

[0085] The self-healing center instructs upstream nodes to forcibly bind the outgoing interface of probe packets to the local physical or logical interface corresponding to the currently traversed non-primary adjacent link, thereby ensuring that the packet is actually sent via that link. For each non-primary adjacent link, the upstream node repeatedly sends probe packets one or more times and starts a high-precision timer; if a response packet is received from the destination active host within a preset time, the time interval from sending to receiving is calculated as the round-trip delay of that probe. The round-trip delays obtained from all valid probes are organized in link order or time order to form a corresponding round-trip delay sequence. The round-trip delay sequence is used to determine whether the link has end-to-end forwarding capability.

[0086] Step 47: If a non-primary adjacent link receives a response data packet within a preset time, the non-primary adjacent link is marked as reachable for forwarding; extract the bidirectional forwarding detection session state information corresponding to the non-primary adjacent link; if the non-primary adjacent link does not receive a response data packet within a preset time and the bidirectional forwarding detection session state information is normal, the non-primary adjacent link is marked as blocked by policy; if the non-primary adjacent link does not receive a response data packet within a preset time and the bidirectional forwarding detection session state information is interrupted, the non-primary adjacent link is marked as a link failure.

[0087] The preset time is preferably 50ms-200ms. If a response is received within the preset time, it indicates that the probe traffic has successfully traversed the entire path and been processed by the destination host, proving that the current non-primary adjacent link has actual end-to-end forwarding capability, and is therefore marked as forwarding reachable. If no response is received, but the corresponding bidirectional forwarding detection session status is normal (Up), it indicates that the underlying connectivity of the link is intact (no abnormalities in the physical layer, data link layer, and BFD session). In this case, the probe failure is most likely due to the policy-based dropping of intermediate nodes (such as security groups, routing policy filtering, etc.). Such problems will not affect BFD control messages (because they usually go through the control channel or high-priority queue), but will block ordinary service flows, so the link is marked as policy-blocked. If no response is received and the bidirectional forwarding detection session status is interrupted (Down), it indicates that the link itself has lost basic connectivity (such as fiber breakage, interface failure, protocol negotiation failure, etc.), and the probe message cannot be delivered to the remote end, so it is marked as link failure.

[0088] Whether a response data packet is received within a preset time in this embodiment reflects the actual carrying capacity of the link for actual service traffic. Combined with the corresponding bidirectional forwarding detection session status information, the root cause of no response can be further distinguished: if no response data packet is received but the bidirectional forwarding detection session status information is normal, it indicates that the underlying connectivity of the link is not interrupted, but the traffic is dropped by intermediate devices due to policy reasons, and is therefore marked as policy blocking; if the bidirectional forwarding detection session status information is interrupted, it indicates that the link itself has failed, and is marked as link failure; only when a response data packet is received is the link confirmed to have end-to-end forwarding capability, and is marked as forwarding reachable. This avoids mistakenly including links that only exist in the routing table but cannot actually forward service traffic in the candidate path, thereby effectively preventing service interruption after handover and significantly improving the accuracy of fault location.

[0089] Step 48: The forwarding reachability, policy blocking, and link failure are used as status labels for non-primary adjacent links and integrated into a dynamic status label set.

[0090] Step 5: Based on the directed graph model and the dynamic state flag set, generate candidate optimization paths, including the following steps:

[0091] Step 51: Extract the path endpoint node based on the primary path, define the upstream node of the faulty link segment as the path starting node, and search all connected paths from the path starting node to the path endpoint node without passing through the faulty link segment based on the directed graph model to form an initial path set.

[0092] The last node extracted from the primary path is designated as the path endpoint, which is the final target device to which the service traffic arrives. The upstream node of the identified faulty link segment is defined as the path start node, serving as the starting position for new path searching.

[0093] Based on this, using the starting node of the path as the source and the ending node of the path as the destination, all possible directed paths in the directed graph model are traversed, and any path containing the faulty link segment is excluded. During the search process, only paths that satisfy the connectivity condition are retained, that is, there are valid directed edges between adjacent nodes in the path, and the actual links corresponding to each edge have established association information in the directed graph model. All paths that satisfy the above conditions are collected to form the initial path set.

[0094] Step 52: Traverse each connected path in the initial path set, and identify the first hop link starting from the path's starting node based on the current initial path; if the first link is a non-primary adjacent link and its status label is link failure or policy blocking, then remove the current initial path.

[0095] The process iterates through each initial path in the initial path set. For the current initial path, it first identifies the first-hop link used by the starting node, i.e., the directed link connecting the starting node and its next-hop node. It then determines whether this first-hop link is a non-primary adjacent link and queries its status label. If the first-hop link is a non-primary adjacent link and its status label is "link failure," it indicates a physical or protocol layer interruption, preventing the forwarding of service traffic. If its status label is "policy blocking," it indicates that although the first-hop link is connected at the underlying level, service packets are dropped due to policy restrictions of intermediate devices, also lacking actual forwarding capability. In both cases, although the initial path is topologically connected, its first-hop link is unavailable, failing to guarantee end-to-end service reachability; therefore, the initial path is removed from the initial path set.

[0096] Step 53: Mark the remaining initial paths after elimination as remaining paths, identify the status labels as remaining paths that can be forwarded, and obtain the set of paths to be evaluated.

[0097] Step 54: For each remaining path in the set of paths to be evaluated, perform path stability evaluation to generate candidate optimized paths, including the following steps:

[0098] Step 541: Extract the bidirectional forwarding detection session status information within the most recent monitoring period for each link of the remaining path, and obtain the number of session interruptions.

[0099] Extract the running records of bidirectional forwarding detection sessions within the most recent monitoring period (e.g., the past 5 minutes, 10 minutes, or a time window dynamically set according to network operation and maintenance policies) from historical monitoring data, and count the number of session interruptions, that is, the cumulative number of times the BFD status of each link changes from normal to interrupted during this period.

[0100] Step 542: Determine the time delay fluctuation index based on the round-trip time delay sequence.

[0101] For each non-primary adjacent link, the standard deviation is calculated based on the round-trip delay sequence and marked as a delay fluctuation index.

[0102] Step 543: If any link satisfies the following condition, the current remaining path is marked as the first stable path and the next step is executed; otherwise, the current remaining path is marked as the second stable path and added to the candidate path subset.

[0103] The specific conditions are: the number of session interruptions is greater than a preset number, and the latency fluctuation index is greater than a preset index.

[0104] The preset number of attempts is preferably 2, and the preset target is 5ms. If any link in the current remaining path exceeds both of the above thresholds at the same time, it indicates that the path contains a significantly unstable transmission segment, and the path is marked as the first stable path (i.e., a low-stability path). If none of the links in the path exceed both thresholds (preset number of attempts and preset target) at the same time, the path is considered to be stable and reliable overall, and it is marked as the second stable path (i.e., a high-stability path) and directly added to the candidate path subset.

[0105] Step 544: Identify the adjacent links between adjacent nodes in the first stable path. If there are N adjacent links whose status labels are forwarding reachable, mark the remaining path as a path to be reinforced, reinforce the path to be reinforced and add it to the candidate subset; otherwise, remove the remaining path; where N≥2.

[0106] The path to be reinforced is reinforced and added to the candidate subset, including:

[0107] Identify the links to be reinforced in the path based on the status labels of N adjacent links.

[0108] Iterate through each link in the path to be reinforced, and for each downstream node of a link, query the state labels of all outgoing adjacent links in the directed graph model. If the number of forwarding reachable adjacent links associated with that downstream node is not less than N (where N≥2), then the next link used in the current path starting from that downstream node is determined to be a link to be reinforced. When a node has at least N forwarding reachable adjacent links, it indicates that there is an alternative exit point, and if the link selected in the current path is a low-stability link, it can be identified as a link to be reinforced that needs to be replaced.

[0109] The upstream and downstream reinforcement nodes are determined based on the link to be reinforced.

[0110] The directed edges corresponding to the link to be reinforced in the directed graph model are analyzed: the starting node of the directed edge is the upstream reinforcement node, which represents the device where the traffic is located before entering the link to be reinforced; the ending node of the directed edge is the downstream reinforcement node, which represents the next hop device that the traffic reaches after passing through the link to be reinforced.

[0111] Starting from the upstream reinforced node and ending at the downstream reinforced node, a connected path that does not pass through the link to be reinforced is searched in the directed graph model and marked as an alternative sub-path. Alternative sub-paths with a forwarding reachable status label are selected and defined as filtered paths. The path to be reinforced is reconstructed based on the filtered paths to obtain a reinforced path, which is then added to the candidate subset. The portion of the path to be reinforced before the upstream reinforced node is taken as the front-end path, and the portion after the downstream reinforced node is taken as the back-end path. The front-end path, any of the filtered paths, and the back-end path are sequentially concatenated to generate the reinforced path.

[0112] Step 545: Generate candidate optimization paths based on the candidate subset.

[0113] Based on the second stable path and the reinforced path of the candidate subset, the number of links is identified; for the second stable path and the reinforced path, they are arranged in ascending order according to the number of links to obtain a permutation set, and all second stable paths are placed before the reinforced paths. The first k second stable paths and / or reinforced paths in the permutation set are taken as candidate optimization paths, where k≥2.

[0114] Each path in the candidate subset is traversed, and the number of links it contains is counted, i.e., the total number of directed links from the starting node to the ending node of the path, which is taken as the link count of that path. Then, the second stable paths and the reinforced paths are internally sorted: within the second stable path set, they are sorted in ascending order of link count; within the reinforced path set, they are also sorted in ascending order of link count. Finally, the sorted second stable paths are placed before the reinforced paths, merging them into a unified permutation set.

[0115] In this permutation set, high-priority paths have two characteristics: first, they belong to the second most stable path (i.e., high stability); second, they have fewer links (i.e., fewer forwarding hops, lower latency, and lower resource consumption). Finally, the self-healing center selects the first k paths (where k is a preset positive integer and k≥2) from the beginning of this permutation set as the final candidate optimization paths.

[0116] Step 6: Determine and execute network configuration instructions based on the candidate optimized paths to obtain the repair strategy.

[0117] The target optimization path is determined based on the candidate optimization paths. The node sequence of the target repair path is parsed, and the outgoing interfaces between adjacent nodes are extracted. Local forwarding configuration instructions for each node are generated based on the outgoing interfaces.

[0118] The highest priority path is selected from the candidate optimization paths as the target optimization path (the first path in the permutation set), and the node sequence of this path is parsed to obtain a list of routers traversed in sequence. For each pair of adjacent nodes in the node sequence, the physical or logical outgoing interfaces used from the upstream node to the downstream node are queried to form a complete outgoing interface sequence.

[0119] Based on this outgoing interface sequence, a corresponding local forwarding configuration command is generated for each device involved in the candidate optimized path. The specific form of the configuration command depends on the device type and network architecture: for traditional IP routers, the command is a static route configuration command, such as adding a static route on the upstream node pointing to the destination network segment, with the next hop being the downstream node, and the outgoing interface being the specified interface; for SDN-enabled switches or white-box devices, the command is an OpenFlow flow table entry, containing matching fields (such as the destination IP prefix), action fields (such as output to a specified port), and timeout parameters. All configuration commands are automatically sent to the corresponding devices and activated via standard protocols (such as NETCONF, SNMP, or OpenFlow).

[0120] The resulting remediation strategy is a set of coordinated local forwarding configuration instructions. Its overall effect is to seamlessly switch service traffic that was originally routed through the faulty link to the target optimized path for forwarding. This strategy does not rely on routing protocol reconvergence and can be deployed within seconds, ensuring service continuity while avoiding forwarding failures or loop risks caused by improper path selection.

[0121] like Figure 2 As shown, a network fault repair system based on multi-protocol detection includes the following modules:

[0122] Data acquisition module: used to collect link layer discovery protocol, address resolution protocol, routing table and bidirectional forwarding detection session state information;

[0123] Graph construction module: used to construct a directed graph model including several nodes and links based on link layer discovery protocol, address resolution protocol, routing table and bidirectional forwarding detection session state information;

[0124] Fault location module: used to identify the primary path of the current traffic based on the bidirectional forwarding detection session state information, and to determine the faulty link segment based on the primary path;

[0125] Status Identification Module: Used to generate a dynamic status identification set based on the address resolution protocol, routing table, and faulty link segments;

[0126] Optimization module: used to generate candidate optimization paths based on the directed graph model and dynamic state flag set;

[0127] Repair module: used to determine and execute network configuration instructions based on the candidate optimized paths to obtain a repair strategy.

[0128] To implement the above embodiments, this application also proposes an electronic device. Please see [link to relevant documentation]. Figure 3 , Figure 3 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 500 includes: a processor 501 and a memory 502 communicatively connected to the processor 501; the memory 502 stores computer-executable instructions; the processor 501 executes the computer-executable instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0129] To implement the above embodiments, this application also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0130] To implement the above embodiments, this application also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0131] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A network fault repair method based on multi-protocol detection, characterized in that, Includes the following steps: Step 1: Collect link layer discovery protocol, address resolution protocol, routing table, and bidirectional forwarding detection session state information; Step 2: Based on the link layer discovery protocol, address resolution protocol, routing table, and bidirectional forwarding detection session state information, construct a directed graph model including several nodes and links; Step 3: Identify the primary path of the current traffic based on the bidirectional forwarding detection session state information, and determine the faulty link segment based on the primary path; Step 4: Generate a dynamic status identifier set based on the address resolution protocol, routing table, and faulty link segment; Step 5: Generate candidate optimization paths based on the directed graph model and the dynamic state identifier set; Step 6: Determine and execute network configuration instructions based on the candidate optimized paths to obtain the repair strategy.

2. The network fault repair method based on multi-protocol detection according to claim 1, characterized in that, Generating a dynamic state flag set includes the following steps: Step 41: Extract the destination IP prefix corresponding to the primary path based on the routing table, and determine the upstream node of the faulty link segment; Step 42: Query all adjacent links of the upstream node in the directed graph model to obtain the set of adjacent links; Step 43: Based on the destination IP prefix, query the routing table of the upstream node to determine the next-hop node, and determine the outgoing interface used by the upstream node to the next-hop node; Step 44: Mark the adjacent links corresponding to the outgoing interface as primary direction links, and remove the primary direction links from the set of adjacent links to obtain a set of non-primary adjacent links; Step 45: Query the active host address corresponding to the destination IP prefix based on the address resolution protocol, and construct a probe packet based on the active host address; Step 46: Based on the upstream node, send the probe message through each non-primary adjacent link in the set of non-primary adjacent links to obtain the round-trip delay sequence; Step 47: If a non-primary adjacent link receives a response data packet within a preset time, the non-primary adjacent link is marked as reachable for forwarding; extract the bidirectional forwarding detection session state information corresponding to the non-primary adjacent link; if the non-primary adjacent link does not receive a response data packet within a preset time and the bidirectional forwarding detection session state information is normal, the non-primary adjacent link is marked as blocked by policy; if the non-primary adjacent link does not receive a response data packet within a preset time and the bidirectional forwarding detection session state information is interrupted, the non-primary adjacent link is marked as a link failure. Step 48: The forwarding reachability, policy blocking, and link failure are used as status labels for non-primary adjacent links and integrated into a dynamic status label set.

3. The network fault repair method based on multi-protocol detection according to claim 2, characterized in that, Based on the directed graph model and the dynamic state identifier set, candidate optimization paths are generated, including the following steps: Step 51: Extract the path endpoint node based on the primary path, define the upstream node of the faulty link segment as the path starting node, and search all connected paths from the path starting node to the path endpoint node without passing through the faulty link segment based on the directed graph model to form an initial path set. Step 52: Traverse each connected path in the initial path set, and identify the first hop link starting from the path's starting node based on the current initial path; if the first link is a non-primary adjacent link and its status label is link failure or policy blocking, then remove the current initial path. Step 53: Mark the remaining initial paths after elimination as remaining paths, identify the status labels of the remaining paths that can be forwarded, and obtain the set of paths to be evaluated; Step 54: For each remaining path in the set of paths to be evaluated, perform path stability evaluation to generate candidate optimized paths.

4. The network fault repair method based on multi-protocol detection according to claim 3, characterized in that, For each remaining path in the set of paths to be evaluated, a path stability assessment is performed, including the following steps: Step 541: Extract the bidirectional forwarding detection session status information within the most recent monitoring period for each link of the remaining path, and obtain the number of session interruptions; Step 542: Determine the time delay fluctuation index based on the round-trip time delay sequence; Step 543: If any link satisfies the following condition, then mark the current remaining path as the first stable path and proceed to the next step; otherwise, mark the current remaining path as the second stable path and add it to the candidate path subset. The specific conditions are: the number of session interruptions is greater than a preset number, and the latency fluctuation index is greater than a preset index; Step 544: Identify the adjacent links between adjacent nodes in the first stable path. If there are N adjacent links whose status labels are forwarding reachable, mark the remaining path as a path to be reinforced, reinforce the path to be reinforced and add it to the candidate subset; otherwise, remove the remaining path; where N≥2. Step 545: Generate candidate optimization paths based on the candidate subset.

5. A network fault repair method based on multi-protocol detection according to claim 4, characterized in that, The path to be reinforced is reinforced and added to the candidate subset, including: Identify the links to be reinforced in the path to be reinforced based on the status labels of N adjacent links; The upstream and downstream reinforcement nodes are determined based on the link to be reinforced. Starting from the upstream reinforcement node and ending at the downstream reinforcement node, a connected path that does not pass through the link to be reinforced is searched in the directed graph model and marked as an alternative sub-path. Filter out alternative sub-paths whose status labels are reachable by forwarding and define them as filter paths; The paths to be reinforced are reconstructed based on the filtered paths, and the reinforced paths are added to the candidate subset.

6. A network fault repair method based on multi-protocol detection according to claim 5, characterized in that, The reinforcement path is reconstructed according to the selected path to obtain the reinforcement path, including: taking the part of the path to be reinforced before the upstream reinforcement node as the front path, taking the part of the path after the downstream reinforcement node as the back path, and sequentially splicing the front path, any of the selected paths, and the back path to generate the reinforcement path.

7. A network fault repair method based on multi-protocol detection according to claim 6, characterized in that, Based on the second stable path and the reinforced path of the candidate subset, the number of links is identified; for the second stable path and the reinforced path, they are arranged in ascending order according to the number of links to obtain a permutation set, and all second stable paths are placed before the reinforced paths. The first k second stable paths and / or reinforced paths in the permutation set are taken as candidate optimization paths, where k≥2.

8. A network fault repair method based on multi-protocol detection according to claim 7, characterized in that, The network configuration instruction determined based on the candidate optimization path includes: determining the target optimization path based on the candidate optimization path, parsing the node sequence of the target repair path, and extracting the outgoing interfaces between adjacent nodes; and generating local forwarding configuration instructions for each node based on the outgoing interfaces.

9. A network fault repair system based on multi-protocol detection, used to execute the network fault repair method based on multi-protocol detection as described in any one of claims 1-8, characterized in that, Includes the following modules: Data acquisition module: used to collect link layer discovery protocol, address resolution protocol, routing table and bidirectional forwarding detection session state information; Graph construction module: used to construct a directed graph model including several nodes and links based on link layer discovery protocol, address resolution protocol, routing table and bidirectional forwarding detection session state information; Fault location module: used to identify the primary path of the current traffic based on the bidirectional forwarding detection session state information, and to determine the faulty link segment based on the primary path; Status Identification Module: Used to generate a dynamic status identification set based on the address resolution protocol, routing table, and faulty link segments; Optimization module: used to generate candidate optimization paths based on the directed graph model and dynamic state flag set; Repair module: used to determine and execute network configuration instructions based on the candidate optimized paths to obtain a repair strategy.

Images