Troubleshooting methods and related devices

Abstract

This application proposes a fault handling method and related apparatus, relating to the field of communication technology. The method involves acquiring a peer-to-peer link fault event sent by any member device; wherein the peer-to-peer link fault event is generated and sent by the member device when a peer-to-peer link fault is determined based on the link status of the peer-to-peer link, and the peer-to-peer link fault event includes the slave device identifier of the slave member device in the MLAG system; retrieving the next-hop information to be processed from the locally stored ECMP configuration group based on the slave device identifier; and updating the ECMP table based on the next-hop information to update the forwarding link between the network-side device and the MLAG system. This method can improve the fault detection speed and fault reporting speed, thereby improving the timeliness of fault handling, and can also improve processing efficiency and link switching convergence speed.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a fault handling method and related apparatus. Background Technology

[0002] MLAG (Multi-Chassis Link Aggregation Group) is a mechanism that enables cross-device link aggregation, allowing links between multiple devices to be aggregated. This improves link reliability from the single-board level to the device level, forming a dual-active or multi-active system. In an MLAG system, two member devices can be connected through a peer-to-peer link, making them logically a single device.

[0003] Currently, communication between network-side devices and user-side devices can be achieved through the MLAG system. However, if the peer-to-peer link between two member devices in the MLAG system fails, it will cause abnormal traffic forwarding on the network-side devices.

[0004] The following methods can be used in existing technologies to solve this problem of abnormal traffic forwarding.

[0005] Specifically, Figure 1 For a communication example diagram of an MLAG system, please refer to [link / reference]. Figure 1 The MLAG system includes two member devices, DUT1 and DUT2. DUT1 acts as the master device in the MLAG system, and DUT2 acts as the slave device. DUT1 and DUT2 are connected via a peer-link. DUT3 is the network-side device connected to the MLAG system. DUT3, DUT1, and DUT2 can establish neighbor relationships according to routing protocols, such as OSPF (Open Shortest Path First) neighbors. Furthermore, DUT1 and DUT2 can also communicate with server A on the access user side. The interface routes or host routes corresponding to server A can be advertised to DUT3 via OSPF on DUT1 and DUT2.

[0006] In this scenario, network-side device DUT3 can forward traffic from user-side device server A. When the peer-link between DUT1 and DUT2 is functioning correctly, this traffic can proceed according to... Figure 1As shown by arrow 1, traffic is forwarded to server A via DUT1 and DUT2 respectively. When the peer-link between DUT1 and DUT2 fails, DUT2 actively disconnects the downlink interface used for communication with the server. The OSPF routing protocol on DUT2, upon detecting a Layer 3 link failure corresponding to this downlink interface, invalidates the Layer 3 routes associated with that downlink interface. Simultaneously, the routing protocol sends a route cancellation message to DUT3 for the downlink interface. Upon receiving the route cancellation message, DUT3 can delete the corresponding routes layer by layer from the routing protocol layer down to the forwarding layer. Therefore, when DUT3 forwards traffic to server A afterward, it will only follow the path indicated by the route cancellation message. Figure 1 The direction of arrow 2 shown in the diagram indicates that the traffic is forwarded to server A via DUT1.

[0007] However, this solution also has some problems. First, the routing protocol can only determine the Layer 3 link failure corresponding to the downlink interface after the DUT2 actively disconnects from the server, thus requiring it to take appropriate action. In other words, the DUT2 needs to perform some operations after the peer-link failure before the routing protocol can detect the fault. This results in slow fault detection, leading to slow fault reporting and untimely fault handling. Second, this method switches traffic forwarding links by canceling routes through the routing protocol. However, for the DUT2, the number of corresponding routes may be large, for example... Figure 1 As shown, DUT2 can connect to other servers besides server A, such as server B. However, the processing efficiency of the route-based approach is strongly correlated with the number of routes; that is, if the number of devices connected to DUT2 is large, the processing efficiency will be low. Furthermore, the route-based approach requires processing layer by layer from the routing protocol layer to the forwarding layer, which also leads to low processing efficiency and slow link switching convergence.

[0008] In addition, existing technologies can also solve this traffic forwarding anomaly problem by using an external server. Specifically, Figure 2 For another communication example diagram of the MLAG system, please refer to [link / reference]. Figure 2 The MLAG system comprises two member devices: an MLAG master device and an MLAG slave device, and is connected to a controller for communication. Both the MLAG master and slave devices are configured with monitoring event identifiers. The controller maintains the association between these monitoring event identifiers and MLAG events. The monitoring events include information about the MLAG system, the core devices communicating with the MLAG system, the access devices of the MLAG system, the slave devices within the MLAG system, and the routing tables associated with each access device.

[0009] exist Figure 2 In this system, the core device can forward traffic to access devices. Understandably, when the Peer-link between the MLAG master and MLAG slave devices is functioning correctly, the traffic can be sent to the user-side access device 1 (which can be a server or a switch) via both devices. However, when the Peer-link fails, the MLAG slave device can send the corresponding monitoring event to the server. The server, based on the monitoring event identifier and its association with the MLAG event, sends a control command to the core device. The core device then sets the cost value of ECMP (Equal Cost Multi Path) path2 in the routing table to the maximum value, thus ensuring that traffic is sent to access device 1 only via the MLAG master device.

[0010] However, this method also has some problems. First, when an MLAG slave device determines that the Peer-link link is faulty, it needs to send the monitoring event to the controller, which then processes it and sends relevant instructions to the core device. Therefore, the transmission of the fault event involves a detour, which slows down fault reporting and leads to untimely fault handling. Second, this method switches traffic forwarding links by processing the routing cost value, so it is strongly correlated with the number of routes. If the number of devices connected to the MLAG slave device is large, the processing efficiency will be low.

[0011] In summary, existing technologies for handling traffic forwarding anomalies often suffer from slow fault reporting, untimely fault handling, low processing efficiency, and slow link switching convergence when there are a large number of access devices in the MLAG system. Summary of the Invention

[0012] In view of this, the purpose of this application is to provide a fault handling method and related apparatus to improve fault reporting efficiency and fault handling efficiency, while also improving fault handling efficiency and link switching convergence speed.

[0013] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0014] In a first aspect, this application provides a fault handling method applied to a network-side device connected to an MLAG system, wherein the MLAG system includes two member devices that are connected via a peer-to-peer link; the method includes:

[0015] Obtain a peer link failure event sent by any of the member devices;

[0016] The peer link failure event is generated and sent by the member device when the peer link failure is determined based on the link status of the peer link. The peer link failure event includes the slave device identifier of the slave member device in the MLAG system.

[0017] The next-hop information to be processed is obtained from the locally stored ECMP configuration group based on the device identifier;

[0018] The ECMP table is updated based on the next-hop information to be processed, thereby updating the forwarding link between the network-side device and the MLAG system.

[0019] In an optional implementation, the ECMP configuration group includes multiple ECMP groups, each ECMP group includes two next-hop groups, and each next-hop group includes at least one next-hop information;

[0020] The step of obtaining the next-hop information to be processed from the locally stored ECMP configuration group based on the slave device identifier includes:

[0021] The next-hop group corresponding to the slave device identifier is designated as the slave next-hop group, and another next-hop group in the ECMP group to which the slave next-hop group belongs is designated as the master next-hop group;

[0022] The next hop information from the next hop group and the main next hop group is used as the next hop information to be processed.

[0023] In an optional implementation, updating the ECMP table based on the next-hop information to be processed, so as to update the forwarding link between the network-side device and the MLAG system, includes:

[0024] Determine whether to update the ECMP table based on the next-hop information to be processed;

[0025] If it is determined that the ECMP table needs to be updated, the next-hop information corresponding to the slave member device is deleted from the ECMP table based on the next-hop information to be processed.

[0026] In an optional implementation, the next-hop information to be processed includes next-hop information from the next-hop group and next-hop information from the primary next-hop group. The step of determining whether to update the ECMP table based on the next-hop information to be processed includes:

[0027] If at least one next-hop information in the next-hop group matches the next-hop information in the ECMP table, and at least one next-hop information in the main next-hop group matches the next-hop information in the ECMP table, then it is determined that the ECMP table should be updated.

[0028] The step of deleting the next-hop information corresponding to the member device from the ECMP table based on the next-hop information to be processed includes:

[0029] Remove the next-hop information from the next-hop group that matches the ECMP table from the ECMP table.

[0030] Secondly, this application provides a fault handling method applied to any member device in an MLAG system, wherein the MLAG system includes two member devices connected via a peer-to-peer link, and the MLAG system is also connected to a network-side device; the method includes:

[0031] Obtain the link status of the peer link;

[0032] If a peer link failure is determined based on the link status of the peer link, a peer link failure event is generated based on the slave device identifier corresponding to the member device, and the peer link failure event is sent to the network-side device. This allows the network-side device to obtain the pending next-hop information from the locally stored ECMP configuration group based on the slave device identifier, and update the ECMP table based on the pending next-hop information to update the forwarding link between the network-side device and the MLAG system.

[0033] Thirdly, this application provides a fault handling device applied to a network-side device connected to an MLAG system, wherein the MLAG system includes two member devices that are connected to each other via a peer-to-peer link; the device includes:

[0034] A receiving module is used to acquire peer link failure events sent by any of the member devices;

[0035] The peer link failure event is generated and sent by the member device when the peer link failure is determined based on the link status of the peer link. The peer link failure event includes the slave device identifier of the slave member device in the MLAG system.

[0036] The receiving module is further configured to obtain the next-hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier;

[0037] The update module is used to update the ECMP table according to the next-hop information to be processed, so as to update the forwarding link between the network-side device and the MLAG system.

[0038] Fourthly, this application provides a fault handling device applied to any member device in an MLAG system, wherein the MLAG system includes two member devices that are connected via a peer-to-peer link, and the MLAG system is also connected to a network-side device; the device includes:

[0039] The acquisition module is used to acquire the link status of the peer link;

[0040] The sending module is configured to, when determining that the peer link is faulty based on the link status of the peer link, generate a peer link failure event based on the slave device identifier corresponding to the member device, and send the peer link failure event to the network-side device, so that the network-side device can obtain the pending next-hop information from the locally stored ECMP configuration group based on the slave device identifier, and update the ECMP table based on the pending next-hop information, so as to update the forwarding link between the network-side device and the MLAG system.

[0041] Fifthly, this application provides a network-side device, including a processor and a memory, wherein the memory stores a computer program executable by the processor, and the processor can execute the computer program to implement the method described in any of the foregoing embodiments.

[0042] In a sixth aspect, this application provides a member device including a processor and a memory, the memory storing a computer program executable by the processor, the processor being able to execute the computer program to implement the methods described in the foregoing embodiments.

[0043] In a seventh aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the foregoing embodiments, or the method described in the foregoing embodiments.

[0044] The fault handling method and related apparatus provided in this application embodiment allow member devices to generate and send peer link failure events when a peer link failure is determined based on the link status of the peer link. These peer link failure events may include slave device identifiers of the slave member devices in the MLAG system. The network-side device can then obtain pending next-hop information from the locally stored ECMP configuration group based on the slave device identifier, and update the ECMP table accordingly to update the forwarding link between the network-side device and the MLAG system. Since member devices can directly send peer link failure events to the network-side device based on the link status, there is no need to detect faults through routing protocols or to send fault events via other devices, thereby improving fault detection speed and fault reporting speed, and consequently, improving the timeliness of fault handling. Furthermore, since the network-side device updates the forwarding link by processing the ECMP table rather than based on routing, the number of access devices in the MLAG system is irrelevant, thus improving processing efficiency and link switching convergence speed.

[0045] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0046] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present application 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.

[0047] Figure 1 A communication example diagram of an MLAG system is shown;

[0048] Figure 2 Another communication example diagram of the MLAG system is shown;

[0049] Figure 3 A block diagram of the communication system is shown;

[0050] Figure 4 A block diagram of a communication device is shown;

[0051] Figure 5 This paper illustrates a flowchart of a fault handling method provided in an embodiment of the present application.

[0052] Figure 6 This paper illustrates another flowchart of the fault handling method provided in an embodiment of this application;

[0053] Figure 7 This paper shows a functional block diagram of a fault handling device provided in an embodiment of the present application;

[0054] Figure 8 Another functional block diagram of the fault handling device provided in the embodiments of this application is shown.

[0055] Icons: 10 - Network-side equipment; 20 - MALG system; 30 - User-side equipment; 100 - Memory; 110 - Processor; 120 - Communication module; 200 - Member equipment; 300 - Receive module; 310 - Update module; 400 - Acquisition module; 410 - Transmit module. Detailed Implementation

[0056] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can be arranged and designed in various different configurations.

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

[0058] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0059] Figure 3 For a block diagram of the communication system, please refer to [link / reference]. Figure 3 The communication system includes a network-side device 10, an MLAG system 20, and a user-side device 30. The network-side device 10 is communicatively connected to the MLAG system 20, and the MLAG system 20 is communicatively connected to the user-side device 30.

[0060] Optionally, the MLAG system 20 includes two member devices 200, which can be connected via a peer-to-peer link.

[0061] Understandably, one of these two member devices is the master member device and the other is the slave member device, but the roles of the member devices are not fixed and can be changed according to the actual application.

[0062] Optionally, the peer link can be a peer-link link.

[0063] It's important to note that a peer-link is a direct connection used to ensure direct communication between two devices. This link must be aggregated to improve reliability and bandwidth. Peer-links can be used to exchange negotiation messages, ensuring that the two devices can synchronize entries and configuration information. Peer-links also transmit some traffic to achieve load balancing and failover.

[0064] Furthermore, once an interface is configured as a Peer-link interface, no other services can be configured on that interface. Peer-link also serves to synchronize table entries, ensuring that the table entries learned by the two MLAG member devices are consistent, thereby guaranteeing that the two MLAG member devices jointly participate in traffic forwarding. However, if the Peer-link link fails, the two MLAG member devices will enter a dual-master state, and the learned table entries will not be synchronized to the other end, resulting in abnormal traffic forwarding.

[0065] Furthermore, to increase the reliability of the Peer-link link, multiple physical links can generally be aggregated.

[0066] Optionally, the MLAG system can communicate with multiple network-side devices. Understandably, network-side devices can communicate with user-side devices through the MLAG system.

[0067] Optionally, to facilitate fault management for the MLAG system, a fault management module can be set up in the communication system.

[0068] In this embodiment, the MLAG system may have a client application for a fault management module, and the network-side device may have a server application for the fault management module.

[0069] Optionally, the client application of this fault management module can support configuring the system MAC address of the device where the server is located. Understandably, since there can be multiple network-side devices communicating with the MLAG system, multiple system MAC addresses can also be configured.

[0070] Optionally, to facilitate fault management by the fault management module, the client can also obtain the MALG role of the member device, i.e., whether the device is a slave member device or a master member device.

[0071] In one possible implementation, the client can acquire the MLAG role through a subscription.

[0072] Optionally, the client can also obtain the peer link status to determine whether the peer link is faulty.

[0073] In one possible implementation, the client can directly monitor the peer link down (disconnect or close) events of the underlying driver to obtain the peer link status. In another possible implementation, the client can also subscribe to MLAG peer link failure events to obtain the peer link status.

[0074] Optionally, the server can support configuring ECMP groups according to actual needs.

[0075] Furthermore, in Figure 3 On this basis, Figure 4 For a block diagram of the communication device, please refer to [link / reference]. Figure 4 The communication device includes a communication device memory 100, a processor 110, and a communication module 120. The memory 100, processor 110, and communication module 120 are electrically connected directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines.

[0076] The memory 100 is used to store computer programs or data that can be executed by the processor. The memory 100 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0077] The processor 110 is used to read / write data or computer programs stored in the memory, and execute the computer program to implement the fault handling method provided in the embodiments of this application.

[0078] The communication module 120 is used to establish a communication connection between the communication device and other communication terminals through the network, and to send and receive data through the network.

[0079] Understandably, the communication device may be the network-side device 10 provided in the embodiments of this application, or the member device 200 provided in the embodiments of this application.

[0080] It should be understood that, Figure 4 The structure shown is only a schematic diagram of the communication device; the communication device may also include components that are larger than those shown. Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof.

[0081] The following is based on the above. Figure 3 The network-side device in this application is the execution entity. The fault handling method provided in the embodiments of this application is described by way of example in conjunction with the flowchart.

[0082] Specifically, Figure 5 Please refer to the flowchart of a fault handling method provided in the embodiments of this application. Figure 5 The method includes:

[0083] Step S20: Obtain the peer link failure event sent by any member device.

[0084] Among them, the peer link failure event is generated and sent by the member device when the peer link failure is determined based on the link status of the peer link. The peer link failure event includes the slave device identifier of the slave member device in the MLAG system.

[0085] Optionally, the peer-to-peer link failure event can be generated and sent by the master member device or by the slave member device, depending on the specific application.

[0086] In one possible implementation, the master member device can store the slave device identifier of the slave member device. Then, the fault management module client in the master member device can generate a peer link failure event based on the slave device identifier when the peer link failure is determined according to the link status, and send the peer link failure event to the fault management module server of the network side device.

[0087] In another possible implementation, the fault management module client in the member device can generate a peer link failure event based on the slave device identifier when a peer link failure is determined based on the link status, and send the peer link failure event to the fault management module server of the network side device.

[0088] Step S21: Obtain the next-hop information to be processed from the locally stored ECMP configuration group based on the slave device identifier.

[0089] Optionally, the network-side device may also store an ECMP configuration group, which includes multiple next-hop information and includes a device identifier.

[0090] Optionally, the device identifier refers to the identifier of a member device, and each device identifier can uniquely represent a member device.

[0091] In one possible implementation, the device identifier can be the system MAC address of a member device.

[0092] Optionally, the next-hop information may also include the next-hop address.

[0093] Optionally, the fault management module server in the network-side device can match the slave device identifier in the ECMP configuration group to obtain the next hop information to be processed.

[0094] Step S22: Update the ECMP table according to the next-hop information to be processed, so as to update the forwarding link between the network-side device and the MLAG system.

[0095] Optionally, the fault management module server in the network-side device can notify the ECMP module of the next-hop information to be processed, and the ECMP module can update the ECMP table, thereby updating the forwarding link between the network-side device and the MLAG system.

[0096] Understandably, please continue to refer to Figure 3 Before the update, network-side devices could send traffic to user-side devices through all member devices in the MLAG system. After the update, network-side devices can send traffic to user-side devices only through the primary member device in the MLAG system.

[0097] In the fault handling method of this application embodiment, member devices can generate and send a peer-to-peer link failure event when a peer-to-peer link failure is determined based on the link status of the peer-to-peer link. This peer-to-peer link failure event may include the slave device identifier of the slave member device in the MLAG system. The network-side device can then obtain the next-hop information to be processed from the locally stored ECMP configuration group based on the slave device identifier, and update the ECMP table according to this next-hop information to update the forwarding link between the network-side device and the MLAG system. Since member devices can directly send peer-to-peer link failure events to the network-side device based on the link status, there is no need to detect faults through routing protocols or to send fault events via other devices, thereby improving the speed of fault detection and reporting, and thus improving the timeliness of fault handling. Furthermore, since the network-side device updates the forwarding link by processing the ECMP table rather than based on routing, it is independent of the number of access devices of the slave devices in the MLAG system, thereby improving processing efficiency and link switching convergence speed.

[0098] Optionally, the ECMP configuration group may include multiple ECMP groups, each ECMP group including two next-hop groups, and each next-hop group including at least one next-hop information.

[0099] Optionally, the next-hop information for two member devices in an MLAG system can be set in different next-hop groups within the same ECMP group.

[0100] Optionally, each next-hop group may include a device identifier and at least one next-hop address.

[0101] In one example, with Figure 1 Taking the MLAG system as an example, the configuration of its corresponding ECMP group ECMP group1 can be characterized as follows:

[0102] ECMP group1

[0103] nh-group1

[0104] The unique device identifier of DUT1 is DUT1.if1.addr. / / The next hop in the next hop group can be configured in multiple ways depending on the actual network topology.

[0105] nh-group2

[0106] The unique device identifier of DUT2 is DUT2.if1.addr. / / The next hop in the next hop group can be configured in multiple ways depending on the actual network topology.

[0107] Here, nh-group1 and nh-group2 are two next-hop groups in this ECMP group, the device identifier and address are the next-hop information, and if1 refers to the interface in the MLAG system that communicates with DUT3.

[0108] The following provides a possible approach for retrieving the next-hop information to be processed from the locally stored ECMP configuration group based on the device identifier.

[0109] Specifically, the network-side device can use the next-hop group corresponding to the device identifier as the slave next-hop group, another next-hop group in the ECMP group where the slave next-hop group is located as the master next-hop group, and the next-hop information in the slave next-hop group and the master next-hop group as the next-hop information to be processed.

[0110] Please refer to the example above. If the member device is DUT2, the network-side device can use the next-hop group nh-group2 where DUT2 is located as the slave next-hop group, and use the other next-hop group nh-group1 in the ECMP group ECMP group1 where nh-group2 is located as the master next-hop group.

[0111] In this example, the next-hop information in nh-group1 and nh-group2 is all next-hop information to be processed.

[0112] Optionally, since there may be multiple access devices under a member device, these access devices may not communicate with the MLAG system, but only with the member devices, for example... Figure 1 Server B is in the middle, so some information in the ECMP table may not need to be updated.

[0113] Specifically, the network-side device can determine whether to update the ECMP table based on the next-hop information to be processed, and if it is determined that the ECMP table should be updated, it can delete the next-hop information corresponding to the member device from the ECMP table based on the next-hop information to be processed.

[0114] Optionally, the network-side device can determine, based on the next-hop information to be processed, whether the user-side device to which the information points is connected to the MLAG system or only connected to the slave device.

[0115] Understandably, if the user-side device is connected to the MLAG system, it can be determined that the ECMP table will be updated; if the user-side device is only connected to the slave device, it can be determined that the ECMP table will not be updated.

[0116] The following section provides a possible implementation method for determining whether to update the ECMP table based on the next-hop information to be processed.

[0117] In this embodiment, if at least one next-hop information in the next-hop group matches the next-hop information in the ECMP table, and at least one next-hop information in the main next-hop group matches the next-hop information in the ECMP table, then it is determined that the ECMP table should be updated.

[0118] Furthermore, if the server determines that the ECMP table needs to be updated, it can delete the next-hop information from the next-hop group that matches the ECMP table from the ECMP table.

[0119] Understandably, if at least one next-hop information in the next-hop group matches the next-hop information in the ECMP table, and at least one next-hop information in the primary next-hop group matches the next-hop information in the ECMP table, then the corresponding user-side device can be determined to be connected to the MLAG system, and thus the ECMP table can be updated.

[0120] Optionally, if the next-hop information in the primary next-hop group does not match the next-hop information in the ECMP table, it can be determined that the corresponding user-side device only communicates with the slave member device, and therefore the ECMP table is not updated.

[0121] Optionally, the server can delete the next-hop information from the next-hop group that matches the ECMP table from the ECMP table, and delete the next-hop information corresponding to the member device from the ECMP table, thereby sending traffic from the network-side device only through the primary member device to the user-side device.

[0122] The following is based on the above. Figure 3 Taking any member device as the execution subject, the fault handling method provided in the embodiments of this application will be described executively with reference to the flowchart. Specifically, Figure 6 For another flowchart illustrating the fault handling method provided in this application embodiment, please refer to [link / reference]. Figure 6 The method includes:

[0123] Step S30: Obtain the link status of the peer link.

[0124] Step S31: If a peer link failure is determined based on the link status of the peer link, a peer link failure event is generated based on the slave device identifier corresponding to the member device, and the peer link failure event is sent to the network-side device so that the network-side device can obtain the next-hop information to be processed from the ECMP configuration group based on the slave device identifier, and update the ECMP table based on the next-hop information to update the forwarding link between the network-side device and the MLAG system.

[0125] In the fault handling method of this application embodiment, member devices can generate and send a peer-to-peer link failure event when a peer-to-peer link failure is determined based on the link status of the peer-to-peer link. This peer-to-peer link failure event may include the slave device identifier of the slave member device in the MLAG system. The network-side device can then obtain the next-hop information to be processed from the locally stored ECMP configuration group based on the slave device identifier, and update the ECMP table according to this next-hop information to update the forwarding link between the network-side device and the MLAG system. Since member devices can directly send peer-to-peer link failure events to the network-side device based on the link status, there is no need to detect faults through routing protocols or to send fault events via other devices, thereby improving the speed of fault detection and reporting, and thus improving the timeliness of fault handling. Furthermore, since the network-side device updates the forwarding link by processing the ECMP table rather than based on routing, it is independent of the number of access devices of the slave devices in the MLAG system, thereby improving processing efficiency and link switching convergence speed.

[0126] To perform the corresponding steps in the above embodiments and various possible methods, an implementation of a fault handling device applied to a network-side device is given below. Further, please refer to... Figure 7 , Figure 7 This is a functional block diagram of a fault handling device provided in an embodiment of this application. It should be noted that the basic principle and technical effects of the fault handling device provided in this embodiment are the same as those in the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments. The fault handling device includes: a receiving module 300 and an updating module 310.

[0127] The receiving module 300 is used to acquire a peer link failure event sent by any member device; wherein the peer link failure event is generated and sent by the member device when the peer link failure is determined based on the link status of the peer link, and the peer link failure event includes the slave device identifier of the slave member device in the MLAG system.

[0128] Understandably, the receiving module 300 can also be used to perform the above step S20.

[0129] The receiving module 300 is also configured to obtain the next-hop information to be processed from the locally stored ECMP configuration group based on the slave device identifier.

[0130] Understandably, the receiving module 300 can also be used to perform the above step S21.

[0131] The update module 310 is used to update the ECMP table based on the next-hop information to be processed, so as to update the forwarding link between the network-side device and the MLAG system.

[0132] Understandably, the update module 310 can also be used to perform the above step S22.

[0133] Optionally, the receiving module 300 is further configured to use the next-hop group corresponding to the slave device identifier as the slave next-hop group, and another next-hop group in the ECMP group where the slave next-hop group is located as the master next-hop group; and to use the next-hop information in the slave next-hop group and the master next-hop group as the next-hop information to be processed.

[0134] Optionally, the update module 310 is further configured to determine whether to update the ECMP table based on the next-hop information to be processed; if it is determined that the ECMP table should be updated, the next-hop information corresponding to the member device is deleted from the ECMP table based on the next-hop information to be processed.

[0135] Optionally, the update module 310 is further configured to determine to update the ECMP table if at least one next-hop information in the next-hop group matches the next-hop information in the ECMP table, and at least one next-hop information in the primary next-hop group matches the next-hop information in the ECMP table.

[0136] Optionally, the update module 310 is also used to delete next-hop information from the ECMP table that matches the ECMP table from the next-hop group.

[0137] The following describes an implementation of a fault handling device applicable to any member device. For further details, please refer to [link to relevant documentation]. Figure 8 This is another functional block diagram of the fault handling device provided in the embodiments of this application. The fault handling device includes: an acquisition module 400 and a transmission module 410.

[0138] The acquisition module 400 is used to acquire the link status of peer links.

[0139] Understandably, the acquisition module 400 can also be used to perform the above step S30.

[0140] The sending module 410 is used to generate a peer link failure event based on the slave device identifier corresponding to the member device when a peer link failure is determined based on the link status of the peer link, and send the peer link failure event to the network-side device so that the network-side device can obtain the next-hop information to be processed from the locally stored ECMP configuration group based on the slave device identifier, and update the ECMP table based on the next-hop information to update the forwarding link between the network-side device and the MLAG system.

[0141] Understandably, the sending module 410 can also be used to perform the above step S31.

[0142] Optionally, the above modules can be stored in the form of software or firmware. Figure 4 The memory shown is either stored in or embedded in the operating system (OS) of the communication device, and can be used by... Figure 4 The processor executes the commands. Meanwhile, the data and program code required to execute these modules can be stored in memory.

[0143] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the fault handling method provided in this application.

[0144] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0145] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

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

[0147] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A fault handling method, characterized in that, A method is applied to network-side devices connected to an MLAG system, wherein the MLAG system includes two member devices that are connected via a peer-to-peer link; the method includes: Obtain a peer link failure event sent by any of the member devices; The peer link failure event is generated and sent by the member device when the peer link failure is determined based on the link status of the peer link. The peer link failure event includes the slave device identifier of the slave member device in the MLAG system. The next-hop group corresponding to the slave device identifier is designated as the slave next-hop group, and another next-hop group in the ECMP group to which the slave next-hop group belongs is designated as the master next-hop group; wherein, the ECMP group includes two next-hop groups, and each next-hop group includes at least one next-hop information; The next hop information in the next hop group and the main next hop group is used as the next hop information to be processed; The ECMP table is updated based on the next-hop information to be processed, thereby updating the forwarding link between the network-side device and the MLAG system.

2. The method according to claim 1, characterized in that, The step of updating the ECMP table based on the next-hop information to be processed, so as to update the forwarding link between the network-side device and the MLAG system, includes: Determine whether to update the ECMP table based on the next-hop information to be processed; If it is determined that the ECMP table needs to be updated, the next-hop information corresponding to the slave member device is deleted from the ECMP table based on the next-hop information to be processed.

3. The method according to claim 2, characterized in that, The next-hop information to be processed includes next-hop information from the next-hop group and next-hop information from the primary next-hop group. Determining whether to update the ECMP table based on the next-hop information to be processed includes: If at least one next-hop information in the next-hop group matches the next-hop information in the ECMP table, and at least one next-hop information in the main next-hop group matches the next-hop information in the ECMP table, then it is determined that the ECMP table should be updated. The step of deleting the next-hop information corresponding to the member device from the ECMP table based on the next-hop information to be processed includes: Remove the next-hop information from the next-hop group that matches the ECMP table from the ECMP table.

4. A fault handling method, characterized in that, The method is applied to any member device in an MLAG system, wherein the MLAG system includes two member devices that are connected via a peer-to-peer link, and the MLAG system is also connected to a network-side device; the method includes: Obtain the link status of the peer link; If a peer link failure is determined based on the link status of the peer link, a peer link failure event is generated based on the slave device identifier corresponding to the member device, and the peer link failure event is sent to the network-side device. The network-side device then designates the next-hop group corresponding to the slave device identifier as the slave next-hop group, designates another next-hop group in the ECMP group containing the slave next-hop group as the master next-hop group, and designates the next-hop information in the slave and master next-hop groups as next-hop information to be processed. The ECMP table is then updated based on the next-hop information to update the forwarding link between the network-side device and the MLAG system. The ECMP group includes two next-hop groups, and each next-hop group includes at least one next-hop information.

5. A fault handling device, characterized in that, A network-side device applied to an uplink MLAG system, wherein the MLAG system includes two member devices connected via a peer-to-peer link; the device includes: A receiving module is used to acquire peer link failure events sent by any of the member devices; The peer link failure event is generated and sent by the member device when the peer link failure is determined based on the link status of the peer link. The peer link failure event includes the slave device identifier of the slave member device in the MLAG system. The receiving module is further configured to take the next-hop group corresponding to the slave device identifier as the slave next-hop group, take another next-hop group in the ECMP group where the slave next-hop group is located as the master next-hop group, and take the next-hop information in the slave next-hop group and the master next-hop group as next-hop information to be processed, wherein the ECMP group includes two next-hop groups, and each next-hop group includes at least one next-hop information; The update module is used to update the ECMP table according to the next-hop information to be processed, so as to update the forwarding link between the network-side device and the MLAG system.

6. A fault handling device, characterized in that, An apparatus applicable to any member device in an MLAG system, wherein the MLAG system comprises two member devices connected via a peer-to-peer link, and the MLAG system also communicates with network-side devices; the apparatus includes: The acquisition module is used to acquire the link status of the peer link; The sending module is configured to, when determining that the peer link is faulty based on the link status of the peer link, generate a peer link failure event based on the slave device identifier corresponding to the member device, and send the peer link failure event to the network-side device. This allows the network-side device to designate the next-hop group corresponding to the slave device identifier as a secondary next-hop group, designate another next-hop group in the ECMP group containing the secondary next-hop group as a primary next-hop group, designate the next-hop information in the secondary and primary next-hop groups as next-hop information to be processed, and update the ECMP table based on the next-hop information to be processed. This updates the forwarding link between the network-side device and the MLAG system. The ECMP group includes two next-hop groups, and each next-hop group includes at least one next-hop information.

7. A network-side device, characterized in that, It includes a processor and a memory, the memory storing a computer program executable by the processor, the processor being able to execute the computer program to implement the method of any one of claims 1-3.

8. A member device, characterized in that, It includes a processor and a memory, the memory storing a computer program that can be executed by the processor to implement the method of claim 4.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1-3, or the method of claim 4.

Images