Fault processing method and related device

Abstract

The embodiment of the invention provides a fault processing method and a related device, and relates to the technical field of communication. 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 under the condition that the peer-to-peer link fault is determined according to the link state of the peer-to-peer link, and the peer-to-peer link fault event comprises a slave device identifier of a slave member device in the MLAG system; acquiring next hop information to be processed from a locally stored ECMP configuration group according to the slave device identifier; and updating the ECMP table according to the next hop information to be processed so as to update a forwarding link between the network side equipment and the MLAG system. According to the method, the fault sensing speed and the fault reporting speed can be improved, so that the timeliness of fault processing is improved, and the processing efficiency and the link switching convergence speed can be improved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a fault handling method and related devices. Background Art

[0002] MLAG (Multi-Chassis Link Aggregation Group) is a mechanism that can achieve cross-device link aggregation, which can achieve link aggregation between multiple devices, thereby improving link reliability from the single-board level to the device level, forming a dual-active system or a multi-active system. In the MLAG system, two member devices can be connected through a peer link, so that the two member devices logically become one device.

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

[0004] In the prior art, this problem of abnormal traffic forwarding can be solved in the following ways.

[0005] Specifically, Figure 1 This is a communication example diagram of the MLAG system. Figure 1 The MLAG system includes two member devices, namely DUT1 and DUT2, where DUT1 is the master device in the MLAG system, DUT2 is the slave device in the MLAG system, and DUT1 and DUT2 are connected through a peer-link, and DUT3 is the network-side device connected to the MLAG system. A neighbor relationship can be established between DUT3, DUT1, and DUT2 based on a routing protocol, such as an OSPF (Open Shortest Path First) neighbor. In addition, DUT1 and DUT2 can also communicate with server A on the user side of the access, and the interface route or host route corresponding to server A can be notified to DUT3 through OSPF on DUT1 and DUT2.

[0006] In this case, the network side device DUT3 can forward the traffic of the user side device server A. When the peer-link between DUT1 and DUT2 is not faulty, the traffic can be forwarded according to Figure 1In the direction of arrow 1 shown in the figure, it is forwarded to server A through DUT1 and DUT2 respectively. When the peer-link between DUT1 and DUT2 fails, DUT2 will actively disconnect the downstream interface for communication with the server. The routing protocol (OSPF) on DUT2 can invalidate the routes related to the layer 3 link corresponding to the downstream interface when it senses the failure of the layer 3 link corresponding to the downstream interface. At the same time, the routing protocol will also send a route withdrawal message for the downstream interface to DUT3. When DUT3 receives the route withdrawal message, it can delete the corresponding routes layer by layer from the routing protocol layer to the forwarding layer. Therefore, when DUT3 forwards the traffic to access server A, it will only follow Figure 1 The traffic is forwarded to server A through DUT1 in the direction of arrow No. 2 shown in the figure.

[0007] However, this solution also has some problems. First, the routing protocol needs to determine the Layer 3 link failure corresponding to the downstream interface for communication with the server only when DUT2 actively disconnects the downstream interface, so as to perform relevant processing. That is, DUT2 needs to perform some operations after the peer-link link fails before the routing protocol can detect the fault. Therefore, there is a problem of slow fault perception, which will lead to slow fault reporting and untimely fault processing. Secondly, this method switches the traffic forwarding link by revoking the routing protocol, but for DUT2, the number of corresponding routes may be large, such as Figure 1 As shown, DUT2 can be connected to other servers such as server B in addition to server A, and the processing based on routing is strongly related to the number of routes, that is, if the number of devices connected to DUT2 is large, the processing efficiency will be low. In addition, the routing-based method requires layer-by-layer processing from the routing protocol layer to the forwarding layer, which will also lead to low processing efficiency and slow link switching convergence.

[0008] In addition, the existing technology can also solve the problem of abnormal traffic forwarding by connecting to an external server. Figure 2 For another communication example diagram of the MLAG system, see Figure 2 The MLAG system includes two member devices, namely the MLAG master device and the MLAG slave device, and a controller is set to communicate with the MLAG system. The MLAG master device and the MLAG slave device are both configured with monitoring event identifiers, and the controller maintains the association relationship between the monitoring event identifier and the MLAG event, wherein the content of the monitoring event includes the MLAG system, the core device communicating with the MLAG system, the access device of the MLAG system, the slave device in the MLAG system, and the routing table associated with each access device.

[0009] exist Figure 2 In the embodiment, the core device can forward the traffic accessing the access device. It can be understood that when the Peer-link between the MLAG master device and the MLAG slave device is not faulty, the traffic can be sent to the access device 1 (which can be a server or a switch) on the user side through the MLAG master device and the MLAG slave device. When the Peer-link fails, the MLAG slave device can send the corresponding monitoring event to the server. The server sends a control instruction to the core device according to the monitoring event identifier corresponding to the event and the association between the monitoring event identifier and the MLAG event. The core device sets the cost value of the route of ECMP (Equal Cost Multi Path) path 2 in the routing table to the maximum value according to the control instruction, thereby sending the traffic to the access device 1 only through the MLAG master device.

[0010] However, this method also has some problems. First, when the MLAG slave device determines that the peer-link link is faulty, it needs to send the monitoring event to the controller first, which will process it and then send relevant instructions to the core device. Therefore, the transmission of the fault event is detoured, which will slow down the fault reporting and lead to untimely fault processing. Secondly, this method processes the overhead value of the route to switch the traffic forwarding link, so it is strongly related to 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, when dealing with abnormal traffic forwarding problems in the prior art, there are often problems such as slow fault reporting and untimely fault handling, as well as 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 the present application is to provide a fault handling method and related devices to improve the fault reporting efficiency and fault handling efficiency, while improving the fault handling efficiency and link switching convergence speed.

[0013] In order to achieve the above purpose, the technical solution adopted in the embodiment of the present application is as follows:

[0014] In a first aspect, the present application provides a fault handling method, which is applied to a network-side device connected to an MLAG system, wherein the MLAG system includes two member devices, and the member devices are connected to each other through a peer-to-peer link communication; the method includes:

[0015] Obtaining 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 according to the link state of the peer link, and the peer link failure event includes a slave device identifier of a slave member device in the MLAG system;

[0017] Obtaining next hop information to be processed from a locally stored ECMP configuration group according to the slave device identifier;

[0018] The ECMP table is updated 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.

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

[0020] The obtaining the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier includes:

[0021] The next hop group corresponding to the slave device identifier is used as the slave next hop group, and another next hop group in the ECMP group where the slave next hop group is located is used as the master next hop group;

[0022] The next hop information in the slave next hop group and the master next hop group is used as the next hop information to be processed.

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

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

[0025] In the case where it is determined to update the ECMP table, the next hop information corresponding to the slave member device is deleted from the ECMP table according to the next hop information to be processed.

[0026] In an optional implementation manner, the next hop information to be processed includes next hop information in a slave next hop group and next hop information in a primary next hop group, and determining whether to update the ECMP table according to the next hop information to be processed includes:

[0027] If at least one next hop information in the slave next hop group matches the next hop information in the ECMP table, and at least one next hop information in the master next hop group matches the next hop information in the ECMP table, determining to update the ECMP table;

[0028] The deleting the next hop information corresponding to the slave member device from the ECMP table according to the next hop information to be processed includes:

[0029] The next hop information in the next hop group that matches the ECMP table is deleted from the ECMP table.

[0030] In a second aspect, the present application provides a fault handling method, which is applied to any member device in an MLAG system, wherein the MLAG system includes two member devices, the member devices are communicatively connected via a peer link, and the MLAG system is also communicatively connected to a network side device; the method includes:

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

[0032] When the peer link failure is determined according to the link status of the peer link, a peer link failure event is generated according to the slave device identifier corresponding to the slave member device, and the peer link failure event is sent to the network side device, so that the network side device obtains the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier, and updates 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.

[0033] In a third aspect, the present application provides a fault handling device, which is applied to a network-side device connected to an MLAG system, wherein the MLAG system includes two member devices, and the member devices are connected to each other through a peer-to-peer link communication; the device includes:

[0034] A receiving module, used for acquiring a peer link failure event 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 according to the link state of the peer link, and the peer link failure event includes a slave device identifier of a slave member device in the MLAG system;

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

[0037] An updating 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] In a fourth aspect, the present application provides a fault handling device, which is applied to any member device in an MLAG system, wherein the MLAG system includes two member devices, the member devices are communicatively connected via a peer link, and the MLAG system is also communicatively connected to a network side device; the device includes:

[0039] An acquisition module, used to acquire the link status of the peer link;

[0040] A sending module is used to generate a peer link failure event according to a slave device identifier corresponding to a slave member device when the peer link failure is determined according to 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 obtains the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier, and updates 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.

[0041] In a fifth aspect, the present application provides a network side device, including a processor and a memory, wherein the memory stores a computer program that can be executed by the processor, and the processor can execute the computer program to implement the method described in any one of the aforementioned implementations.

[0042] In a sixth aspect, the present application provides a member device, including a processor and a memory, wherein the memory stores a computer program that can be executed by the processor, and the processor can execute the computer program to implement the method described in the aforementioned embodiment.

[0043] In a seventh aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the method described in any one of the aforementioned embodiments, or the method described in the aforementioned embodiments, is implemented.

[0044] In the fault handling method and related apparatus provided in the embodiment of the present application, a member device can generate and send a peer link failure event when determining a peer link failure according to the link status of the peer link. The peer link failure event may include a slave device identifier of a slave member device in the MLAG system. Then, the network side device can obtain the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier, thereby updating 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. Since the member device can directly send the peer link failure event to the network side device according to the link status, there is no need to perceive the fault through the routing protocol, and there is no need to send the fault event through other devices, thereby improving the fault perception speed and the fault reporting speed, and thus improving the timeliness of fault handling; in addition, since the network side device is not based on routing, but updates the forwarding link by processing the ECMP table, it is irrelevant to the number of access devices of the slave device in the MLAG system, thereby improving the processing efficiency and link switching convergence speed.

[0045] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. 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 related drawings can be obtained based on these drawings without paying creative work.

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

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

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

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

[0051] Figure 5 A schematic diagram of a process flow of a fault handling method provided in an embodiment of the present application is shown;

[0052] Figure 6 Another schematic diagram of a process flow of a fault handling method provided in an embodiment of the present application is shown;

[0053] Figure 7 A functional module diagram of a fault handling device provided in an embodiment of the present application is shown;

[0054] Figure 8 Another functional module diagram of the fault handling device provided in an embodiment of the present application is shown.

[0055] Icons: 10 - network side device; 20 - MALG system; 30 - user side device; 100 - memory; 110 - processor; 120 - communication module; 200 - member device; 300 - receiving module; 310 - updating module; 400 - acquiring module; 410 - sending module. DETAILED DESCRIPTION

[0056] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0057] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for which protection is sought, but merely represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0058] It should be noted that relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0059] Figure 3 For a block diagram of the communication system, see 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 communicatively connected via a peer-to-peer link.

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

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

[0063] It should be noted that Peer-link is a link that must be directly connected to ensure direct communication between two devices, and the link must be aggregated to improve link reliability and bandwidth. Peer-link can be used to exchange negotiation messages to ensure that the two devices can synchronize table entries and configuration information, and Peer-link is also used to transmit part of the traffic to achieve load balancing and failover.

[0064] In addition, once an interface is configured as a Peer-link interface, no other services can be configured on the interface. Peer-link also plays the role of table entry synchronization, so that the table entries learned by the two MLAG member devices are consistent, thereby ensuring that the two MLAG member devices participate in traffic forwarding together. If the Peer-link link fails, the two MLAG member devices will enter the dual-active state, and the learned table entries will not be synchronized to the other end, resulting in abnormal traffic forwarding.

[0065] Furthermore, in order to increase the reliability of the peer-link, multiple physical links can generally be used for link aggregation.

[0066] Optionally, the MLAG system can be connected to multiple network-side devices. It can be understood that the network-side device can communicate with the user-side device through the MLAG system.

[0067] Optionally, in order to facilitate fault management for the MLAG system, a fault management module may be provided in the communication system.

[0068] In this embodiment, a client application of the fault management module may be provided in the MLAG system, and a server application of the fault management module may be provided in the network side device.

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

[0070] Optionally, in order to facilitate the fault management module to manage the fault, the client may also obtain the MALG role of the member device, that is, whether the device is a slave member device or a master member device.

[0071] In a possible implementation, the client may obtain the MLAG role by subscription.

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

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

[0074] Optionally, the server may support configuration of an ECMP group according to actual conditions.

[0075] Further, in Figure 3 On the basis of Figure 4 For a block diagram of a communication device, see Figure 4 The communication device includes a communication device memory 100, a processor 110 and a communication module 120. The memory 100, the processor 110 and the communication module 120 are electrically connected to each other directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through 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 can be, but is not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable 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 embodiment of the present application.

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

[0079] It can be understood that the communication device can be the network side device 10 provided in the embodiment of the present application, or it can be the member device 200 provided in the embodiment of the present application.

[0080] It should be understood that Figure 4 The structure shown is only a schematic diagram of the structure of the communication device. The communication device may also include Figure 4 More or fewer components as shown, or with Figure 4 Different configurations shown. Figure 4 Each component shown in the figure can be implemented by hardware, software or a combination thereof.

[0081] Next, the above Figure 3 The network side device in the embodiment is the execution subject, and the fault handling method provided in the embodiment of the present application is exemplarily introduced in combination with the flow chart.

[0082] Specifically, Figure 5 A flowchart of a fault handling method provided in an embodiment of the present application is shown in Figure 5 , the method comprising:

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

[0084] The peer link failure event is generated and sent by a member device when a peer link failure is determined according to a link state of the peer link. The peer link failure event includes a slave device identifier of a slave member device in the MLAG system.

[0085] Optionally, the peer link failure event may be generated and sent by a master member device, or may be generated and sent by a slave member device, which may be specifically set according to actual application conditions.

[0086] In one possible implementation, the slave device identifier of the slave member device can be stored in the master 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 determining the peer link failure based on 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 slave member device can generate a peer link failure event based on the slave device identifier when determining the peer link failure 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, obtaining the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier.

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

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

[0091] In a possible implementation manner, the device identifier may be a system MAC of a member device.

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

[0093] Optionally, the fault management module server in the network side device may perform matching in the ECMP configuration group according to the slave device identifier, thereby obtaining 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 may notify the ECMP module of the next hop information to be processed, and the ECMP module updates 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, the network-side device can send traffic to the user-side device through all member devices in the MLAG system. After the update, the network-side device can send traffic to the user-side device only through the master member device in the MLAG system.

[0097] In the fault handling method of the embodiment of the present application, a member device can generate and send a peer link failure event when determining a peer link failure based on the link status of the peer link. The peer link failure event may include a slave device identifier of a slave member device in the MLAG system. 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, thereby updating the ECMP table based on the next hop information to be processed to update the forwarding link between the network side device and the MLAG system. Since the member device can directly send the peer link failure event to the network side device based on the link status, there is no need to perceive the fault through the routing protocol, and there is no need to send the fault event through other devices, thereby improving the fault perception speed and fault reporting speed, thereby improving the timeliness of fault handling; in addition, since the network side device updates the forwarding link by processing the ECMP table instead of routing, it is irrelevant to the number of access devices of the slave device in the MLAG system, thereby improving the processing efficiency and link switching convergence speed.

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

[0099] Optionally, next hop information corresponding to two member devices in an MLAG system are both set in different next hop groups in 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, Figure 1 Taking the MLAG system in as an example, the configuration of the 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 / / Multiple next hops in the next hop group can be configured according to the actual networking situation.

[0105] nh-group2

[0106] The unique device identifier of DUT2 is DUT2.if1.addr / / Multiple next hops in the next hop group can be configured according to the actual networking situation.

[0107] Among them, nh-group1 and nh-group2 are two next-hop groups in the ECMP group, the device identifier and address are the next-hop information, and if1 refers to the interface for communicating with DUT3 in the MLAG system.

[0108] Next, a possible implementation method is provided for how to obtain the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier.

[0109] Specifically, the network side device can use the next hop group corresponding to the slave 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 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.

[0110] Please continue to refer to the above example. If the slave 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 another 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 the next hop information to be processed.

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

[0113] Specifically, the network side device may determine whether to update the ECMP table according to the next hop information to be processed, and if it is determined to update the ECMP table, delete the next hop information corresponding to the slave member device from the ECMP table according to the next hop information to be processed.

[0114] Optionally, the network-side device may determine, based on the next-hop information to be processed, whether the user-side device pointed to by the information is connected to the MLAG system for communication, or is only connected to the slave member device for communication.

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

[0116] Next, a possible implementation method is provided for determining whether to update the ECMP table according to the next hop information to be processed.

[0117] In this embodiment, if at least one next hop information in the slave next hop group matches the next hop information in the ECMP table, and at least one next hop information in the master next hop group matches the next hop information in the ECMP table, it is determined to update the ECMP table.

[0118] Further, when determining to update the ECMP table, the server may delete the next hop information in the next hop group that matches the ECMP table from the ECMP table.

[0119] It can be understood that if at least one next hop information from 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, it can be determined that the corresponding user-side device is connected to the MLAG system for communication, and therefore 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 is only connected to the slave member device for communication, and therefore the ECMP table is not updated.

[0121] Optionally, the server may delete the next hop information corresponding to the slave member device from the ECMP table by deleting the next hop information matching the ECMP table from the next hop group in the ECMP table, thereby sending traffic from the network side device to the user side device only through the master member device.

[0122] Next, the above Figure 3 Any member device in is the execution subject, and the fault handling method provided in the embodiment of the present application is exemplarily introduced in combination with the flowchart. Specifically, Figure 6 For another flowchart of the fault handling method provided in the embodiment of the present application, please refer to Figure 6 , the method comprising:

[0123] Step S30, obtaining the link status of the peer link.

[0124] Step S31, when a peer link failure is determined according to the link status of the peer link, a peer link failure event is generated according to the slave device identifier corresponding to the slave member device, and the peer link failure event is sent to the network side device, so that the network side device obtains the next hop information to be processed from the ECMP configuration group according to the slave device identifier, and updates 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.

[0125] In the fault handling method of the embodiment of the present application, a member device can generate and send a peer link failure event when determining a peer link failure based on the link status of the peer link. The peer link failure event may include a slave device identifier of a slave member device in the MLAG system. 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, thereby updating the ECMP table based on the next hop information to be processed to update the forwarding link between the network side device and the MLAG system. Since the member device can directly send the peer link failure event to the network side device based on the link status, there is no need to perceive the fault through the routing protocol, and there is no need to send the fault event through other devices, thereby improving the fault perception speed and fault reporting speed, and thus improving the timeliness of fault handling; in addition, since the network side device is not based on routing, but updates the forwarding link by processing the ECMP table, it is irrelevant to the number of access devices of the slave device in the MLAG system, thereby improving the processing efficiency and link switching convergence speed.

[0126] In order to execute the corresponding steps in the above embodiments and various possible methods, an implementation method of a fault handling device applied to a network side device is given below. Figure 7 , Figure 7 A functional module diagram of a fault handling device provided in an embodiment of the present 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 of the above embodiments. For the sake of brief description, for parts not mentioned in this embodiment, reference can be made to the corresponding contents 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 obtain a peer link failure event sent by any member device; wherein the peer link failure event is generated and sent by a member device when a peer link failure is determined based on the link status of the peer link, and the peer link failure event includes a slave device identifier of a slave member device in the MLAG system.

[0128] It can be understood that the receiving module 300 can also be used to execute the above step S20.

[0129] The receiving module 300 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.

[0130] It can be understood that the receiving module 300 can also be used to execute the above step S21.

[0131] The updating module 310 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.

[0132] It can be understood that the updating module 310 can also be used to execute the above step S22.

[0133] Optionally, the receiving module 300 is further used 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 main next hop group; and use the next hop information in the slave next hop group and the main next hop group as the next hop information to be processed.

[0134] Optionally, the updating module 310 is further configured to determine whether to update the ECMP table according to the next hop information to be processed; if it is determined to update the ECMP table, delete the next hop information corresponding to the slave member device from the ECMP table according to the next hop information to be processed.

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

[0136] Optionally, the updating module 310 is further configured to delete, from the ECMP table, the next hop information in the next hop group that matches the ECMP table.

[0137] Next, we will give an implementation method of a fault handling device applied to any member device. For further information, please refer to Figure 8 , is another functional module diagram of the fault handling device provided in the embodiment of the present application. The fault handling device includes: an acquisition module 400 and a sending module 410.

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

[0139] It can be understood that the acquisition module 400 can also be used to execute the above step S30.

[0140] The sending module 410 is used to generate a peer link failure event according to a slave device identifier corresponding to a slave member device when a peer link failure is determined according to the link status of the peer link, and send the peer link failure event to a network side device, so that the network side device obtains the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier, and updates 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.

[0141] It can be understood that the sending module 410 can also be used to execute the above step S31.

[0142] Optionally, the above modules can be stored in the form of software or firmware. Figure 4 The memory shown in FIG. 1 or fixed in the operating system (OS) of the communication device, and can be Figure 4 Meanwhile, the data and program codes required for executing the above modules can be stored in the memory.

[0143] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the fault handling method provided in the embodiment of the present application can be implemented.

[0144] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and a part of the module, program segment or code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

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

[0146] If the function is implemented in the form of a software function 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 the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program codes.

[0147] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A fault handling method, characterized in that: A network-side device applied to an MLAG system, wherein the MLAG system includes two member devices, and the member devices are connected to each other through a peer-to-peer link communication; the method includes: Obtaining 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 according to the link state of the peer link, and the peer link failure event includes a slave device identifier of a slave member device in the MLAG system; Obtaining next hop information to be processed from a locally stored ECMP configuration group according to the slave device identifier; The ECMP table is updated 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.

2. The method according to claim 1, characterized in that The ECMP configuration group includes a plurality of ECMP groups, each of the ECMP groups includes two next hop groups, and each of the next hop groups includes at least one next hop information; The obtaining the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier includes: The next hop group corresponding to the slave device identifier is used as the slave next hop group, and another next hop group in the ECMP group where the slave next hop group is located is used as the master next hop group; The next hop information in the slave next hop group and the master next hop group is used as the next hop information to be processed.

3. The method according to claim 1, characterized in that The updating of the ECMP table according to the next hop information to be processed to update the forwarding link between the network side device and the MLAG system includes: Determine whether to update the ECMP table according to the next hop information to be processed; In the case where it is determined to update the ECMP table, the next hop information corresponding to the slave member device is deleted from the ECMP table according to the next hop information to be processed.

4. The method according to claim 3, characterized in that The next hop information to be processed includes next hop information in a slave next hop group and next hop information in a master next hop group, and determining whether to update the ECMP table according to the next hop information to be processed includes: If at least one next hop information in the slave next hop group matches the next hop information in the ECMP table, and at least one next hop information in the master next hop group matches the next hop information in the ECMP table, determining to update the ECMP table; The deleting the next hop information corresponding to the slave member device from the ECMP table according to the next hop information to be processed includes: The next hop information in the next hop group that matches the ECMP table is deleted from the ECMP table.

5. A fault handling method, characterized in that: Applied to any member device in an MLAG system, the MLAG system includes two member devices, the member devices are communicatively connected via a peer link, and the MLAG system is also communicatively connected with a network side device; the method includes: Obtaining the link status of the peer link; When the peer link failure is determined according to the link status of the peer link, a peer link failure event is generated according to the slave device identifier corresponding to the slave member device, and the peer link failure event is sent to the network side device, so that the network side device obtains the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier, and updates 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: A network-side device applied to an MLAG system, wherein the MLAG system includes two member devices, and the member devices are connected to each other through a peer-to-peer link communication; the device includes: A receiving module, used for acquiring 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 according to the link state of the peer link, and the peer link failure event includes a slave device identifier of a slave member device in the MLAG system; The receiving module is further used to obtain the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier; An updating 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.

7. A fault handling device, characterized in that: Applicable to any member device in an MLAG system, the MLAG system includes two member devices, the member devices are communicatively connected via a peer link, and the MLAG system is also communicatively connected with a network side device; the device includes: An acquisition module, used to acquire the link status of the peer link; A sending module is used to generate a peer link failure event according to a slave device identifier corresponding to a slave member device when the peer link failure is determined according to 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 obtains the next hop information to be processed from the locally stored ECMP configuration group according to the slave device identifier, and updates 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.

8. A network side device, characterized in that: The method comprises 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 according to any one of claims 1 to 4.

9. A member device, characterized in that: The method comprises 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 of claim 5.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 4 or the method according to claim 5 is implemented.

Images