Network Fault Notification Methods, Devices, Network Equipment, and Readable Storage Media

Abstract

This invention relates to the field of communication technology, providing a network fault notification method, apparatus, network device, and readable storage medium. Applied to a network device, the network device is directly connected to at least one directly connected network device. The network device is configured with link types for the direct links between itself and each directly connected network device. The link types include uplink links and downlink links. The method includes: acquiring a fault notification message; determining forwarding links from all directly connected links, the forwarding links including at most one uplink link; and sending a fault notification message through each of the forwarding links. This invention enables rapid detection of link faults.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically, to a network fault notification method, apparatus, network device, and readable storage medium. Background Technology

[0002] With the rapid development of AI (Artificial Intelligence) technology, intelligent computing center networks have gradually become a research hotspot in the industry. AI training, due to its characteristics of distributed computing, long-cycle operation, and real-time response, is extremely sensitive to network failures. Since intelligent computing networks typically use a large number of fragile components such as optical modules, network failures are inevitable during AI training. Currently, the industry is paying great attention to improving the fault convergence speed in intelligent computing center networks and reducing the impact of network failures on AI training tasks.

[0003] Traditional fault recovery primarily relies on the control plane of network devices. When a network device detects a link or node failure, it sends protocol messages to its neighbors via routing protocols (BGP (Border Gateway Protocol) / OSPF (Open Shortest Path First) / ISIS (Intermediate System to Intermediate System)) to notify them of route cancellation. Service recovery only occurs after neighboring devices receive the protocol messages and update their local routing table entries. In typical scenarios, convergence time is on the order of seconds, resulting in excessively long packet loss periods.

[0004] To address the issue of slow routing protocol convergence leading to prolonged packet loss, the industry has begun proposing fault recovery technologies based on the forwarding plane. The main idea is to combine fault notification with remote fault handover. Regarding fault notification, one existing solution is to use network-wide flooding for fault notification. Its disadvantages are: fault notification message forwarding loops, numerous duplicate notifications, low efficiency, and waste of network bandwidth. Summary of the Invention

[0005] The purpose of this invention is to provide a network fault notification method, apparatus, network device, and readable storage medium, which enables network devices affected by faults to quickly detect faults without changing the hardware.

[0006] The embodiments of the present invention can be implemented as follows:

[0007] In a first aspect, the present invention provides a network fault notification method applied to a network device, wherein the network device is directly connected to at least one directly connected network device, and the network device is configured with a link type for the direct link between itself and each of the directly connected network devices, wherein the link type includes an uplink link and a downlink link, and the method includes:

[0008] Obtain fault notification messages;

[0009] Determine a forwarding link from all the directly connected links, the forwarding link including at most one uplink link;

[0010] The fault notification message is sent through each link in the forwarding link.

[0011] In an optional implementation, the step of determining the forwarding link from all the directly connected links includes:

[0012] If there is at least one downstream link among all the directly connected links, then each of the downstream links will be used as one of the forwarding links;

[0013] If at least one of the directly connected links exists, the forwarding link is determined based on the fault notification message.

[0014] In an optional implementation, the step of determining the forwarding link based on the fault notification message includes:

[0015] If the fault notification message is generated by the network device when it detects a fault in the link with any of the directly connected network devices, or if the fault notification message is received by the network device through at least one of the downlink links, then one uplink link is determined from the at least one uplink link as one of the forwarding links.

[0016] In an optional implementation, the step of obtaining the fault notification message includes:

[0017] When a traffic packet is received, the next-hop link for forwarding the traffic packet is determined, and the status of the next-hop link is obtained. If the status of the next-hop link is a fault state, an announcement message is generated, and the preset fields in the announcement message are set to preset values, and a link identifier representing the faulty link is added to the announcement message to obtain the fault announcement message.

[0018] In an optional implementation, the step of obtaining the fault notification message includes:

[0019] When a link failure is detected between the device and any of the directly connected network devices, a notification message is generated. The preset fields in the generated notification message are set to preset values, and a link identifier representing the faulty link is added to the notification message to obtain the fault notification message.

[0020] In an optional implementation, the step of generating an announcement message when a link failure is detected with any of the directly connected network devices includes:

[0021] For any of the directly connected network devices, if the optical module status of the directly connected network device is detected to be abnormal, or the device port status of the directly connected network device is detected to be disconnected, or the bidirectional forwarding detection (BFD) session between the directly connected network device and the directly connected network device is disconnected, then it is determined that the link between the network device and the directly connected network device has failed.

[0022] In an optional implementation, the step of obtaining the fault notification message includes:

[0023] Receive notification messages sent by other network devices;

[0024] If the notification message contains a preset field and the preset field has a preset value, then the notification message will be used as the fault notification message.

[0025] Secondly, the present invention provides a network fault notification device applied to a network device, wherein the network device is directly connected to at least one directly connected network device, and the network device is configured with a link type for the direct link between itself and each of the directly connected network devices, the link type including an uplink link and a downlink link, and the device includes:

[0026] The acquisition module is used to acquire fault notification messages;

[0027] A determining module is configured to determine a forwarding link from all the directly connected links, the forwarding link including at most one uplink link;

[0028] The sending module is used to send the fault notification message through each link in the forwarding link.

[0029] Thirdly, the present invention provides a network device including a processor and a memory, the memory being used to store a program, and the processor being used to implement the network fault notification method described in any of the foregoing embodiments when executing the program.

[0030] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the network fault notification method described in any of the foregoing embodiments.

[0031] Compared with the prior art, the present invention has the following advantages: when forwarding fault notification messages, the fault notification messages are forwarded on the forwarding plane through at most one uplink link, avoiding the use of protocol notification route update on the control plane for fault notification, thus improving the efficiency of fault notification. This allows all affected devices to quickly detect the fault, and effectively avoids the waste of network bandwidth caused by fault notification messages being forwarded in loops or repeatedly in the network. At the same time, it does not involve hardware improvements, reducing the difficulty of implementation. Attached Figure Description

[0032] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0033] Figure 1 This is an example diagram of the Fat-Tree network provided in this embodiment.

[0034] Figure 2 Provided for this embodiment Figure 1 An example diagram of traffic forwarding paths affected by link failures in existing technologies.

[0035] Figure 3 This is a block diagram of a network device provided in this embodiment.

[0036] Figure 4 This is a flowchart illustrating the network fault notification method provided in this embodiment.

[0037] Figure 5 Provided for this embodiment Figure 1 An example diagram illustrating the network fault notification method used in this embodiment.

[0038] Figure 6 This is a block diagram of the network fault notification device provided in this embodiment.

[0039] Icons: 10-Network device; 11-Processor; 12-Memory; 13-Bus; 100-Network fault notification device; 110-Acquisition module; 120-Determination module; 130-Transmission module. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0041] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0042] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings.

[0043] In the description of this invention, it should be noted that if terms such as "upper," "lower," "inner," or "outer" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship in which the product of this invention is usually placed, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0044] Furthermore, the terms "first" and "second" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0045] It should be noted that, where there is no conflict, the features in the embodiments of the present invention can be combined with each other.

[0046] For ease of explanation, this embodiment uses network devices in a Fat-Tree network as an example. Please refer to... Figure 1 , Figure 1 This is an example diagram of the Fat-Tree network provided in this embodiment. The Fat-Tree network can be a two-level Fat-Tree network or a three-level Fat-Tree network. Figure 1 This is an example diagram of a three-level Fat-Tree network. Figure 1The network devices in the Fat-Tree include the Spine devices at the top, the Leaf devices in the middle, and the Tor (Top of Rack) devices at the bottom. The Tor devices communicate directly with the computing nodes responsible for intelligent computing. Since the main component responsible for intelligent computing on each node is the GPU (Graphics Processing Unit), therefore... Figure 1 In Chinese, it is simplified to a GPU representation. Figure 1 In this system, there is at least one direct link between each layer of devices and the devices in other layers. Two devices connected by a direct link are called directly connected devices. Directly connected devices learn routing table entries through BGP / OSPF / ISIS routing protocols.

[0047] Spine devices connect to Leaf devices, and Spine devices can also interconnect to form a flat network structure. As a result, any two Leaf devices can achieve fast data exchange through a Spine switch.

[0048] Leaf devices connect directly to Tor devices in the third-level Fat-Tree network and directly to compute nodes, including GPUs, in the second-level Fat-Tree network. They are the edge or access layer of the network, responsible for receiving data and forwarding it to Spine devices.

[0049] Tor devices are an important component in the network architecture of intelligent computing centers. The main function of Tor devices is to provide network access points for computing centers, allowing them to connect directly to Tor devices via short patch cables.

[0050] It should be noted that, Figure 1 This is just an example of a three-level Fat-Tree network. In real-world applications, a three-level Fat-Tree network can include more Tor devices, more Leaf devices, more Spine devices, and more compute nodes including GPUs, with each device having a greater number of direct links.

[0051] It should also be noted that the secondary Fat-Tree network is similar, except that it includes Spine devices and Leaf devices. The Leaf devices communicate directly with the nodes responsible for intelligent computing. The network fault notification method provided in this embodiment is applicable to both secondary and tertiary Fat-Tree networks.

[0052] based on Figure 1 To more vividly illustrate the impact of link failures on traffic forwarding using routing protocols in the control plane of existing technologies, please refer to the three-level Fat-Tree network. Figure 2 , Figure 2 Provided for this embodiment Figure 1 Example diagram of traffic forwarding paths affected by link failure in existing technologies. Figure 2 Taking a link failure between Leaf1 and Tor1 as an example, for traffic from Tor5 to Tor1, both paths through Leaf5 will pass through the failed link. Therefore, Tor5 needs to respond to the link failure and switch traffic to other Leaf paths. The traditional fault convergence method based on routing protocols works as follows: After Leaf1 detects a link failure connecting to Tor1, it sends protocol messages to Spine1 and Spine2 via routing protocols (BGP / OSPF / ISIS) to notify of route cancellation. Spine1 and Spine2 then notify their directly connected Leaf3 and Leaf5 protocols. Leaf5's routing protocol notifies Tor. Service can only resume after Tor5 receives the protocol messages and updates its local routing table. This entire process requires the control planes of multiple devices, resulting in a long convergence time.

[0053] In view of this, this embodiment provides a network fault notification method, apparatus, network device, and readable storage medium. It forwards fault notification messages at the forwarding plane, avoiding the use of protocol notification route updates at the control plane, thus improving the efficiency of fault notification. At the same time, it forwards fault notification messages through at most one uplink link, effectively avoiding the waste of network bandwidth caused by fault notification messages being forwarded in loops or repeatedly forwarded in the network. Furthermore, it does not involve hardware improvements, reducing the difficulty of implementation. It will be described in detail below.

[0054] Please refer to Figure 3 , Figure 3 This is a block diagram illustrating a network device provided in this embodiment. Network device 10 implements the network fault notification method of this embodiment. For a three-level Fat-Tree network, network device 10 can be... Figure 1 The Spine device in the middle can also be Figure 1 The Leaf device in the text can also be Figure 1 In a secondary Fat-Tree network, network device 10 can be either a Spine device or a Leaf device. Network device 10 includes a processor 11, a memory 12, and a bus 13, with the processor 11 and memory 12 connected via the bus 13.

[0055] The processor 11 can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the network fault notification method in the above embodiments can be completed by the integrated logic circuitry in the hardware of the processor 11 or by software instructions. The processor 11 can be a general-purpose processor, including a CPU (Central Processing Unit), an NP (Network Processor), etc.; it can also be a DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Logic Gate Array), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0056] The memory 12 is used to store a program that implements the network fault notification method. The program may be a software function module stored in the memory 12 in the form of software or firmware or embedded in the OS (Operating System) of the network device 10.

[0057] After receiving the execution instruction, the processor 11 executes the program to implement the network fault notification method of the aforementioned embodiment.

[0058] Based on the above Figure 1 and Figure 2 This embodiment provides a method that can be applied to Figure 1 Spine devices, or Leaf devices, or Tor devices, or Figure 2 This embodiment describes a network fault notification method for network devices in a Fat-Tree network. For ease of description, this embodiment uses any network device in the Fat-Tree network as the execution subject (referred to as "this network device" in this embodiment; other network devices in the Fat-Tree network are referred to as "other network devices"). Please refer to... Figure 4 , Figure 4 This is a flowchart illustrating the network fault notification method provided in this embodiment. The method includes the following steps:

[0059] Step S101: Obtain the fault notification message.

[0060] In this embodiment, the fault notification message is generated by the network device that detects the link fault and sent to other network devices. Therefore, for this network device, the fault notification message obtained can be generated by this network device or generated by other network devices and then forwarded to this network device.

[0061] In this embodiment, fault notification messages typically use a specific identifier to distinguish them from other messages. When any network device receives a message carrying this specific identifier, it can determine that the message is a fault notification message. In addition, fault notification messages can also carry the link identifier of the faulty link, so that the network device receiving the fault notification message can perform fault handling based on the link identifier.

[0062] Step S102: Determine the forwarding link from all directly connected links. The forwarding link includes at most one uplink link.

[0063] In this embodiment, the network device is directly connected to at least one directly connected network device. The network device is configured with a link type for the direct link between itself and each directly connected network device. The link types include uplink links and downlink links. One way to determine the link type is to pre-set a level for each network device in the Fat-Tree network. The level of the network device is set according to its hierarchy within the Fat-Tree network. For example, in... Figure 1 In this context, if all Spine devices are at the same level, then all Spine devices have the same priority; similarly, if all Leaf devices are at the same level, then all Leaf devices have the same priority; and if all Tor devices are at the same level, then all Tor devices have the same priority. Spine devices have a higher priority than Leaf devices, and Leaf devices have a higher priority than Tor devices. An uplink is a direct link between a network device and a directly connected network device with a higher priority; a downlink is a direct link between a network device and a directly connected network device with a lower priority. For example, this network device is... Figure 1 Taking the Leaf1 device as an example, its directly connected network devices include Spine1, Spine2, Tor1, Tor2, Tor3, and Tor4. The direct links between Leaf1 and Spine1, and between Leaf1 and Spine2, are uplink links, while the direct links between Leaf1 and Tor1, Tor2, Tor3, and Tor4 are downlink links.

[0064] In this embodiment, the forwarding link may include at most one uplink link, that is, the forwarding link may include one uplink link and not include a downlink link, or it may include one uplink link and at least one downlink link, or it may include multiple downlink links and not include an uplink link.

[0065] Step S103: Send a fault notification message through each link in the forwarding link.

[0066] In this embodiment, the sending of fault notification messages is performed in the forwarding plane rather than the control plane. When the fault notification message is generated by this network device, this network device sends it to the corresponding directly connected network device through each link in the forwarding link. When the fault notification message is received by this network device from other directly connected network devices, this network device forwards the received fault notification message to the corresponding directly connected network device through each link in the forwarding link.

[0067] The method provided in this embodiment avoids the use of protocol announcement route updates for fault notification on the control plane, thus improving the efficiency of fault notification. It enables all affected devices to quickly detect the fault and effectively avoids the waste of network bandwidth caused by fault notification messages being looped or repeatedly forwarded in the network. At the same time, it does not involve hardware improvements, reducing the difficulty of implementation.

[0068] It should be noted that for application scenarios with high requirements for the delay of the fault notification process, the sending and forwarding of fault notification messages can also be implemented in hardware through the switching chip.

[0069] In this embodiment, the fault notification message may be sent via the uplink link or via the downlink link. This embodiment provides a method for determining the forwarding link:

[0070] If there is at least one downstream link among all direct links, then each downstream link will be treated as one of the forwarding links;

[0071] In this embodiment, when there is a downstream link in the direct link, the faulty link message needs to be sent to each downstream link. This embodiment refers to the principle of "downward flooding".

[0072] In this embodiment, when the fault notification message is forwarded by a directly connected network device, there are two situations: (1) the fault notification message is forwarded through the uplink; (2) the fault notification message is forwarded through the downlink. For (2), the fault notification message can be sent through all downlinks because the downlink that forwards the fault notification message will not resend it even if it receives the forwarded fault notification message again. Alternatively, the fault notification message can be sent through the downlinks other than the downlink that sent the fault notification message.

[0073] If there is at least one uplink among all directly connected links, the forwarding link is determined based on the fault notification message.

[0074] In this embodiment, to minimize the repeated transmission of fault notification messages and avoid fault notification message forwarding loops, when there is at least one uplink among all directly connected links, whether to forward fault notification messages through the uplink depends on the specific circumstances. This embodiment provides a method for determining the forwarding link based on the fault notification message:

[0075] If the fault notification message is generated by the network device when it detects a fault in the link with any directly connected network device, or if the fault notification message is received by the network device through at least one downlink, then one uplink is determined from the at least one uplink as one of the forwarding links.

[0076] In this embodiment, fault notification messages generated by the network device or originating from downstream links must be sent via upstream links. However, they do not need to be sent through every single upstream link; only one upstream link needs to be selected for transmission. The selection method can be random, choosing the most stable link from all upstream links, or selecting the link with the lowest network bandwidth load. This is referred to as the "single-upward transmission" principle in this embodiment. For fault notification messages originating from upstream links, they do not need to be sent via upstream links again; they only need to be sent through each downstream link. This is the "single-upward transmission, flooding downstream" principle proposed in this embodiment.

[0077] In this embodiment, the fault notification message can be generated by this network device or sent to this network device by other network devices. When it is generated by this network device, there are two generation methods depending on when the fault notification message is generated:

[0078] Method 1: Generate a fault notification message upon receiving a traffic packet.

[0079] When a traffic packet is received, the next-hop link for forwarding the traffic packet is determined, and the status of the next-hop link is obtained. If the status of the next-hop link is a fault state, an announcement message is generated, and the preset fields in the announcement message are set to preset values, and the link identifier representing the faulty link is added to the announcement message to obtain a fault announcement message.

[0080] In this embodiment, the above-described method of obtaining notification messages can minimize the unnecessary impact of fault notification messages on network bandwidth.

[0081] Method 2: Generate when a link failure is detected

[0082] When a link failure is detected between the device and any directly connected network device, a notification message is generated. The preset fields in the generated notification message are set to preset values, and a link identifier representing the faulty link is added to the notification message to obtain a fault notification message.

[0083] In this embodiment, a link failure will generate a corresponding event in the network device, which will trigger the generation of a fault notification message.

[0084] In this embodiment, a link failure between the network device and a directly connected network device can be caused by a failure in the directly connected network device or by a session anomaly between the network device and the directly connected network device. This embodiment provides a method for determining link failures:

[0085] For any directly connected network device, if the optical module status of the directly connected network device is detected to be abnormal, or the device port status of the directly connected network device is detected to be disconnected, or the bidirectional forwarding detection (BFD) session between the directly connected network device and the directly connected network device is disconnected, it is determined that the link between the network device and the directly connected network device has failed.

[0086] In this embodiment, the device port status includes two states: UP (connected) and DOWN (disconnected). When the device port status is DOWN, it can be determined that the device port status is disconnected.

[0087] BFD sessions are used to quickly detect network connectivity failures. A BFD session is a BFD connection established between two network devices. Through this connection, the network devices can quickly determine whether the other device is reachable and whether the network path is normal. A BFD session has two states: UP and DOWN. When the BFD session is in the DOWN state, it can be determined that the BFD session is disconnected.

[0088] In this embodiment, to distinguish fault notification messages from other messages, a specific identifier is typically used. This identifier can be a preset field such as a special source MAC address or destination MAC address, a special source IP address or destination IP address, or a special Ethernet header protocol type. One specific method is to assign specific values ​​to these fields. Besides using preset fields to represent fault notification messages, to achieve faster fault convergence, information about the faulty link can also be carried in the fault notification message. For example, a link identifier representing the faulty link can be added to the fault notification message so that the network device receiving the fault notification message can promptly learn about the faulty link and take timely action to avoid it. In this embodiment, when the fault notification message is received from another network device, the method for obtaining the fault notification message is as follows:

[0089] Receive notification messages sent by other network devices;

[0090] If a notification message contains a preset field and the preset field has a preset value, then the notification message will be treated as a fault notification message.

[0091] To more vividly illustrate the fault notification process of the network notification method provided in this embodiment, please refer to... Figure 5 , Figure 5 Provided for this embodiment Figure 1 An example diagram illustrating the network fault notification method used in this embodiment is shown. Figure 5 In the process, when Leaf1 detects a link failure with Tor1, it generates a fault notification message, sets the Ethernet type of the fault notification message to 0x88FF to identify the message as a fault notification message, and sets the source MAC address of the fault notification message to the link identifier link_leaf1_tor1 so that the fault notification message carries the link identifier of the faulty link. Leaf1, following the principle of "single transmission uplink, flooding downlink," selects the uplink link between Leaf1 and Spine1 to send the generated fault notification message. Simultaneously, it sends this fault notification message to Tor2, Tor3, and Tor4 via the downlink link. When Spine1 receives the fault notification message, it follows the principle of "single transmission uplink, flooding downlink." Since Spine1 lacks an uplink link, it forwards the fault notification message to Leaf3, Leaf5, and Leaf7 via the downlink link. Leaf3, Leaf5, and Leaf7 then send the fault notification message to Tor1 through Tor8 via their respective downlink links, following the same principle. It can be seen that the network fault notification method in this embodiment reduces the number of fault messages sent while still ensuring that the fault notification message is sent to all network devices affected by the faulty link, without affecting the fault convergence effect.

[0092] To perform the corresponding steps in the above embodiments and various possible implementations, an implementation method of the network fault notification device 100 is given below. Please refer to... Figure 6 , Figure 6 This is a block diagram of the network fault notification device provided in this embodiment. It should be noted that the basic principle and technical effects of the network fault notification device 100 provided by the present invention are the same as those of the corresponding embodiments described above. For the sake of brevity, some parts of this embodiment are not mentioned.

[0093] The network fault notification device 100 includes an acquisition module 110, a determination module 120, and a sending module 130.

[0094] Module 110 is used to acquire fault notification messages;

[0095] The determination module 120 is used to determine the forwarding link from all directly connected links, the forwarding link including at most one uplink link;

[0096] The sending module 130 is used to send fault notification messages through each link in the forwarding link.

[0097] In an optional implementation, the determining module 120 is specifically used for:

[0098] If there is at least one downstream link among all direct links, then each downstream link will be treated as one of the forwarding links;

[0099] If there is at least one uplink among all directly connected links, the forwarding link is determined based on the fault notification message.

[0100] In an optional implementation, the determining module 120 is specifically used to: determine the forwarding link based on the fault notification message.

[0101] If the fault notification message is generated by the network device when it detects a fault in the link with any directly connected network device, or if the fault notification message is received by the network device through at least one downlink, then one uplink is determined from the at least one uplink as one of the forwarding links.

[0102] In an optional implementation, the acquisition module 110 is specifically used for:

[0103] When a traffic packet is received, the next-hop link for forwarding the traffic packet is determined, and the status of the next-hop link is obtained. If the status of the next-hop link is a fault state, an announcement message is generated, and the preset fields in the announcement message are set to preset values, and the link identifier representing the faulty link is added to the announcement message to obtain a fault announcement message.

[0104] In an optional implementation, the acquisition module 110 is further configured to:

[0105] When a link failure is detected between the device and any directly connected network device, a notification message is generated. The preset fields in the generated notification message are set to preset values, and a link identifier representing the faulty link is added to the notification message to obtain a fault notification message.

[0106] In an optional implementation, the acquisition module 110 is further configured to: generate an announcement message before generating the announcement message when a link failure is detected with any of the directly connected network devices.

[0107] For any directly connected network device, if the optical module status of the directly connected network device is detected to be abnormal, or the device port status of the directly connected network device is detected to be disconnected, or the bidirectional forwarding detection (BFD) session between the directly connected network device and the directly connected network device is disconnected, it is determined that the link between the network device and the directly connected network device has failed.

[0108] In an optional implementation, the acquisition module 110 is further configured to:

[0109] Receive notification messages sent by other network devices;

[0110] If a notification message contains a preset field and the preset field has a preset value, then the notification message will be treated as a fault notification message.

[0111] This invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the network fault notification method described in any of the foregoing embodiments.

[0112] In summary, this embodiment of the invention provides a network fault notification method, apparatus, network device, and readable storage medium. The method includes: applying to a network device, the network device being directly connected to at least one directly connected network device, the network device having a link type for the direct link between itself and each directly connected network device, the method including: acquiring a fault notification message; determining a forwarding link from all directly connected links, the forwarding link including at most one uplink link; and sending a fault notification message through each link in the forwarding link. Compared with the prior art, this embodiment has at least the following advantages: (1) Fault notification is performed according to the rule of "single transmission to the uplink and flooding to the downlink", so that all devices affected by the fault can quickly perceive the fault, and the network bandwidth waste caused by the fault notification message being looped or repeatedly forwarded in the network can be effectively avoided; (2) Fault notification is based on the device forwarding plane, without the need for control plane participation, and the fault notification speed is fast; (3) Fault notification is independent of the number of service flows, and has good scalability.

[0113] The above descriptions are merely various embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for notifying network faults, characterized in that, Applied to network devices, wherein the network devices are directly connected to at least one directly connected network device, and the network devices are configured with link types for the direct links between themselves and each of the directly connected network devices, wherein the link types include uplink links and downlink links, and the method includes: Obtain fault notification messages; Determine forwarding links from all directly connected links, wherein the forwarding links include at most one uplink link; The fault notification message is sent through each link in the forwarding link.

2. The network fault notification method according to claim 1, characterized in that, The step of determining the forwarding link from all directly connected links includes: If there is at least one downstream link among all the directly connected links, then each of the downstream links will be used as one of the forwarding links; If at least one of the directly connected links exists, the forwarding link is determined based on the fault notification message.

3. The network fault notification method according to claim 2, characterized in that, The step of determining the forwarding link based on the fault notification message includes: If the fault notification message is generated by the network device when it detects a fault in the link with any of the directly connected network devices, or if the fault notification message is received by the network device through at least one of the downlink links, then one uplink link is determined from the at least one uplink link as one of the forwarding links.

4. The network fault notification method according to claim 1, characterized in that, The steps for obtaining the fault notification message include: When a traffic packet is received, the next-hop link for forwarding the traffic packet is determined, and the status of the next-hop link is obtained. If the status of the next-hop link is a fault state, an announcement message is generated, and the preset fields in the announcement message are set to preset values, and a link identifier representing the faulty link is added to the announcement message to obtain the fault announcement message.

5. The network fault notification method according to claim 1, characterized in that, The steps for obtaining the fault notification message include: When a link failure is detected between the device and any of the directly connected network devices, a notification message is generated, and preset fields in the notification message are set to preset values, and a link identifier representing the faulty link is added to the notification message to obtain the fault notification message.

6. The network fault notification method according to claim 5, characterized in that, Before the step of generating an announcement message when a link failure is detected with any of the directly connected network devices, the following steps are included: For any of the directly connected network devices, if the optical module status of the directly connected network device is detected to be abnormal, or the device port status of the directly connected network device is detected to be disconnected, or the bidirectional forwarding detection (BFD) session between the directly connected network device and the directly connected network device is disconnected, then it is determined that the link between the network device and the directly connected network device has failed.

7. The network fault notification method according to claim 1, characterized in that, The steps for obtaining the fault notification message include: Receive notification messages sent by other network devices; If the notification message contains a preset field and the preset field has a preset value, then the notification message will be used as the fault notification message.

8. A network fault notification device, characterized in that, An apparatus applied to network devices, wherein the network devices are directly connected to at least one directly connected network device, and the network devices are configured with link types for direct links between themselves and each of the directly connected network devices, the link types including uplink links and downlink links, the apparatus comprising: The acquisition module is used to acquire fault notification messages; A determining module is configured to determine a forwarding link from all the directly connected links, the forwarding link including at most one uplink link; The sending module is used to send the fault notification message through each link in the forwarding link.

9. A network device, characterized in that, It includes a processor and a memory, the memory being used to store a program, and the processor being used to implement the network fault notification method according to any one of claims 1-7 when executing the program.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the network fault notification method according to any one of claims 1-7.

Images