Network fault processing method, electronic device, storage medium and program product

Abstract

This invention provides a network fault handling method, electronic device, storage medium, and program product, relating to the field of communication technology. The method includes: in response to a detected network link fault, acquiring initial fault information and starting a delay timer to enter a routing waiting window; within the routing waiting window, if duplicate fault information for the same link is received, merging the duplicate fault information into the initial fault information; when the routing waiting window ends, determining whether the network link fault corresponding to the initial fault information has recovered; if the network link fault has not recovered, starting a routing re-optimization system to calculate a new primary path and distributing the new primary path to network devices, so that the network devices switch traffic to the new primary path for forwarding. This invention can effectively guarantee overall network performance.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a network fault handling method, electronic device, storage medium, and program product. Background Technology

[0002] In recent years, Software-Defined Networking (SDN) has been widely used in traffic engineering and path optimization in complex network environments due to its centralized control and flexible programming capabilities. In SDN architecture, path re-optimization mechanisms are a key means to achieve efficient network resource utilization and service quality assurance. Existing technologies typically improve network resource utilization efficiency and service transmission quality to some extent by explicitly configuring tunnel head nodes and combining real-time network status data, historical traffic information, entropy weighting methods, and machine learning models to perform path calculation and optimization decisions.

[0003] However, existing solutions have significant limitations when facing network failures. Specifically, when a failure occurs, existing mechanisms often trigger re-optimization calculations instantly, failing to fully consider the actual situation of drastic fluctuations in network status and a large amount of redundant alarm information in the early stages of a failure. At this time, the re-optimized path calculated based on instantaneous state data not only may lead to distortion of the re-optimized path, but also easily exacerbates routing oscillations due to frequent re-optimization triggers, seriously affecting network performance. Summary of the Invention

[0004] This invention provides a network fault handling method, electronic device, storage medium, and program product to solve the technical problem in the prior art where re-optimization using instantaneous state data leads to distortion of the re-optimized path, aggravates routing oscillations, and thus seriously affects network performance.

[0005] This invention provides a network fault handling method, comprising: In response to a detected network link failure, the system acquires initial failure information and starts a delay timer to enter the routing waiting window. If repeated fault information for the same link is received within the routing waiting window, the repeated fault information is merged into the first fault information. When the routing waiting window ends, it is determined whether the network link fault corresponding to the initial fault information has been recovered; If the network link failure is not recovered, the routing re-optimization system is activated to calculate a new primary path and distribute the new primary path to the network devices so that the network devices can switch traffic to the new primary path for forwarding.

[0006] According to a network fault handling method provided by the present invention, a BGP-LS neighbor is configured between the network controller and the network device; wherein, prior to responding to a detected network link fault, the method further includes: Receive real-time network topology information reported by the network device using the BGP-LS protocol, wherein the real-time network topology information includes device connection status, load status, and traffic statistics; Based on the real-time network topology information, the network link status is continuously monitored, wherein the network link status includes the status of monitoring devices, link status, and routing prefix information.

[0007] According to a network fault handling method provided by the present invention, if repeated fault information for the same link is received within the routing waiting window, the repeated fault information is merged into the initial fault information, comprising: Within the routing waiting window, multiple fault messages reported by the network device are received; Extract the link identifiers of the multiple fault information; If the link identifier in the fault information is the same as the link identifier in the initial fault information, then the fault information is determined to be a duplicate fault information, and the duplicate fault information is merged into the initial fault information.

[0008] According to a network fault handling method provided by the present invention, the step of activating the routing re-optimization system to calculate a new primary path includes: Start the routing re-optimization system; The path re-optimization system obtains the link information and delay constraints corresponding to the initial fault information. The routing re-optimization system calculates a new primary path based on the link information and the delay constraints.

[0009] The present invention also provides a network fault handling method, applied to network devices, comprising the following steps: The system receives a new primary path issued by the network controller and switches traffic to the new primary path for forwarding. The new primary path is calculated and issued by the routing reoptimization system after the network controller starts a delay timer to enter a routing waiting window after obtaining the first fault information. Within the routing waiting window, the received repeated fault information is merged into the first fault information. If it is determined that the network link fault has not been recovered when the routing waiting window ends, the new primary path is calculated and issued by the routing reoptimization system.

[0010] According to a network fault handling method provided by the present invention, the step of receiving a new primary path issued by the network controller and switching traffic to the new primary path for forwarding includes: When a network link failure is detected, the traffic affected by the failure will be switched from the primary path to the backup path for forwarding. The system receives a new primary path from the network controller and switches the traffic from the backup path to the new primary path for forwarding.

[0011] According to a network fault handling method provided by the present invention, when a network link fault is detected, the traffic affected by the fault is switched from the primary path to the backup path for forwarding, including: When a network link failure is detected by the seamless bidirectional forwarding detection mechanism, the local routing protocol is triggered to recalculate the converged route and determine the backup path based on the converged route. Traffic affected by the fault will be switched from the primary path to the backup path for forwarding.

[0012] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the network fault handling methods described above.

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

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

[0015] This invention provides a network fault handling method, electronic device, storage medium, and program product. In response to a detected network link fault, the method acquires initial fault information and initiates a delay timer to enter a routing waiting window. Within the routing waiting window, if duplicate fault information for the same link is received, the duplicate fault information is merged into the initial fault information. When the routing waiting window ends, it is determined whether the network link fault corresponding to the initial fault information has been recovered. If the network link fault has not been recovered, a routing re-optimization system is initiated to calculate a new primary path, and the new primary path is distributed to network devices so that the network devices switch traffic to the new primary path for forwarding. This invention addresses the technical problem of distorted reoptimized paths and exacerbated routing oscillations caused by using instantaneous state data for reoptimization, which severely impacts network performance. Compared to existing technologies, this invention sets a routing waiting window to postpone reoptimization decisions during periods of drastic network state fluctuations in the early stages of a fault, and merges and compresses duplicate fault information. This effectively avoids invalid reoptimization and routing oscillations caused by instantaneous data distortion. Furthermore, after the waiting window expires, reoptimization is only triggered for faults that have not yet recovered, ensuring the accuracy and necessity of reoptimization decisions. This improves the efficiency of routing reoptimization and guarantees the stability of overall network performance. Attached Figure Description

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

[0017] Figure 1 This is one of the flowcharts of the network fault handling method provided by the present invention.

[0018] Figure 2 This is a schematic diagram of the SDN network structure of the network fault handling method provided by the present invention.

[0019] Figure 3 This is a schematic diagram of the window period interaction of the network fault handling method provided by the present invention.

[0020] Figure 4 This is a schematic diagram of the routing optimization interaction of the network fault handling method provided by the present invention.

[0021] Figure 5 This is the second flowchart of the network fault handling method provided by the present invention.

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

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

[0024] The following is combined with Figure 1 and Figure 5 The present invention describes a network fault handling method applicable to any network fault handling. The subject executing this method can be an electronic device or a network fault handling device installed in the electronic device. The network fault handling device can be implemented by software, hardware, or a combination of both.

[0025] Figure 1 This is one of the flowcharts illustrating the network fault handling method provided by the present invention, such as... Figure 1 As shown, the network fault handling method is applied to a network controller, and the method includes the following: Step 101: In response to the detected network link failure, obtain the initial failure information and start a delay timer to enter the routing waiting window; It is understandable that, such as Figure 2 The diagram illustrates an SDN (Software-Defined Networking) network architecture. In an SDN network, the network controller receives instructions from the upper-layer orchestration system to enable services. It interacts with network devices via protocols such as BGP-LS / SNMP / NETCONF, distributing the necessary network-wide configurations, including but not limited to routing policies and VPN identifiers. Simultaneously, a BGP-LS (Border Gateway Protocol-Link State) peer relationship is established between the network controller and network devices. Network devices are responsible for collecting network information and reporting it to the network controller in real-time using the BGP-LS protocol. Based on this continuously reported topology information, the network controller maintains a real-time view of the entire network and continuously monitors network link status, enabling it to detect changes in link status immediately when network failures occur.

[0026] It should be noted that when a network failure occurs (such as equipment downtime or link interruption), or when frequent momentary interruptions occur, the network controller records the initial failure information and caches it in the Redis database. Simultaneously, a timing mechanism is triggered to enter a waiting state. By setting a routing waiting window, a buffer period is provided to the network, preventing the immediate triggering of the routing re-optimization system due to link interruptions or short-term jitter, thus preventing routing oscillations caused by frequent path recalculation. During the routing waiting window, the network controller only monitors the network status and does not perform path optimization operations, ensuring that path optimization is only performed after the fault persists and the network stabilizes, thereby improving the accuracy and effectiveness of routing tuning. Furthermore, the acquired initial failure information will serve as the merging benchmark for subsequent repeated failure alarms on the same link, providing a basis for implementing the oscillation compression strategy.

[0027] It should be noted that the window duration of the routing waiting window can be pre-configured according to the actual network requirements and business scenarios. The delay timer, as the timing mechanism for implementing the routing waiting window, is started when a network link failure is detected and counts down according to the preset window duration. During the operation of the delay timer, the network controller does not trigger routing optimization, but only monitors the network status and merges fault information.

[0028] In the specific implementation, when the preset window duration is set to 0, the delay timer takes a value of 0, indicating that no delay processing is performed. After detecting a network link failure, the network controller immediately starts the routing re-optimization system and calculates the new primary path to carry the traffic affected by the failure, based on indicators such as latency constraints and link information. When the preset window duration is set to a value greater than 0, such as 5 minutes, the delay timer starts synchronously from the time the failure occurs and counts for 5 minutes. During this period, the network controller only performs monitoring and merging operations. After the 5-minute countdown expires, the decision on whether to start routing optimization is made based on whether the failure has been recovered.

[0029] Step 102: If repeated fault information for the same link is received within the routing waiting window, the repeated fault information is merged into the first fault information. It should be noted that during the routing waiting window, if the network controller receives duplicate fault information for the same link, these duplicate fault information will be merged into the already recorded first fault information. This operation is used to implement the oscillation compression strategy, avoiding the processing pressure on the controller caused by a large number of duplicate alarms due to frequent changes in link status, and preventing the controller from repeatedly triggering unnecessary internal processes due to receiving the same fault information multiple times. By merging duplicate fault information into the first fault information, the network controller only needs to maintain a single fault record and continuously monitor the actual status of the link based on the merged information, thereby significantly reducing system overhead while ensuring the integrity of fault information. In addition, the merging operation is only performed within the routing waiting window, ensuring that only duplicate alarms related to the current fault event are compressed.

[0030] Understandably, during the routing wait window, the network controller uses an oscillation compression strategy to merge duplicate fault information. Its core purpose is to effectively address the initial state fluctuations of a network fault. When a network link fails, it is often accompanied by repeated oscillations in the link's state, causing network devices to report the same fault information multiple times within a short period. If the network controller responds separately to each reported fault, it will not only consume significant computing resources to process redundant alarms but may also exacerbate routing oscillations due to frequent triggering of internal processes. By merging duplicate fault information for the same link into the initial fault information within the routing wait window, the network controller only needs to maintain a single fault record and continuously monitor the actual state changes of that link based on the merged information. This oscillation compression strategy ensures the integrity of fault information while significantly reducing system processing overhead. Furthermore, the merging operation is limited to the routing wait window, ensuring that only duplicate alarms closely related to the current fault event are compressed, without affecting the normal processing of other link faults. When the routing waiting window ends, the controller determines whether the link failure has been recovered based on the merged first fault information using protocols such as BGP-LS. If the failure has been recovered, the network controller does not intervene and the network device performs the primary and backup path switchback locally. If the failure has not been recovered, the network controller starts the routing system, calculates and generates a new primary and backup path based on the global network topology and service constraints, and sends it to the network device for forwarding.

[0031] Step 103: When the routing waiting window ends, determine whether the network link fault corresponding to the initial fault information has been recovered; It should be noted that when the routing waiting window ends (i.e., the delay timer times out), the network controller determines whether the network link corresponding to the initial fault information has recovered, based on the merged fault information and the real-time network topology information obtained through continuous monitoring. This operation is used to perform a final evaluation of the fault status after the buffer period to determine whether subsequent path optimization processing is required. Through this judgment, the network controller can distinguish between transient and persistent link outages, avoiding unnecessary routing adjustments for temporarily recovered links. This ensures that path recalculation is only triggered when the fault is indeed persistent, further improving network resource utilization efficiency and system stability. At the same time, the result of this judgment will directly determine the controller's subsequent behavior branch: if the link has recovered, the existing path is maintained; if it has not recovered, the routing re-optimization system is started to calculate a new path.

[0032] In specific implementations, such as Figure 3 As shown, when the routing wait window is not 0 (e.g., set to 5 minutes), the delay counter starts counting synchronously from the moment the fault occurs. During the delay counter's counting period, the network controller obtains the aggregated IGP protocol topology information through the BGP protocol and continuously monitors the network status in conjunction with the characteristics of protocols such as BGP-LS, including but not limited to monitoring device status, link status, and routing prefixes. The real-time network topology information obtained from this continuous monitoring provides data support for fault judgment after the routing wait window ends. When the routing wait window ends, the controller comprehensively judges whether the link fault has been recovered based on the fault information stored during the window and the latest network status obtained from real-time monitoring. If the monitoring data shows that the link status has recovered to UP and the relevant routing prefix is ​​reachable again, the fault is determined to be recovered, and the network controller does not trigger routing optimization. If the monitoring data shows that the link status is still DOWN and the relevant routing prefix is ​​unreachable, the fault is determined to be unrecoverable, and the controller immediately starts the routing re-optimization system to calculate a new path.

[0033] Step 104: If the network link failure is not recovered, start the routing re-optimization system to calculate a new primary path and distribute the new primary path to the network devices so that the network devices can switch traffic to the new primary path for forwarding.

[0034] It is understandable that the new primary path refers to an optimized forwarding path that the network controller recalculates and generates based on the real-time topology of the entire network, link status information, and service quality constraints after confirming that the link failure has not been resolved. This path is used to replace the backup path that network devices temporarily switch to when a failure occurs.

[0035] It should be noted that when the network controller determines that the link failure has not been recovered after the routing waiting window expires, it initiates the routing re-optimization system. Based on the current network status information (including but not limited to latency constraints, link load, bandwidth utilization, etc.), it calculates a new primary path and distributes the calculated new primary path to the relevant network devices. This operation is used to re-plan an optimal forwarding path that meets the service quality requirements for the traffic affected by the failure, after confirming that the failure is a persistent failure rather than a brief interruption, by leveraging the controller's global view and routing capabilities. Unlike the temporary backup path used for rapid switching at the device level, the routing optimization result (i.e., the new primary path) issued by the network controller is an optimized path calculated comprehensively under the entire network topology view, which can avoid local detours or resource congestion and improve the overall network resource utilization efficiency. After receiving the new primary path, the network devices switch the traffic from the temporary backup path to the new primary path for forwarding, thereby achieving a closed-loop process of the network from a failure state to a stable operating state while ensuring uninterrupted service.

[0036] In specific implementations, such as Figure 4 As shown, when a network link fails, the network device initially detects and reports the link change information to the network controller. The controller then starts a delay counter and enters a routing wait window. During the wait period, if the same link reports changes multiple times due to status fluctuations, the controller determines that they are of the same fault type through fault analysis and performs oscillation merging processing to effectively suppress alarm storms. Within the delay counter, if the link fault recovers on its own, the network device performs primary / backup path switching without controller intervention; if the fault has not recovered by the end of the counter, the controller determines it to be a persistent stable fault, starts the routing re-optimization system to calculate a new forwarding path and sends it to the network device, which then completes the traffic switching.

[0037] The network fault handling method provided in this embodiment of the invention obtains initial fault information in response to a detected network link fault and starts a delay timer to enter a routing waiting window. Within the routing waiting window, if duplicate fault information for the same link is received, the duplicate fault information is merged into the initial fault information. When the routing waiting window ends, it is determined whether the network link fault corresponding to the initial fault information has recovered. If the network link fault has not recovered, a routing re-optimization system is started to calculate a new primary path, and the new primary path is distributed to network devices so that the network devices switch traffic to the new primary path for forwarding. This invention addresses the technical problem of distorted reoptimized paths and exacerbated routing oscillations caused by using instantaneous state data for reoptimization, which severely impacts network performance. Compared to existing technologies, this invention sets a routing waiting window to postpone reoptimization decisions during periods of drastic network state fluctuations in the early stages of a fault, and merges and compresses duplicate fault information. This effectively avoids invalid reoptimization and routing oscillations caused by instantaneous data distortion. Furthermore, after the waiting window expires, reoptimization is only triggered for faults that have not yet recovered, ensuring the accuracy and necessity of reoptimization decisions. This improves the efficiency of routing reoptimization and guarantees the stability of overall network performance.

[0038] In one feasible implementation, the network controller and the network device are configured with BGP-LS neighbors; wherein, prior to responding to a detected network link failure, the method further includes: Receive real-time network topology information reported by the network device using the BGP-LS protocol, wherein the real-time network topology information includes device connection status, load status, and traffic statistics; Based on the real-time network topology information, the network link status is continuously monitored, wherein the network link status includes the status of monitoring devices, link status, and routing prefix information.

[0039] It should be noted that in an SDN network, a BGP-LS peering system (i.e., BGP-LS neighbor) is pre-configured between the network controller and network devices. This configuration is used to establish a channel for the controller to obtain the network topology. Based on this continuously reported topology information, the network controller maintains a real-time view of the entire network and continuously monitors the network link status, thereby enabling it to detect network link failures as soon as possible.

[0040] Understandably, after the delay counter starts counting down, during the routing wait window, the network controller needs to continuously acquire and monitor real-time changes in the network status to provide accurate data support for subsequent fault diagnosis and re-optimization decisions. Specifically, the controller obtains IGP protocol topology information aggregated and sent via the BGP protocol through pre-configured BGP-LS neighbor relationships. This information covers real-time network topology data such as device connectivity, load status, and traffic statistics. At the same time, the controller continuously monitors the network status by combining the characteristics of protocols such as BGP-LS, including monitoring device status (such as device online status and interface status), link status (such as link bandwidth utilization, latency, jitter, and other quality indicators), and routing prefix information (such as route reachability and route priority).

[0041] The network fault handling method provided in this invention configures BGP-LS neighbors between the network controller and network devices, and receives real-time network topology information reported by the network devices using the BGP-LS protocol. This information covers device connectivity, load, and traffic statistics. Based on this information, the network link status is continuously monitored, including device status, link status, and routing prefix information. This enables real-time and accurate perception of network topology and link status. The rich network information obtained through the BGP-LS protocol provides an accurate data foundation for subsequent fault detection and route recalculation optimization, effectively avoiding misjudgments or omissions due to missing or delayed network information, thereby improving the timeliness and accuracy of fault detection.

[0042] In one feasible implementation, if repeated fault information for the same link is received within the routing waiting window, the repeated fault information is merged into the initial fault information, including: Within the routing waiting window, multiple fault messages reported by the network device are received; Extract the link identifiers of the multiple fault information; If the link identifier in the fault information is the same as the link identifier in the initial fault information, then the fault information is determined to be a duplicate fault information, and the duplicate fault information is merged into the initial fault information.

[0043] It should be noted that after starting the delay timer and entering the routing wait window, the network controller continuously listens for and receives multiple fault messages reported by network devices. For each received fault message, the link identifier used to uniquely identify the link is extracted. This link identifier can be a link identifier, a source-destination IP address pair, an interface index, or other information that can uniquely identify a link. Then, the extracted link identifier is compared with the link identifier in the pre-stored initial fault message. If they match, the currently received fault message is determined to be a duplicate fault message for the same link. Next, the duplicate fault message is merged into the initial fault message, for example, by updating the fault occurrence count, refreshing the latest fault occurrence timestamp, or the cumulative fault duration in the initial fault message. At the same time, the duplicate fault message is ignored, a new routing wait window is not started for it, and no re-optimization calculation is triggered.

[0044] The network fault handling method provided in this invention receives multiple fault information reports from network devices within the routing waiting window, extracts their link identifiers, compares them with the initial fault information, and merges repeated fault information for the same link into the initial fault information. This effectively suppresses alarm storms in the early stages of network faults and prevents the network controller from consuming excessive computing and storage resources due to processing a large number of redundant alarm information. At the same time, by merging repeated fault information, it prevents frequent re-optimization calculations caused by multiple fault reports for the same link, avoids making distorted decisions based on instantaneous state data, thereby significantly suppressing routing oscillations, improving the accuracy and efficiency of routing re-optimization, and ensuring the stability and reliability of the overall network performance.

[0045] In one feasible implementation, initiating the routing re-optimization system to compute a new primary path includes: Start the routing re-optimization system; The path re-optimization system obtains the link information and delay constraints corresponding to the initial fault information. The routing re-optimization system calculates a new primary path based on the link information and the delay constraints.

[0046] It should be noted that when the network link failure has not been recovered after the routing waiting window ends, the network controller officially starts the routing re-optimization system to enter the path re-optimization phase. As the core routing module of the controller, the routing re-optimization system is responsible for replanning the optimal forwarding path for the affected traffic in the case of continuous failure. After starting the routing re-optimization system, it first obtains the link information (including the fault link identifier, the status of surrounding links, bandwidth utilization, etc.) and the latency constraints required by the service corresponding to the initial failure information. Based on these input parameters and combined with the network topology view maintained by the network controller, the routing re-optimization system calculates a new primary path that meets the service quality requirements of the service through a preset routing algorithm. This new primary path can effectively avoid the failure point and achieve traffic load balancing and path optimization from a global perspective, thereby replacing the backup path temporarily switched at the device level, and enabling the network to recover from the failure state to a stable and efficient operating state.

[0047] In its implementation, the route re-optimization system can perform path calculations based on a real-time network topology database maintained by the network controller, using a constrained shortest path first (SLTF) algorithm. Specifically, it first locates the faulty link based on the link identifier in the initial fault information and marks it as unavailable from the current topology, ensuring that the newly calculated primary path does not pass through the fault point. Subsequently, combining the acquired link information (such as the remaining bandwidth, latency jitter, and packet loss rate of each link) and service latency constraints, path calculations are performed in the remaining network topology. During the calculation process, latency is used as a hard constraint to ensure that the end-to-end latency of the new primary path meets the service quality requirements; at the same time, the bandwidth utilization of each link is comprehensively considered, and a load balancing strategy is used to prioritize links with lower loads, avoiding traffic being diverted to congested links, thereby improving the overall network resource utilization efficiency.

[0048] The network fault handling method provided in this invention activates a path re-optimization system when a network link fault is confirmed to be unrecoverable. This system acquires the link information and latency constraints corresponding to the initial fault information, and then calculates a new primary path based on the link information and latency constraints. This enables accurate and efficient path re-optimization even in scenarios where faults persist. On one hand, path calculation based on the link information corresponding to the initial fault information avoids path calculation errors caused by instantaneous state data distortion during network fluctuations. On the other hand, the introduction of latency constraints as a constraint condition for path calculation ensures that the calculated new primary path can meet the service quality requirements of service transmission, thereby improving service experience while ensuring path availability.

[0049] Figure 5 This is one of the flowcharts illustrating the network fault handling method provided by the present invention, such as... Figure 3 As shown, it is applied to network devices, such as Figure 5 As shown, the method includes the following: Step 201: Receive the new primary path issued by the network controller and switch the traffic to the new primary path for forwarding. The new primary path is calculated and issued by the routing re-optimization system after the network controller starts a delay timer to enter the routing waiting window after obtaining the first fault information. In the routing waiting window, the received repeated fault information is merged into the first fault information. When the routing waiting window ends and it is determined that the network link fault has not been recovered, the routing re-optimization system calculates and issues the new primary path.

[0050] In its implementation, when a network link fails for the first time, the controller does not immediately trigger re-optimization calculation. Instead, it starts a delay timer to enter a routing waiting window. During this window, if duplicate fault information for the same link is received, it is merged into the initial fault information, effectively suppressing alarm storms and routing oscillations in the early stages of a fault. Only when the routing waiting window ends and it is confirmed that the link fault has not been recovered, does the controller determine that the fault is in a stable state. At this point, the routing re-optimization system is started to calculate a new primary path and distribute it to the network devices. After receiving the new primary path, the network devices switch the traffic affected by the fault from the temporarily activated backup path to the new primary path for forwarding.

[0051] The network fault handling method provided in this invention, by receiving a new primary path issued by the controller after the routing waiting window and fault merging mechanism and switching traffic, can obtain a globally optimized forwarding path when the fault persists. This effectively avoids invalid re-optimization decisions caused by the distortion of instantaneous state data during network fluctuations, significantly suppresses routing oscillations, and improves the accuracy and efficiency of routing re-optimization. At the same time, combined with the rapid primary / backup switching on the network device side, it achieves the organic unity of rapid service recovery and long-term path optimization, thereby ensuring the stability and reliability of the overall network performance.

[0052] In one feasible implementation, receiving the new primary path issued by the network controller and switching traffic to the new primary path for forwarding includes: When a network link failure is detected, the traffic affected by the failure will be switched from the primary path to the backup path for forwarding. The system receives a new primary path from the network controller and switches the traffic from the backup path to the new primary path for forwarding.

[0053] It is understandable that the primary path refers to the preferred forwarding path for carrying service traffic under normal network conditions; the backup path refers to the alternative forwarding path that network devices temporarily switch to using through local fast protection mechanisms when a network link failure occurs; and the new primary path refers to the optimized forwarding path that the network controller recalculates and distributes based on global topology and service constraints through the routing re-optimization system after confirming that the fault has not been recovered, and is used to ultimately replace the backup path for carrying traffic.

[0054] It's important to note that in SDN networks, when links between devices are interrupted due to port downtime or other events, network devices typically detect the fault quickly through SBFD (Seamless Bidirectional Forwarding Detection) and immediately modify their session state identifiers. Based on locally recalculated routing information, they autonomously switch from the primary path to the backup path, without intervention from the network controller's routing system. This device-based rapid protection mechanism can achieve millisecond-level service recovery, ensuring uninterrupted traffic. However, its limitation lies in the fact that backup paths often only aim to maintain connectivity and are not globally optimized, potentially leading to increased latency and uneven load distribution.

[0055] In practice, when a network device detects a link failure and has switched traffic to a backup path, the network controller confirms that the failure persists through a routing wait window mechanism. It then starts the routing re-optimization system to calculate the globally optimal new primary path and distributes the new primary path to the network device. After receiving the new primary path, the network device smoothly switches traffic from the temporarily used backup path to the new primary path for forwarding.

[0056] The network fault handling method provided in this invention provides instantaneous service protection by quickly switching the traffic affected by the fault from the primary path to the backup path when a network link fault is detected. This avoids traffic interruption caused by the fault and significantly improves network reliability and service continuity. Subsequently, the method receives a new primary path issued by the network controller and smoothly switches the traffic from the backup path to the new primary path for forwarding. This ensures the temporary forwarding needs of services during the fault period and obtains a better forwarding path through routing re-optimization after the fault is confirmed. This achieves a seamless connection from temporary protection to optimized forwarding, thereby improving the overall utilization efficiency of network resources and the practical application effect of routing re-optimization while ensuring the quality of service.

[0057] Based on any of the above embodiments, the step of switching the traffic affected by the network link failure from the primary path to the backup path for forwarding when a network link failure is detected includes: When a network link failure is detected by the seamless bidirectional forwarding detection mechanism, the local routing protocol is triggered to recalculate the converged route and determine the backup path based on the converged route. Traffic affected by the fault will be switched from the primary path to the backup path for forwarding.

[0058] It should be noted that Seamless Bidirectional Forwarding Detection (SBFD) is a fast protection mechanism that can perform traffic switching operations when a link failure is detected. Specifically, when an SBFD session detects a link failure, it immediately triggers a local routing protocol (such as OSPF, IS-IS, or BGP) to recalculate routes. Based on the re-converged routing information, it determines an alternative path to the destination address and switches the traffic affected by the failure from the original primary path to this alternative path for forwarding.

[0059] The network fault handling method provided in this invention monitors network link faults through a seamless bidirectional forwarding detection mechanism. When a fault occurs, the network device locally triggers the routing protocol to recalculate the converged route, determines the backup path based on the converged route, and switches the traffic affected by the fault from the primary path to the backup path for forwarding. This achieves millisecond-level rapid fault recovery, effectively ensuring service continuity and network reliability. Simultaneously, this process is entirely executed locally by the network device, without intervention from the controller's routing system. This avoids the processing pressure on the controller caused by a large amount of information being reported instantly during a fault, providing a stable network environment for the controller to make fault merging and intelligent re-optimization decisions within the routing waiting window. This achieves coordinated local rapid protection and global path optimization, significantly improving the overall network fault handling efficiency and resource utilization.

[0060] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6 As shown, the electronic device may include a processor 610, a communications interface 620, a memory 630, and a communication bus 640, wherein the processor 610, communications interface 620, and memory 630 communicate with each other via the communication bus 640. The processor 610 can call logical instructions in the memory 630 to execute a network fault handling method. This method includes: in response to a detected network link fault, acquiring initial fault information and starting a delay timer to enter a routing waiting window; within the routing waiting window, if duplicate fault information for the same link is received, merging the duplicate fault information into the initial fault information; when the routing waiting window ends, determining whether the network link fault corresponding to the initial fault information has been recovered; if the network link fault has not been recovered, starting a routing re-optimization system to calculate a new primary path and distributing the new primary path to network devices, so that the network devices switch traffic to the new primary path for forwarding.

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

[0062] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the network fault handling method provided by the above methods. The method includes: in response to a detected network link fault, acquiring initial fault information and starting a delay timer to enter a routing waiting window; within the routing waiting window, if duplicate fault information for the same link is received, merging the duplicate fault information into the initial fault information; when the routing waiting window ends, determining whether the network link fault corresponding to the initial fault information has been recovered; if the network link fault has not been recovered, starting a routing re-optimization system to calculate a new primary path and distributing the new primary path to network devices so that the network devices switch traffic to the new primary path for forwarding.

[0063] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the network fault handling method provided by the above methods. The method includes: in response to a detected network link fault, acquiring initial fault information and starting a delay timer to enter a routing waiting window; within the routing waiting window, if duplicate fault information for the same link is received, merging the duplicate fault information into the initial fault information; when the routing waiting window ends, determining whether the network link fault corresponding to the initial fault information has been recovered; if the network link fault has not been recovered, starting a routing re-optimization system to calculate a new primary path and distributing the new primary path to network devices so that the network devices switch traffic to the new primary path for forwarding.

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

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

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

Claims

1. A network fault handling method, characterized in that, Applied to network controllers, including: In response to a detected network link failure, the system acquires initial failure information and starts a delay timer to enter the routing waiting window. If repeated fault information for the same link is received within the routing waiting window, the repeated fault information is merged into the first fault information. When the routing waiting window ends, it is determined whether the network link fault corresponding to the initial fault information has been recovered; If the network link failure is not recovered, the routing re-optimization system is activated to calculate a new primary path and distribute the new primary path to the network devices so that the network devices can switch traffic to the new primary path for forwarding.

2. The network fault handling method according to claim 1, characterized in that, The network controller and the network device are configured with BGP-LS neighbors; wherein, prior to responding to a detected network link failure, the method further includes: Receive real-time network topology information reported by the network device using the BGP-LS protocol, wherein the real-time network topology information includes device connection status, load status, and traffic statistics; Based on the real-time network topology information, the network link status is continuously monitored, wherein the network link status includes the status of monitoring devices, link status, and routing prefix information.

3. The network fault handling method according to claim 1, characterized in that, If, within the path calculation waiting window, repeated fault information for the same link is received, the repeated fault information is merged into the initial fault information, including: Within the routing waiting window, multiple fault messages reported by the network device are received; Extract the link identifiers of the multiple fault information; If the link identifier in the fault information is the same as the link identifier in the initial fault information, then the fault information is determined to be a duplicate fault information, and the duplicate fault information is merged into the initial fault information.

4. The network fault handling method according to claim 1, characterized in that, The startup of the routing re-optimization system to calculate the new primary path includes: Start the routing re-optimization system; The path re-optimization system obtains the link information and delay constraints corresponding to the initial fault information. The routing re-optimization system calculates a new primary path based on the link information and the delay constraints.

5. A network fault handling method, characterized in that, Applied to network devices, including: The system receives a new primary path issued by the network controller and switches traffic to the new primary path for forwarding. The new primary path is calculated and issued by the routing reoptimization system after the network controller starts a delay timer to enter a routing waiting window after obtaining the first fault information. Within the routing waiting window, the received repeated fault information is merged into the first fault information. If it is determined that the network link fault has not been recovered when the routing waiting window ends, the new primary path is calculated and issued by the routing reoptimization system.

6. The network fault handling method according to claim 5, characterized in that, The process of receiving the new primary path issued by the network controller and switching traffic to the new primary path for forwarding includes: When a network link failure is detected, the traffic affected by the failure will be switched from the primary path to the backup path for forwarding. The system receives a new primary path from the network controller and switches the traffic from the backup path to the new primary path for forwarding.

7. The network fault handling method according to claim 6, characterized in that, When a network link failure is detected, the process of switching the traffic affected by the failure from the primary path to the backup path for forwarding includes: When a network link failure is detected by the seamless bidirectional forwarding detection mechanism, the local routing protocol is triggered to recalculate the converged route and determine the backup path based on the converged route. Traffic affected by the fault will be switched from the primary path to the backup path for forwarding.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the network fault handling method as described in any one of claims 1 to 7.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the network fault handling method as described in 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 the processor, it implements the network fault handling method as described in any one of claims 1 to 7.

Images