Link fault handling method, device, Leaf device, and storage medium

Abstract

The embodiments of the present application relate to the field of communication technology and provide a link fault processing method, apparatus, Leaf device, and storage medium. The methods first withdraw a port from the packet sending logic and then DOWN the port at the chip level, thereby switching traffic to the port before DOWNing it, effectively avoiding packet loss. Furthermore, the ports of the Spine device and CE device are processed first, and then the ports of the Leaf device are processed, thereby avoiding packet loss due to time difference between the uplink and downlink links. This significantly improves the performance of addressing packet loss during peer-link failure in MLAG dual-homing VXLAN network scenarios.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a link failure handling method, apparatus, Leaf device, and storage medium. Background Technology

[0002] With the development of computer networks, data traffic in data center networks is increasing, and the requirements for data reliability are also getting higher. Active-active systems have become an increasingly common technology, and MLAG (Multi-chassis Link Aggregation) is one of the protocols that can form an active-active system with two devices.

[0003] like Figure 1 As shown, deploying MLAG between Leaf1 and Leaf2 devices elevates the reliability of services carried by the CE (Customer Edge) device to the device level. The CE device can be a switch or a server. Specifically, Leaf1 and Leaf2 are the two devices forming the MLAG, interconnected via a peer-link. The CE device, acting as a pure Layer 2 access device, connects to the two MLAG devices through an AP (Aggregate Port). The northbound direction of the MLAG connects to the Spine device via VXLAN (Virtual eXtensible Local Area Network).

[0004] In the above scenarios, when the peer-link between Leaf1 and Leaf2 fails, users want to maintain the stability of the system to the greatest extent possible, that is, to minimize or eliminate packet loss in the uplink and downlink. Summary of the Invention

[0005] The purpose of this application is to provide a link failure handling method, apparatus, Leaf device, and storage medium to solve the problem of uplink and downlink packet loss when the peer-link between Leaf1 device and Leaf2 device fails.

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

[0007] In a first aspect, embodiments of this application provide a link failure handling method applied to a slave leaf device in a cross-device link aggregation group (MLAG). The MLAG further includes a master leaf device. The master leaf device and the slave leaf device are connected via a peer-link. The slave leaf device is connected to a third port of a Spine device via a first port and to a fourth port of a CE device via a second port. The method includes:

[0008] When the peer-link fails, a port pre-notification message is sent to the Spine device and the CE device respectively. The port pre-notification message is used to indicate that the third port and the fourth port should be removed from the packet sending logic.

[0009] The system receives response messages from the Spine device and the CE device respectively, and removes the first port and the second port from the packet sending logic.

[0010] Port negotiation messages are sent to the Spine device and the CE device respectively, and the port negotiation messages are used to indicate that the third port and the fourth port are set to the DOWN state;

[0011] Set the first port and the second port to the DOWN state.

[0012] Optionally, after receiving the response messages returned by the Spine device and the CE device respectively, and removing the first port and the second port from the packet sending logic, and before sending the port negotiation message to the Spine device and the CE device respectively, the method further includes:

[0013] Confirm that both the first port and the second port have exited the packet sending logic.

[0014] Optionally, the first port of the Leaf device is connected to the third port of the Spine device via a VXLAN tunnel, and both the Leaf device and the Spine device include an aggregation module and a VXLAN module;

[0015] When a peer-link failure occurs, the step of sending a port pre-notification message to the Spine device includes:

[0016] When the peer-link fails, the aggregation module of the Leaf device sends the port pre-notification message to the aggregation module of the Spine device, so that the aggregation module of the Spine device notifies the VXLAN module of the Spine device to remove the third port from the packet sending logic.

[0017] The step of receiving the response message returned by the Spine device and removing the first port from the packet sending logic includes:

[0018] The aggregation module of the Leaf device receives the response message returned by the aggregation module of the Spine device, and notifies the VXLAN module of the Leaf device to remove the first port from the packet sending logic;

[0019] The step of sending a port negotiation message to the Spine device includes:

[0020] The port negotiation message is sent from the aggregation module of the Leaf device to the aggregation module of the Spine device, so that the aggregation module of the Spine device sets the third port to the DOWN state.

[0021] The step of setting the first port to a DOWN state includes:

[0022] The aggregation module from the Leaf device sets the first port to a DOWN state.

[0023] Optionally, both the Leaf device and the CE device include a convergence module;

[0024] When a peer-link failure occurs, the step of sending a port pre-notification message to the CE device includes:

[0025] When the peer-link fails, the aggregation module of the Leaf device sends the port pre-notification message to the aggregation module of the CE device, so that the aggregation module of the CE device will remove the fourth port from the packet sending logic.

[0026] The step of receiving the response message returned by the CE device and removing the second port from the packet sending logic includes:

[0027] The second port is removed from the packet sending logic after receiving the response message returned by the aggregation module of the CE device from the aggregation module of the Leaf device.

[0028] The step of sending a port negotiation message to the CE device includes:

[0029] The aggregation module of the Leaf device sends the port negotiation message to the aggregation module of the CE device, so that the aggregation module of the CE device sets the fourth port to the DOWN state;

[0030] The steps to set the second port to a DOWN state include:

[0031] The aggregation module from the Leaf device sets the second port to a DOWN state.

[0032] Optionally, there are multiple CE devices and multiple second ports, and the multiple second ports of the Leaf device are connected one-to-one with the fourth ports of the multiple CE devices;

[0033] The step of receiving the response message returned by the CE device and removing the second port from the packet sending logic includes:

[0034] Upon receiving the response message returned by each of the CE devices, the second port associated with the fourth port of each CE device will be simultaneously removed from the packet sending logic.

[0035] Optionally, after the step of sending port pre-notification messages to the Spine device and the CE device respectively when the peer-link link fails, the method further includes:

[0036] A timeout mechanism is triggered after the port pre-notification message is sent to the Spine device and the CE device.

[0037] If the response message is not received from the Spine device within the set time, the step of sending the port negotiation message to the Spine device is executed directly.

[0038] If the response message is not received from the CE device within the set time period, the step of sending the port negotiation message to the CE device is executed directly.

[0039] Secondly, embodiments of this application also provide a link failure handling device, applied to a slave Leaf device in a cross-device link aggregation group (MLAG). The MLAG further includes a master Leaf device. The master Leaf device and the slave Leaf device are connected via a peer-link. The slave Leaf device is connected to a third port of a Spine device via a first port and to a fourth port of a CE device via a second port. The device includes an aggregation module.

[0040] The aggregation module is used to send port pre-notification messages to the Spine device and the CE device respectively when the peer-link link fails. The port pre-notification messages are used to indicate that the third port and the fourth port should be removed from the packet sending logic.

[0041] The aggregation module is also used to receive response messages returned by the Spine device and the CE device respectively, and to remove the first port and the second port from the packet sending logic;

[0042] The aggregation module is also used to send port negotiation messages to the Spine device and the CE device respectively, and the port negotiation messages are used to indicate that the third port and the fourth port are set to the DOWN state;

[0043] The aggregation module is also used to set the first port and the second port to a DOWN state.

[0044] Optionally, the aggregation module is further configured to confirm that both the first port and the second port have exited the packet sending logic.

[0045] Thirdly, embodiments of this application also provide a Leaf device, including a processor and a memory, wherein the memory is used to store a program, and the processor is used to implement the link failure handling method in the first aspect above when executing the program.

[0046] Fourthly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the link failure handling method described in the first aspect above.

[0047] Compared to existing technologies, the present application provides a link failure handling method, apparatus, Leaf device, and storage medium. When the Leaf device in the MLAG detects a peer-link failure, it first sends port pre-notification messages to the Spine device and CE device respectively, instructing the third and fourth ports to be removed from the packet sending logic. Then, upon receiving the response messages returned by the Spine device and CE device respectively, it removes the first and second ports from the packet sending logic. Finally, it sends port negotiation messages to the Spine device and CE device respectively, instructing the third and fourth ports to be set to the DOWN state, and then sets the first and second ports to the DOWN state. In other words, on the one hand, the port DOWN logic is split into two parts: PRE_DOWN and DOWN. The port is first removed from the packet sending logic, and then the port is DOWN at the chip level. This achieves the goal of switching the traffic to a different port before DOWN, which can effectively avoid packet loss. On the other hand, the ports of the Spine and CE devices are processed first, and then the ports of the Leaf device are processed, avoiding packet loss due to time differences between uplink and downlink. This significantly improves the performance of packet loss when the peer-link fails in MLAG dual-homed access VXLAN network scenarios. Attached Figure Description

[0048] Figure 1 This illustration shows a schematic diagram of an MLAG application scenario provided by an embodiment of this application. Figure 1 .

[0049] Figure 2 This paper illustrates a flowchart of a link failure handling method provided in an embodiment of this application. Figure 1 .

[0050] Figure 3 This paper illustrates a flowchart of a link failure handling method provided in an embodiment of this application. Figure 2 .

[0051] Figure 4 The diagram illustrates the signaling interaction of a link failure handling method provided in an embodiment of this application.

[0052] Figure 5 This illustration shows a schematic diagram of an MLAG application scenario provided by an embodiment of this application. Figure 2 .

[0053] Figure 6 A block diagram of a link failure handling device provided in an embodiment of this application is shown.

[0054] Figure 7 A block diagram of a Leaf device provided in an embodiment of this application is shown.

[0055] Icons: 100-Link fault handling device; 101-Aggregation module; 102-VXLAN module; 10-Leaf device; 11-Processor; 12-Memory; 13-Bus. Detailed Implementation

[0056] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0057] like Figure 1 As shown, in the MLAG dual-homed access VXLAN network scenario, Leaf1 is the master Leaf device in the MLAG, and Leaf2 is the slave Leaf device in the MLAG. Leaf1 and Leaf2 are connected via a peer-link. Leaf2 is connected to the third port (port 3) of the Spine device through its first port (port 1), and to the fourth port (port 4) of the CE device through its second port (port 2).

[0058] When the peer-link between Leaf1 and Leaf2 fails, Leaf1 and Leaf2 cannot forward traffic simultaneously. If they do, problems such as broadcast storms and MAC drift will occur. Therefore, Leaf2 needs to set all physical interfaces except the peer-link port, stacking port, and management port to the DOWN state so that traffic is forwarded only from Leaf1.

[0059] In other words, when the peer-link fails, the MLAG protocol on the Leaf2 device needs to drop ports 1 and 2 according to the existing mechanism.

[0060] However, if port 1 of the Leaf2 device goes down, the Spine device may still send packets to the Leaf2 device through port 3, causing packet loss on port 1 of the Leaf2 device. Similarly, if port 2 of the Leaf2 device goes down, the CE device may still send packets to the Leaf2 device through port 4, causing packet loss on port 2 of the Leaf2 device.

[0061] In summary, due to the time difference between port 1 DOWN and port 3 DOWN, and similarly, the time difference between port 2 DOWN and port 4 DOWN, there is a small amount of packet loss in uplink traffic (port 4 → port 2) and a small amount of packet loss in downlink traffic (port 3 → port 1).

[0062] In existing technologies, a fast port down mechanism is used. Taking ports 1 and 3 as examples, when port 1 of Leaf2 device down, LACP (Link Aggregation Control Protocol) is sent immediately to trigger port 3 down of the peer device SPNE1, so that the time interval between port 3 and port 1 down is small, thereby reducing packet loss to less than 50ms. However, packet loss still exists between port 3 and port 1, and between port 4 and port 2.

[0063] Therefore, to address the packet loss issue caused by the time difference between port 1 DOWN and port 3 DOWN, and the time difference between port 2 DOWN and port 4 DOWN, this application embodiment splits the port DOWN logic into two parts: PRE_DOWN and DOWN. First, the port is removed from the packet transmission logic, and then the port is DOWN at the chip level. In this way, the traffic is switched to a different port before being DOWN, which can effectively avoid packet loss. At the same time, the ports of the Spine device and CE device are processed first, and then the ports of the Leaf device are processed, avoiding packet loss due to the time difference between uplink and downlink. This significantly improves the performance of packet loss when the peer-link fails in the MLAG dual-homed access VXLAN network scenario.

[0064] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0065] The CE device in this embodiment can be a switch or a server. The following embodiment uses a switch as an example for illustration.

[0066] Please refer to Figure 2 , Figure 2This illustration shows a flowchart of a link failure handling method provided in an embodiment of this application. This link failure handling method is applied to… Figure 1 The Leaf2 device in the middle may include the following steps:

[0067] S101, when the peer_link fails, a port pre-notification message is sent to the Spine device and the CE device. The port pre-notification message is used to indicate that the third port and the fourth port will be removed from the packet sending logic.

[0068] In this embodiment, when the peer link fails, the Leaf2 device sends port pre-notification messages to the Spine device and the CE device through port 1 and port 2, respectively. The port pre-notification message sent to the Spine device is used to instruct the Spine device to remove port 3 from the packet transmission logic, and the port pre-notification message sent to the CE device is used to instruct the CE device to remove port 4 from the packet transmission logic.

[0069] S103 receives response messages from the Spine device and the CE device respectively, and removes the first port and the second port from the packet sending logic.

[0070] In this embodiment, the Leaf2 device receives the response message returned by the Spine device and exits port 1 from the packet sending logic; the Leaf2 device receives the response message returned by the CE device and exits port 2 from the packet sending logic.

[0071] S105 sends port negotiation messages to the Spine device and the CE device respectively. The port negotiation messages are used to indicate that the third port and the fourth port should be set to the DOWN state.

[0072] In this embodiment, after receiving the response message from the Spine device and removing port 1 from the packet sending logic, the Leaf2 device sends a port negotiation message to the Spine device, which instructs the Spine device to set port 3 to the DOWN state. Similarly, after receiving the response message from the CE device and removing port 2 from the packet sending logic, the Leaf2 device sends a port negotiation message to the CE device, which instructs the CE device to set port 4 to the DOWN state.

[0073] S107, set the first port and the second port to the DOWN state.

[0074] In this embodiment, after receiving the port pre-notification message sent by the Leaf2 device, the Spine device removes port 3 from the packet sending logic and then returns an acknowledgment message to the Leaf2 device. After receiving the acknowledgment message, the Leaf2 device removes port 1 from the packet sending logic.

[0075] After exiting the packet sending logic on port 1, the Leaf2 device sends a port negotiation message to the Spine device. After receiving the port negotiation message, the Spine device downloads port 3 and then returns an acknowledgment message to the Leaf2 device. After receiving the acknowledgment message, the Leaf2 device downloads port 1.

[0076] In this embodiment, when the peer link fails, the Leaf2 device first notifies the Spine device to remove port 3 from the packet transmission logic, and then removes its own port 1 from the packet transmission logic. Afterwards, the Leaf2 device first notifies the Spine device to download port 3, and then downloads its own port 1. By processing port 3 of the Spine device first, and then processing port 1 of the Leaf2 device, and by switching traffic before downloading the ports, the problem of packet loss in downlink traffic (port 3 → port 1) can be avoided.

[0077] In this embodiment, after receiving the port pre-notification message sent by the Leaf2 device, the CE device exits port 4 from the packet sending logic and then returns a response message to the Leaf2 device. After receiving the response message, the Leaf2 device exits port 2 from the packet sending logic.

[0078] After exiting the packet sending logic on port 2, the Leaf2 device sends a port negotiation message to the CE device. After receiving the port negotiation message, the CE device downloads port 4 and then returns a response message to the Leaf2 device. After receiving the response message, the Leaf2 device downloads port 2.

[0079] In this embodiment, when the peer link fails, the Leaf2 device first notifies the CE device to remove port 4 from the packet transmission logic, and then removes its own port 2 from the packet transmission logic. Afterwards, the Leaf2 device first notifies the CE device to down port 4, and then down its own port 2. Thus, by processing the CE device's port 4 first, and then processing the Leaf2 device's port 2, and by switching traffic before downloading the ports, the problem of packet loss in the uplink traffic (port 4 → port 2) can be avoided.

[0080] As described above, when a peer-link failure occurs, for downlink traffic (port 3 → port 1), the Leaf2 device first notifies the Spine device to remove port 3 from the packet transmission logic, and then removes its own port 1 from the packet transmission logic. After completing the port switchover, the Leaf2 device first notifies the Spine device to download port 3, and then downloads its own port 1, thus effectively preventing downlink packet loss. For uplink traffic (port 4 → port 2), the Leaf2 device first notifies the CE device to remove port 4 from the packet transmission logic, and then removes its own port 2 from the packet transmission logic. After completing the port switchover, the Leaf2 device first notifies the CE device to download port 4, and then downloads its own port 2, thus effectively preventing uplink packet loss.

[0081] In one possible scenario, such as Figure 1 As shown, besides the time difference between port 1 down and port 3 down, and between port 2 down and port 4 down, the time difference between port 3 and port 4 down may also exist due to device differences, resulting in a small amount of packet loss in both upstream (port 4 → port 2 → port 1 → port 3) and downstream (port 3 → port 1 → port 2 → port 4) traffic. Clearly, the existing fast port down mechanism cannot mitigate the packet loss caused by the time difference between port 3 and port 4 down.

[0082] To address the packet loss issue caused by the time difference between port 3 and port 4 being down, this embodiment of the application can, after confirming that both port 3 of the Spine device and port 4 of the CE device have exited the packet transmission logic, instruct the Spine device to set port 3 to the down state and instruct the CE device to set port 4 to the down state. In this way, by downloading the ports only when neither port 3 of the Spine device nor port 4 of the CE device is transmitting packets, packet loss caused by the time difference between port 3 and port 4 being down can be effectively avoided.

[0083] Therefore, in Figure 2 Based on this, please refer to Figure 3 After step S103 and before step S105, the link fault handling method for Leaf2 devices provided in this application embodiment may further include step S104.

[0084] S104, confirm that both the first port and the second port have exited the packet sending logic.

[0085] In this embodiment, when the peer_link fails, the Leaf2 device sends port pre-notification messages to the Spine device and the CE device through port 1 and port 2 respectively, to instruct the Spine device to exit the packet transmission logic with port 3 and to instruct the CE device to exit the packet transmission logic with port 4. Then, after receiving the response message returned by the Spine device, it exits the packet transmission logic with port 1, and after receiving the response message returned by the CE device, it exits the packet transmission logic with port 2.

[0086] After ports 1 and 2 have both exited packet transmission logic, it is confirmed that port 3 of the Spine device and port 4 of the CE device are no longer transmitting packets. At this point, a port negotiation message is sent to both the Spine and CE devices. Upon receiving the port negotiation message, the Spine device downloads port 3 and returns a response message to the Leaf2 device. Upon receiving the port negotiation message, the CE device downloads port 4 and returns a response message to the Leaf2 device. After receiving the response messages from the Spine and CE devices, the Leaf2 device confirms that both devices have downloaded their ports, and then downloads its own ports 1 and 2.

[0087] Thus, when the peer link fails, the Leaf2 device first notifies the Spine device to remove port 3 from the packet transmission logic, and the CE device to remove port 4 from the packet transmission logic. Then, it removes its own ports 1 and 2 from the packet transmission logic. After confirming that both the Spine and CE devices have completed the port switching of traffic and will no longer transmit packets, it first notifies the Spine device to download port 3, the CE device to download port 4, and then it downloads its own ports 1 and 2. This not only avoids packet loss in downlink traffic (port 3 → port 1) and uplink traffic (port 4 → port 2), but also avoids packet loss in uplink traffic (port 4 → port 2 → port 1 → port 3) and downlink traffic (port 3 → port 1 → port 2 → port 4).

[0088] As described above, compared to existing port fast DOWN mechanisms, this embodiment of the application splits the port DOWN logic into two parts: PRE_DOWN and DOWN. For the PRE_DOWN part, an aggregation module (also called a LAC module) needs to be set up on the Leaf2 device, Spine device, and CE device. Simultaneously, port pre-notification messages and response messages are added by modifying the last two reserved fields of the LAC protocol to achieve port switching of traffic. The aggregation module provides an interface for sending messages from a specified aggregation port and can receive and process port pre-notification messages and response messages. A detailed description follows.

[0089] In one possible implementation, such as Figure 1As shown, for the Spine device, the first port (port 1) of the Leaf2 device is connected to the third port (port 3) of the Spine device via a VXLAN tunnel. Both the Spine device and the Leaf2 device include an aggregation module and a VXLAN module. Please refer to... Figure 4 The link failure handling process is as follows:

[0090] S1. When the aggregation module of the Leaf2 device detects a peer_link failure, it sends a port pre-notification message to the aggregation module of the Spine device.

[0091] After receiving the port pre-notification message, the aggregation module of the Spine device announces the notification event for port 3. The VXLAN module of the Spine device responds to the notification event and removes port 3 from the packet sending logic. Afterwards, the aggregation module of the Spine device returns a response message to the aggregation module of the Leaf2 device.

[0092] After receiving the response message, the aggregation module of the S22 and Leaf2 devices announces the notification event for port 1. The VXLAN module of the Leaf2 device responds to the notification event and removes port 1 from the packet sending logic.

[0093] The aggregation modules of S23 and Leaf2 devices send port negotiation messages to the aggregation modules of Spine devices;

[0094] After receiving the port negotiation message, the aggregation module of the S24 and Spine devices will 3-DOWN the port and then return a response message to the aggregation module of the Leaf2 devices.

[0095] After receiving the response message, the aggregation module of devices S4 and Leaf2 will DOWN port 1.

[0096] In another possible implementation, such as Figure 1 As shown, for the CE device, the second port (port 2) of the Leaf2 device is connected to the fourth port (port 4) of the CE device. Both the CE device and the Leaf2 device include an aggregation module. Therefore, please refer to... Figure 4 The link failure handling process is as follows:

[0097] S1. When the aggregation module of the Leaf2 device detects a peer_link failure, it sends a port pre-notification message to the aggregation module of the CE device.

[0098] After receiving the port pre-notification message, the aggregation module of the S31 and CE devices will remove port 4 from the packet sending logic and then return a response message to the aggregation module of the Leaf2 devices.

[0099] After receiving the response message, the aggregation module of the S32 and Leaf2 devices will exit port 2 from the packet sending logic;

[0100] The aggregation modules of S33 and Leaf2 devices send port negotiation messages to the aggregation module of the CE device;

[0101] After receiving the port negotiation message, the aggregation module of the S34 and CE devices will DOWN port 4 and then return a DOWN response message to the aggregation module of the Leaf2 devices.

[0102] After receiving the response message, the aggregation module of devices S4 and Leaf2 will DOWN port 2.

[0103] The above process is Figure 2 The underlying implementation of the link failure handling method shown is for... Figure 3 The underlying implementation of the link failure handling method shown is as follows: Figure 4 As shown, after S22 and S32, there is also Sa, that is, after confirming that both port 1 and port 2 have exited the packet sending logic, the aggregation module of the Leaf2 device sends a port negotiation message to the aggregation modules of the Spine device and the CE device. After that, the aggregation module of the Leaf2 device will then drop port 1 and port 2.

[0104] In practice, such as Figure 5 As shown, there may be multiple CE devices. The multiple second ports (port 2) of the Leaf2 device are connected one-to-one with the fourth ports (port 4) of the multiple CE devices. In this case, the multiple second ports can be managed as a group.

[0105] Therefore, for this scenario, the process of receiving the response message returned by the CE device and removing the second port from the packet sending logic in step S103 can include:

[0106] After receiving the response message from each CE device, the second port associated with the fourth port of each CE device will be simultaneously removed from the packet sending logic.

[0107] That is, such as Figure 5 As shown, when the peer_link fails, the Leaf2 device simultaneously sends port pre-notification messages to each CE device through each port 2, instructing each CE device to withdraw its respective port 4 from the packet sending logic. Afterwards, the Leaf2 device will receive response messages from each CE device. After confirming that it has received the response message from each CE device, it will withdraw all ports 4 from the packet sending logic at the same time. In this way, unified management of multiple second ports is achieved.

[0108] In this embodiment, for scenarios where ports 3 of the Spine device and port 4 of the CE device no longer send packets and ports are then down, and for unified management of multiple second ports, the Leaf2 device may also include a registration module (also known as the MLAG module).

[0109] For scenarios where ports are down when neither port 3 of the Spine device nor port 4 of the CE device are sending packets, combined with... Figure 4 After receiving the response message from the Spine device or the CE device, the aggregation module of the Leaf2 device will notify the registration module of the response message. After confirming that it has received the response message from the Spine device and the CE device, the registration module will then trigger the aggregation module of the Leaf2 device to send a port negotiation message to the Spine device and the CE device.

[0110] For scenarios requiring unified management of multiple secondary ports, combined with... Figure 4 After receiving the response message from the CE device, the aggregation module of the Leaf2 device will notify the registration module of the response message. After confirming that it has received the response message from each CE device, the registration module will trigger the aggregation module to simultaneously exit all port 4 from the packet sending logic.

[0111] In one possible scenario, the Spine device and CE device may not support the PRE_DOWN function, causing the Leaf2 device to remain in a state of waiting for a response message. Therefore, this embodiment adds a timeout mechanism for sending port pre-notification messages to the Spine device and CE device. If either the Spine device or the CE device does not support the PRE_DOWN function, the Leaf2 device will directly execute the subsequent DOWN procedure.

[0112] Therefore, after step S101, the link failure handling method provided in this application embodiment further includes steps S10A to S10B.

[0113] S10A triggers a timeout mechanism after sending a port pre-notification message to the Spine device and the CE device.

[0114] S10B detects whether response messages are received from the Spine device and CE device within a set time period.

[0115] If a response message is received from the Spine device within the set time period, the first port is removed from the packet sending logic. Then, a port negotiation message is sent to the Spine device to instruct it to set the third port to the DOWN state, and then the first port to the DOWN state. If no response message is received from the Spine device after the set time period, a port negotiation message is directly sent to the Spine device to instruct it to set the third port to the DOWN state, and then the first port to the DOWN state.

[0116] If a response message is received from the CE device within the set time period, the second port is removed from the packet sending logic. Then, a port negotiation message is sent to the CE device to instruct it to set the fourth port to the DOWN state, and then the second port to the DOWN state. If no response message is received from the CE device after the set time period, a port negotiation message is directly sent to the CE device to instruct it to set the fourth port to the DOWN state, and then the second port to the DOWN state.

[0117] Compared with the prior art, the embodiments of this application have the following beneficial effects:

[0118] First, to address the packet loss issue caused by the time difference between port 1 DOWN and port 3 DOWN, and the time difference between port 2 DOWN and port 4 DOWN, the port DOWN logic is split into two parts: PRE_DOWN and DOWN. The port is first removed from the packet sending logic, and then the port is DOWN at the chip level. In this way, the traffic is switched to a different port before being DOWN, which can effectively avoid packet loss. At the same time, the ports of the Spine device and CE device are processed first, and then the ports of the Leaf2 device are processed, which avoids packet loss due to the time difference between uplink and downlink.

[0119] Secondly, regarding the packet loss issue caused by the time difference between port 3 and port 4 being down, after confirming that both port 3 of the Spine device and port 4 of the CE device have exited the packet transmission logic, the Spine device is instructed to set port 3 and port 4 of the CE device to the down state. In this way, down the ports when neither port 3 of the Spine device nor port 4 of the CE device is transmitting packets can effectively avoid packet loss caused by the time difference between port 3 and port 4 being down.

[0120] Third, for scenarios with multiple CE devices, after confirming that the response message returned by each CE device has been received, all port 4 is simultaneously removed from the packet sending logic, thus achieving unified management of multiple second ports.

[0121] Fourth, a timeout mechanism is added for sending port pre-notification messages to Spine and CE devices. If the Spine or CE device does not support the PRE_DOWN function, the Leaf2 device will directly execute the subsequent DOWN process to avoid waiting indefinitely.

[0122] Fifth, by extending the LAC protocol messages, new message types are added, namely port pre-notification messages and response messages, thereby associating the port-independent states "DOWN" and "outbound forwarding" in the system, and combining the two into two linked states through the newly added LAC message types.

[0123] Sixth, in order to adapt to the differences between the north and south devices in the MLAG scenario, the forwarding logic of the SPINE device and the CE device is indirectly linked through the two ports of the MLAG device. When neither port 3 of the Spine device nor port 4 of the CE device sends packets, the port is down, thereby achieving zero packet loss when the peer-link link fails.

[0124] In order to perform the corresponding steps in the above method embodiments and various possible implementations, an implementation of a link fault handling device is given below.

[0125] Please refer to Figure 6 , Figure 6 A block diagram of a link failure handling device 100 provided in an embodiment of this application is shown. The link failure handling device 100 is applied to... Figure 1 The Leaf2 device includes aggregation module 101.

[0126] The aggregation module 101 is used to send port pre-notification messages to the Spine device and the CE device respectively when the peer_link fails. The port pre-notification messages are used to indicate that the third port and the fourth port should be removed from the packet sending logic.

[0127] The aggregation module 101 is also used to receive response messages returned by the Spine device and the CE device respectively, and to remove the first port and the second port from the packet sending logic.

[0128] The aggregation module 101 is also used to send port negotiation messages to the Spine device and the CE device respectively. The port negotiation messages are used to indicate that the third port and the fourth port are set to the DOWN state.

[0129] The aggregation module 101 is also used to set the first port and the second port to a DOWN state.

[0130] Optionally, the aggregation module 101 is also used to confirm that both the first port and the second port have exited the packet sending logic.

[0131] Optionally, the first port of the Leaf2 device is connected to the second port of the Spine device via a VXLAN tunnel, and the link failure handling device 100 also includes a VXLAN module 102;

[0132] The aggregation module 101 is also used for,

[0133] When the peer-link fails, a port pre-notification message is sent to the aggregation module of the Spine device so that the aggregation module of the Spine device notifies the VXLAN module 102 of the Spine device to remove the third port from the packet sending logic.

[0134] Receive the response message returned by the aggregation module of the Spine device and notify the VXLAN module 102 to exit the first port from the packet sending logic;

[0135] Send a port negotiation message to the aggregation module of the Spine device so that the aggregation module of the Spine device sets the third port to the DOWN state.

[0136] Set the first port to the DOWN state.

[0137] Optionally, the aggregation module 101 is also used for,

[0138] When the peer-link fails, a pre-notification message is sent to the aggregation module of the CE device so that the aggregation module of the CE device will remove the fourth port from the packet sending logic;

[0139] Receive the response message returned by the aggregation module of the CE device and remove the second port from the packet sending logic;

[0140] Send a port negotiation message to the aggregation module of the CE device so that the aggregation module of the CE device sets the fourth port to the DOWN state.

[0141] Set the second port to the DOWN state.

[0142] Optionally, there are multiple CE devices, and the multiple second ports of the Leaf2 device are connected one-to-one with the fourth ports of the multiple CE devices;

[0143] The aggregation module 101 executes the following methods to remove the second port from the packet sending logic after receiving the response message returned by the CE device:

[0144] After receiving the response message from each CE device, the second port associated with the fourth port of each CE device will be simultaneously removed from the packet sending logic.

[0145] Optionally, the aggregation module 101 is also used for,

[0146] A timeout mechanism is triggered after sending a port pre-notification message to the Spine device and the CE device;

[0147] If no response message is received from the Spine device after the set time, the step of sending a port negotiation message to the Spine device will be executed directly.

[0148] If no response message is received from the CE device within the set time, the step of sending a port negotiation message to the CE device will be executed directly.

[0149] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the link fault handling device 100 described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0150] Please refer to Figure 7 , Figure 7 The diagram shown is a block diagram of the Leaf device 10 provided in an embodiment of this application. The Leaf device 10 is... Figure 1 The Leaf2 device in the middle. The Leaf device 10 includes a processor 11, a memory 12 and a bus 13, with the processor 11 connected to the memory 12 via the bus 13.

[0151] The memory 12 is used to store programs. After receiving an execution instruction, the processor 11 executes the programs to implement the link failure handling method disclosed in the above embodiments.

[0152] The memory 12 may include high-speed random access memory (RAM) or non-volatile memory (NVM).

[0153] Processor 11 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed through integrated logic circuits in the hardware of processor 11 or through software instructions. Processor 11 can be a general-purpose processor, including a Central Processing Unit (CPU), a Microcontroller Unit (MCU), a Complex Programmable Logic Device (CPLD), a Field Programmable Gate Array (FPGA), embedded ARM chips, etc.

[0154] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by the processor 11, implements the link failure handling method disclosed in the above embodiments.

[0155] In summary, the link failure handling method, apparatus, Leaf device, and storage medium provided in this application split the port DOWN logic into two parts: PRE_DOWN and DOWN. First, the port is removed from the packet sending logic, and then the port is DOWN at the chip level. In this way, the traffic is switched to the port before being DOWN, which can effectively avoid packet loss. At the same time, the ports of the Spine device and CE device are processed first, and then the port of the Leaf device is processed, avoiding packet loss due to the time difference between uplink and downlink. Thus, the performance of packet loss during peer-link failure in MLAG dual-homed access VXLAN network scenarios is significantly improved.

[0156] 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 link failure handling method, characterized in that, The method is applied to a slave leaf device in a cross-device link aggregation group (MLAG), wherein the MLAG also includes a master leaf device, the master leaf device and the slave leaf device are connected via a peer-link, and the slave leaf device is connected to a third port of a Spine device via a first port and to a fourth port of a CE device via a second port; the method includes: When the peer-link fails, a port pre-notification message is sent to the Spine device and the CE device respectively. The port pre-notification message is used to indicate that the third port and the fourth port should be removed from the packet sending logic. The system receives response messages from the Spine device and the CE device respectively, and removes the first port and the second port from the packet sending logic. Port negotiation messages are sent to the Spine device and the CE device respectively, and the port negotiation messages are used to indicate that the third port and the fourth port are set to the DOWN state; Set the first port and the second port to the DOWN state.

2. The method as described in claim 1, characterized in that, After receiving the response messages returned by the Spine device and the CE device respectively, and removing the first port and the second port from the packet sending logic, and before sending the port negotiation message to the Spine device and the CE device respectively, the method further includes: Confirm that both the first port and the second port have exited the packet sending logic.

3. The method as described in claim 1, characterized in that, The first port of the Leaf device and the third port of the Spine device are connected via a VXLAN tunnel. Both the Leaf device and the Spine device include an aggregation module and a VXLAN module. When a peer-link failure occurs, the step of sending a port pre-notification message to the Spine device includes: When the peer-link fails, the aggregation module of the Leaf device sends the port pre-notification message to the aggregation module of the Spine device, so that the aggregation module of the Spine device notifies the VXLAN module of the Spine device to remove the third port from the packet sending logic. The step of receiving the response message returned by the Spine device and removing the first port from the packet sending logic includes: The aggregation module of the Leaf device receives the response message returned by the aggregation module of the Spine device, and notifies the VXLAN module of the Leaf device to remove the first port from the packet sending logic; The step of sending a port negotiation message to the Spine device includes: The port negotiation message is sent from the aggregation module of the Leaf device to the aggregation module of the Spine device, so that the aggregation module of the Spine device sets the third port to the DOWN state. The step of setting the first port to a DOWN state includes: The aggregation module from the Leaf device sets the first port to a DOWN state.

4. The method as described in claim 1, characterized in that, Both the Leaf device and the CE device include a convergence module; When a peer-link failure occurs, the step of sending a port pre-notification message to the CE device includes: When the peer-link fails, the aggregation module of the Leaf device sends the port pre-notification message to the aggregation module of the CE device, so that the aggregation module of the CE device will remove the fourth port from the packet sending logic. The step of receiving the response message returned by the CE device and removing the second port from the packet sending logic includes: The second port is removed from the packet sending logic after receiving the response message returned by the aggregation module of the CE device from the aggregation module of the Leaf device. The step of sending a port negotiation message to the CE device includes: The aggregation module of the Leaf device sends the port negotiation message to the aggregation module of the CE device, so that the aggregation module of the CE device sets the fourth port to the DOWN state; The steps to set the second port to a DOWN state include: The aggregation module from the Leaf device sets the second port to a DOWN state.

5. The method as described in claim 4, characterized in that, There are multiple CE devices, multiple second ports, and the multiple second ports of the Leaf device are connected one-to-one with the fourth ports of the multiple CE devices; The step of receiving the response message returned by the CE device and removing the second port from the packet sending logic includes: Upon receiving the response message returned by each of the CE devices, the second port associated with the fourth port of each CE device will be simultaneously removed from the packet sending logic.

6. The method as described in claim 1, characterized in that, After the step of sending port pre-notification messages to the Spine device and the CE device respectively when the peer-link link fails, the method further includes: A timeout mechanism is triggered after the port pre-notification message is sent to the Spine device and the CE device. If the response message is not received from the Spine device within the set time, the step of sending the port negotiation message to the Spine device is executed directly. If the response message is not received from the CE device within the set time period, the step of sending the port negotiation message to the CE device is executed directly.

7. A link fault handling device, characterized in that, A slave leaf device is applied in a cross-device link aggregation group (MLAG), wherein the MLAG also includes a master leaf device. The master leaf device and the slave leaf device are connected via a peer-link. The slave leaf device is connected to the third port of a Spine device via a first port and to the fourth port of a CE device via a second port. The device includes an aggregation module. The aggregation module is used to send port pre-notification messages to the Spine device and the CE device respectively when the peer-link link fails. The port pre-notification messages are used to indicate that the third port and the fourth port should be removed from the packet sending logic. The aggregation module is also used to receive response messages returned by the Spine device and the CE device respectively, and to remove the first port and the second port from the packet sending logic; The aggregation module is also used to send port negotiation messages to the Spine device and the CE device respectively, and the port negotiation messages are used to indicate that the third port and the fourth port are set to the DOWN state; The aggregation module is also used to set the first port and the second port to a DOWN state.

8. The apparatus as claimed in claim 7, characterized in that, The aggregation module is also used to confirm that both the first port and the second port have exited the packet sending logic.

9. A Leaf device, characterized in that, It includes a processor and a memory, the memory being used to store a program, and the processor being used to implement the link failure handling method according to any one of claims 1-6 when executing the program.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the link failure handling method as described in any one of claims 1-6.

Images