WO2019174454A1

WO2019174454A1 - Link recovery method and device, system, storage medium, and electronic device

Info

Publication number: WO2019174454A1
Application number: PCT/CN2019/076064
Authority: WO
Inventors: 郭晓彬; 陈世猛; 龙波; 陈志伟; 夏迎春
Original assignee: 中兴通讯股份有限公司
Priority date: 2018-03-13
Filing date: 2019-02-25
Publication date: 2019-09-19
Also published as: CN110278094A; CN110278094B

Abstract

The present disclosure provides a link recovery method and device, a system, a storage medium, and an electronic device. The method comprises: a first apparatus negotiating with a second apparatus to obtain a predetermined time, the predetermined time being used to characterize the transmission time of a communication link between the first apparatus and the second apparatus; the first apparatus sending to the second apparatus instruction information for recovering the communication link, and in a predetermined time after sending the instruction information, the first apparatus recovering the communication link. The present disclosure solves the technical problem in the related art of excessive packet loss during the recovery of a communication link between apparatuses.

Description

Link recovery method and device, system, storage medium, electronic device

Technical field

The present disclosure relates to the field of communications, and in particular to a link recovery method and apparatus, system, storage medium, and electronic device.

Background technique

With the rapid development of computer and network technologies and the emergence of various network applications, the stability of basic data communication networks is becoming more and more important. To increase the bandwidth and implement the link transmission flexibility and redundancy, the connections between the switches are generally aggregated to implement the load balancing of the inbound and outbound traffic of each member interface. The status of the aggregation member is up and down. The port is in the state of down to up, which is called the Link Aggregation Control Protocol (LACP) recovery state. In this case, you need to quickly add the local port to the aggregation group, so that the aggregation link can be quickly involved. Traffic load sharing.

Aggregation functionality in the related art As a data center technology, requests from clients can be distributed to two or more servers. The problem in the related art is that a large number of packet loss does not occur during the link fault recovery process. The reason is that the two devices run dynamic lacp. After the port is up, each link performs the lacp protocol interaction without affecting each other. After the negotiation between the two ends is successful, the platform module sends the information of the activated aggregation group member to the driver module. The platform module cannot guarantee that the aggregation group member information is sent between the two devices at the same time. Secondly, the process of sending the aggregation member information from the platform module to the driver module can delay the error, which leads to the underlying aggregation group of the two devices. If the member entry is not updated at the same time, the member of the aggregation group is added to the aggregation group. The time is the same. The more the traffic is delivered to the port, the traffic will be delivered to the other port, and the traffic will reach the other end. The other end is deactivated because the port is in the block state. As for a large number of packet loss, the packet loss time is the same as the time when the two groups join the aggregation group.

In view of the above problems in the related art, no effective solution has been found yet.

Summary of the invention

Embodiments of the present disclosure provide a link recovery method and device, system, storage medium, and electronic device.

According to an embodiment of the present disclosure, a link recovery method is provided, including: a first device negotiates with a second device to obtain a predetermined time, wherein the predetermined time is used to characterize the first device and the second a transmission time of a communication link between the devices; the first device transmitting, to the second device, indication information for restoring the communication link, the predetermined time after transmitting the indication information, the The first device resumes the communication link.

According to an embodiment of the present disclosure, another link recovery method is provided, including: a second device negotiates with a first device to obtain a predetermined time, wherein the predetermined time is used to characterize the first device and the first The transmission time of the communication link between the two devices; the second device receives the indication information sent by the first device for recovering the communication link; after receiving the indication information, the second device is configured according to the The indication information recovers the communication link.

According to another embodiment of the present disclosure, there is provided a link recovery apparatus, applied to a first device, comprising: a negotiation module, configured to negotiate with a second device to obtain a predetermined time, wherein the predetermined time is used to represent the location a transmission time of a communication link between the first device and the second device; a sending module configured to send indication information for restoring the communication link to the second device; and a recovery module configured to be The communication link is resumed at the predetermined time after the indication information is transmitted.

According to another embodiment of the present disclosure, another link recovery apparatus is provided, which is applied to a second device, including: a negotiation module, configured to negotiate with a first device to obtain a predetermined time, wherein the predetermined time is used for characterization a transmission time of the communication link between the first device and the second device; a receiving module configured to receive indication information sent by the first device for recovering the communication link; and a recovery module configured to be After receiving the indication information, the communication link is restored according to the indication information.

According to still another embodiment of the present disclosure, a link recovery system includes a first device and a second device, where the first device includes: a first negotiation module, configured to negotiate with a second device to obtain a predetermined time, The predetermined time is used to represent a transmission time of a communication link between the first device and the second device, and the sending module is configured to send to the second device to recover the communication link. The first recovery module is configured to restore the communication link at the predetermined time after transmitting the indication information; the second device includes: a second negotiation module, configured to negotiate with the first device Obtaining the predetermined time; the receiving module is configured to receive the indication information sent by the first device for recovering the communication link; and the second recovery module is configured to: after receiving the indication information, according to the indication information Restore the communication link.

According to still another embodiment of the present disclosure, there is also provided a storage medium having stored therein a computer program, wherein the computer program is configured to perform the steps of any one of the method embodiments described above at runtime.

According to still another embodiment of the present disclosure, there is also provided an electronic device comprising a memory and a processor, wherein the memory stores a computer program, the processor being configured to execute the computer program to perform any of the above The steps in the method embodiments.

Through the present disclosure, the first device resumes the communication link at a predetermined time after transmitting the indication information for restoring the communication link to the second device, considering that the first device detects the packet delay time between the second device and the second device, The first device and the second device can recover the communication link at the same time, and solve the technical problem that the packet loss is excessive when the communication link is restored between the devices in the related art, and the traffic loss during the fault recovery is reduced.

DRAWINGS

The drawings described herein are provided to provide a further understanding of the present disclosure, which is a part of the present disclosure, and the description of the present disclosure and the description thereof are not intended to limit the disclosure. In the drawing:

1 is a network architecture diagram of an embodiment of the present disclosure;

2 is a flowchart of a link recovery method according to an embodiment of the present disclosure;

FIG. 3 is a structural block diagram of a link recovery apparatus according to an embodiment of the present disclosure; FIG.

4 is a structural block diagram of another link recovery apparatus according to an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a method for implementing fast convergence of an aggregation port in a link recovery process based on a custom negotiation mechanism according to an embodiment;

FIG. 6 is a system diagram of implementing fast convergence of an aggregation port in a link recovery process based on a custom negotiation mechanism according to the embodiment;

7 is a schematic diagram of network load sharing in this embodiment;

FIG. 8 is a schematic diagram of network load sharing when a 3 link fails in the embodiment;

FIG. 9 is a schematic diagram of network load sharing when a vsc link fails in this embodiment;

FIG. 10 is a schematic diagram of a message format of this embodiment.

detailed description

The present disclosure will be described in detail below with reference to the drawings in conjunction with the embodiments. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict.

It is to be understood that the terms "first", "second", and the like in the specification and claims of the present disclosure are used to distinguish similar objects, and are not necessarily used to describe a particular order or order.

Example 1

The embodiment of the present application can be run on the network architecture shown in FIG. 1. FIG. 1 is a network architecture diagram of an embodiment of the present disclosure. As shown in FIG. 1 , the network architecture includes: a first device, a second device, where A device interacts with the second device through an aggregated link.

In this embodiment, a link recovery method running on the network architecture is provided. FIG. 2 is a flowchart of a link recovery method according to an embodiment of the present disclosure. As shown in FIG. 2, the process includes the following steps. :

Step S202, the first device negotiates with the second device to obtain a predetermined time, where the predetermined time is used to represent a transmission time of the communication link between the first device and the second device;

Step S204: The first device sends, to the second device, indication information for recovering the communication link.

Step S206, the first device resumes the communication link at a predetermined time after transmitting the indication information.

In this embodiment, a link recovery method running on the network architecture is also provided. As shown in FIG. 2, the process includes the following steps:

Step S302, the second device negotiates with the first device to obtain a predetermined time, where the predetermined time is used to represent a transmission time of the communication link between the first device and the second device;

Step S304, the second device receives the indication information that is sent by the first device and is used to restore the communication link.

Step S306, after receiving the indication information, the second device resumes the communication link according to the indication information.

Through the above steps, the first device resumes the communication link at a predetermined time after transmitting the indication information for restoring the communication link to the second device, and considers that the first device detects the packet delay time between the second device and the second device, The first device and the second device can recover the communication link at the same time, and solve the technical problem that the packet loss is excessive when the communication link is restored between the devices in the related art, and the traffic loss during the fault recovery is reduced.

Optionally, the first device of the foregoing step may be an entity, a software, a server, a routing device, etc., but is not limited thereto.

Optionally, before the first device sends the indication information to the second device, the method further includes: determining, by the first device, the communication link with the second device. Before the first device determines to restore the communication link with the second device, the method further includes: the first device receiving the link aggregation control protocol LACP packet, where the LACP packet is used to represent the communication by the LACP packet The link is smooth.

Optionally, the determining, by the first device, the communication link between the second device and the second device includes: determining, by the first device, whether the LACP packet is from a port of the communication link; and the communication link includes two ports, respectively, on the first device side On the second device side, the first device may receive the LACP packet from the port on the first device side; if the LACP packet is determined to be from the port of the communication link, the communication link through which the LACP packet passes is unobstructed. Specifically, the communication link between the first device and the second device is unobstructed, and the first device determines to restore the communication link with the second device.

Optionally, before the first device negotiates with the second device to obtain the predetermined time, the method further includes: the first device detecting a packet delay time between the second device and the second device, wherein the predetermined time is greater than or equal to the packet delay time.

In an optional example, the predetermined time is half of the packet delay time for fully considering the transmission time of the indication information to the second device. Of course, it may be other time, for example, the time when the second device response indication information has been received from the receipt of the indication information to the completion of the recovery link. In this embodiment, the delay time of sending and receiving packets is that the time from the first device to the second device is received, and the time from the second device to the first device may of course be characterized by other transmission time.

Optionally, the first device recovering the communication link includes: the first device adds the communication link to the LACP aggregation group, where the member in the LACP aggregation group is used to transmit data between the first device and the second device. After the first device resumes the communication link, the method further includes: the first device interacting with the second device via the communication link.

In this embodiment, the detecting, by the first device, the delay time of sending and receiving packets with the second device includes:

S11. The first device sends a request message for detecting a link delay to the second device.

S12. The first device receives a response message that is sent by the second device according to the request packet.

S13. The first device calculates a delay time of sending and receiving packets according to a difference between a receiving time of the response message and a sending time of the request message. That is, the receiving and receiving time is subtracted from the sending time to obtain the packet delay time. When the response packet carries the timestamp of the request packet received by the first device, the delay time of the packet transmission and reception time may be calculated by using the timestamp and the transmission time of the request packet, and the calculated delay time of the transceiver packet is calculated. Half of the above example.

Optionally, the request packet carries the first packet sequence number, and the response packet carries the second packet sequence number, wherein the first packet sequence number corresponds to the second packet sequence number. The first device may periodically send the request packet, and after receiving the multiple request packets, the first device may also feed back multiple response packets, and the request packet and the response packet corresponding to the sequence number can ensure the delay of sending and receiving packets. The accuracy.

Optionally, the second device recovers the communication link according to the indication information, where the second device adds the communication link to the link aggregation control protocol LACP aggregation group, where the members in the LACP aggregation group are used to transmit the first device and the first device. Data between two devices. After the second device resumes the communication link according to the indication information, the method further includes: the second device interacting with the first device to exchange traffic data through the communication link.

Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware, but in many cases, the former is A better implementation. Based on such understanding, portions of the technical solutions of the present disclosure that contribute substantially or to the prior art may be embodied in the form of a software product stored in a storage medium (eg, ROM/RAM, disk, The optical disc includes a number of instructions for causing a terminal device (which may be a cell phone, a computer, a server, or a network device, etc.) to perform the methods described in various embodiments of the present disclosure.

Example 2

In the embodiment, a link recovery device and a system are provided, which are used to implement the foregoing embodiments and preferred embodiments, and are not described again. As used below, the term "module" may implement a combination of software and/or hardware of a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.

FIG. 3 is a structural block diagram of a link recovery apparatus according to an embodiment of the present disclosure. As shown in FIG. 3, the apparatus is applied to a first device, where the apparatus includes:

The negotiation module 30 is configured to negotiate with the second device to obtain a predetermined time, where the predetermined time is used to represent a transmission time of the communication link between the first device and the second device;

The sending module 32 is configured to send, to the second device, indication information for recovering the communication link;

The recovery module 34 is arranged to resume the communication link a predetermined time after transmitting the indication information.

FIG. 4 is a structural block diagram of another link recovery apparatus according to an embodiment of the present disclosure. As shown in FIG. 4, the apparatus is applied to a second device, where the apparatus includes:

The negotiation module 40 is configured to negotiate with the first device to obtain a predetermined time, where the predetermined time is used to represent a transmission time of the communication link between the first device and the second device;

The receiving module 42 is configured to receive indication information that is sent by the first device and used to restore the communication link.

The recovery module 44 is configured to resume the communication link according to the indication information after receiving the indication information.

This embodiment further provides a link recovery system, including the first device shown in FIG. 3 and the second device shown in FIG. 4. The operational steps in the optional example in the above embodiment 1 can also be implemented in the first device or the second device by means of a module or a unit.

It should be noted that each of the above modules may be implemented by software or hardware. For the latter, the foregoing may be implemented by, but not limited to, the foregoing modules are all located in the same processor; or, the above modules are in any combination. The forms are located in different processors.

Example 3

This embodiment is used to compensate and detail the solution of the present application:

The present embodiment provides a method and system for implementing fast convergence of an aggregation port in a link recovery process based on a custom negotiation mechanism, which can ensure that data packets between the network and the network are restored when the aggregation group member links are restored. You can quickly and evenly share the ports of all aggregation group members to reduce the packet loss rate.

A method and system for implementing fast convergence of an aggregation port in a link recovery process based on a custom protocol, and setting a physical device (such as the first device and the second device in the foregoing embodiment) in the network. Aggregation group member list. The aggregation group member list stores all member information of the aggregation group.

The method of the embodiment includes: when the aggregation link is restored, it is determined whether the LACP packet is received, and if the LACP packet is received, the LACP module is advertised, and the LACP module collects the required information, and simultaneously sends the link delay detection packet, the packet. The format is as shown in FIG. 10. FIG. 10 is a schematic diagram of the format of the packet in the embodiment, testing the delay time of sending and receiving packets between the two devices, and then sending the fast-cut packet (the format of the packet is as shown in FIG. 10) to the peer end. After receiving the fast-cut packet, the peer immediately joins the member to the lacp aggregation group. After the local end delays for a certain period of time (such as half of the delay time), the local end performs fast cut and adds the restored link to the lacp aggregation group. The mechanism of the link recovery on both ends is basically synchronized. The service is basically not interrupted, which greatly reduces the convergence time of the aggregation link recovery.

Optionally, the message shown in Figure 10 uses a special DMAC: 0x 01 d0 d0 11 22 33, special Ether type: 0x2234

Message Protocol Interaction Field Description:

Version: current version 1.0

Type: 1 indicates the link delay detection packet, and 2 indicates the fast-cut notification packet.

Flag: Valid for the link delay detection message, 1 for the request and 2 for the response. Invalid for fast cut notification message

Seq Num: Valid for link delay detection packets, invalid for fast-cut notification packets

The link delay detection packet requires a sequence number. For example, one end sends a link delay detection packet (request packet) to the other end. After 200 ms, no response packet has been received, and another link delay can be sent. Detecting the message (requesting message). If the response message is received, the sequence number is judged whether it is the response to the first detection message or the second detection message, so that the N can be correctly calculated. .

A system for implementing fast convergence of an aggregation port in a link recovery process, including a storage module, a traffic module, a link fast recovery detection module, and a fault recovery processing module.

The storage module is configured to store an aggregation group member list. The aggregation group member list is used to store information of all members of the aggregation group.

The traffic forwarding module is configured to forward traffic according to the aggregation group member list stored by the storage module.

The link fast recovery detection module is configured to detect a lacp protocol for interaction between network device aggregation links, and determine the link by adding a link detection protocol, a fast-cut notification protocol, and a negotiation rule defined by the protocol. Recovery detection function.

The fault recovery processing module is configured to discover the custom fast-cut packet sent by the aggregation link, and add the information of the aggregation group member of the fault recovery to the aggregation group list, and the traffic is quickly restored.

For the aggregation link recovery policy in the related art, the technical defect of the convergence time cannot be met. When the switch detects that one of the faulty links is restored, the switch performs fast switching according to the port up state, and the ports at both ends of the device cannot be detected at the same time. At the same time, the fast-cutting, that is, the addition of the member, causes the port at one end to join the lacp aggregation group, and the other end has not yet joined the aggregation group. As a result, the traffic from the end of the aggregation group to the end of the aggregation group is lost. Therefore, the convergence time cannot meet the requirements of the current network device failure recovery convergence time. In order to solve the problem, the present embodiment proposes the solution, that is, when one of the faulty aggregation group member ports is restored, the self-defined protocol is customized according to the intercepted lacp protocol, and the fast link switching is completed by sending a custom protocol, and the method is implemented. , greatly reducing the problem of serious traffic loss caused by the port recovery.

In the data analysis of the aggregation link recovery in this embodiment, it is very common for the network packet to use the aggregated link to implement traffic forwarding in the network environment, but the link fault is also often present, and the link is faulty. The packet loss time can meet the requirements, but the fault recovery cannot be satisfied. The reason is that the two devices run dynamic lacp. After the port is up, each link performs the lacp protocol interaction without affecting each other. The module delivers the aggregation group member information to the driver module. The platform module cannot guarantee that the two devices will send the aggregation group member information at the same time. Secondly, the process of sending the member information of the aggregation module from the platform module to the driver module may delay the error, resulting in the underlying entries of the two devices. It is not updated at the same time, resulting in a serious packet loss, and the time is about 3s. However, this embodiment can solve the problem, and the time when the two ends are switched is basically the same, and the convergence time is within 5ms.

FIG. 5 is a schematic diagram of a method for implementing fast convergence of an aggregation port in a link recovery process based on a custom negotiation mechanism according to the embodiment. As shown in FIG. 5, the method includes:

Step 1: Determine whether a lCP packet is received.

In this embodiment, it is first determined whether a LACP packet is received, and if a LACP packet is received, a link delay detection packet is sent to the peer end, and the delay time is detected, and the local end receives the response and calculates the delay time.

Step 2: According to step 1, immediately send a notification to the peer to send a fast-cut message, which is a custom packet, and notify the peer to cut the packet immediately, and add the port to the lacp aggregation group.

Step 3: According to step 2, the local end delays for a certain time (half of the delay time calculated in step 1);

Step 4: On the basis of step 3, add the port to the aggregation group list to complete the link recovery.

FIG. 6 is a system diagram of implementing fast convergence of an aggregation port in a link recovery process according to a custom negotiation mechanism. As shown in FIG. 6, the system includes: a storage module, a traffic module, and a link recovery detection module. , fault recovery processing module.

The storage module is configured to store an aggregation group member list. The aggregation group member list is used to store information about all the members of the aggregation group. You can create an aggregation group. Add a number of members to the group and save a member of the aggregation group as a storage module. For example, Figure 7 Figure 7 is a schematic diagram of network load sharing in this embodiment. There are three links in the aggregation link, and the storage module stores the three aggregation group members.

The traffic forwarding module is configured to perform traffic forwarding according to the aggregation group member list stored in the storage module. For example, FIG. 8 is a schematic diagram of network load sharing when the 3 link fails in this embodiment, when the fault is aggregated. When the member status is restored, the restored member is added to the storage module based on the customized packet negotiation mechanism. The traffic is hashed to all members of the LCP group based on the hash policy. The status of the port is immediately restored to the traffic load balancing state. .

The link fast recovery detection module is configured to detect whether the faulty aggregation member port of the network device is restored, specifically, detecting whether the LACP packet is received, and if the LACP is received, immediately sending a link delay detection packet to the peer end. The local end receives the response packet, immediately calculates the delay time, and immediately sends a customized fast-cut notification message to the peer end. The peer end receives the fast-cut notification message and immediately cuts the packet. The local end according to the delay time. After the half-delay is performed, the fast-switching process is performed, and the restored port is added to the lacp aggregation group to complete the recovery of the aggregation link to ensure that the number of lost packets is within 5 ms.

The fault recovery processing module adds the restored link to the aggregation group after the custom negotiation succeeds, and the traffic is quickly restored to the port.

As shown in Figure 7, two devices, A B, have transmissions in between, and four ports run the lacp protocol. After the port is up, the project module reports to the platform module. After receiving the port up message, the platform module starts the lacp protocol interaction. Protocol interaction is based on links, and each of the four links interacts. A first packet or B first packet is random, such as A first packet (A--B direction), A sends a lacp interaction packet from port 1 to port 1 of B, and B receives a lcp packet from port 1. The driver module intercepts the message (does not affect the normal uplink platform module, and each port changes from down to up, only intercepts once), sends a notification message to the driver lacp module (the message only contains the source port), the driver After receiving the message, the lacp module can obtain two pieces of information: the packet is received from port 1, and the link connected to port 1 is up (because the message has already arrived). At this point, you can do a quick cut. Before the fast cut, you need to test the delay time of sending and receiving packets between the two devices, so that you can get the value of the delay Nms (1ms or more) mentioned in the following scheme. At this time, B to A can send a link delay detection message. After A receives, one situation is to immediately reply to B. After receiving the reply, B calculates the time difference (from issue to recovery), and then divides by 2 to do For the N delay time, the other case is 200ms. If the response message has not been received, we will send another link delay detection message (request message). If the response message is received, it will be judged. The sequence number carried in the message is known as the response to the first detection message or the response of the second detection message. The time difference is calculated after receiving the response, and then divided by 2 as the N delay time. If the link detection packet is discarded, the normal LACP exchange packet will be discarded. The platform module will not send the aggregation group member information entry. The project can wait for 100-200ms and continue to send the link delay detection message until it is recycled, and then proceed to the next step.

After the link delay between the two devices is calculated, it can be quickly cut. B must first send a fast-cut notification message and then locally fast-cut. After the packet is sent, there can be a delay of N ms (the N obtained by the link detection packet interaction), and then local fast-cut. This fast cut notification message is sent from port 1 of B. A intercepts and terminates the message from port 1, and then triggers the fast cut of port A of the A device. If the notification message is lost (the probability is very small), there is no problem, the B--A direction will also have this process, that is, the first LCP message received by A is also processed similarly (calculation delay N, Then A sends a quick cut to notify the message and then cuts it.) If the message is not lost, A has done a fast cut, then there is no need to process the first lcp message of B (that is, there is no need to send a fast cut notification message and then cut). By analogy, each link performs this interaction, and needs to update the number of entries (number of links) n times, and finally complete the link recovery.

As shown in Figure 7, two devices, A B, have transmissions in the middle. If both A B devices are multi-cpu, the processing mechanism and the instance are basically the same, but the CPU can be cut to idle cpu when the CPU is busy. This is the protection mechanism of the cpu. The four ports run the lacp protocol. After the port is up, the platform module is reported. When the platform module receives this message, it will start the lacp protocol interaction. The protocol interaction is based on the link, and the four links will interact with each other. A first packet or B first packet is random, such as A first packet (A--B direction), A sends a lacp interaction packet from port 1 to port 1 of B, and B receives a lcp packet from port 1. The driver module intercepts the message (does not affect the normal uplink platform module, and each port changes from down to up, only intercepts once), sends a notification message to the driver lacp module (the message only contains the source port), the driver After receiving the message, the lacp module can obtain two pieces of information: the packet is received from port 1, and the link of port 1 is up (because the message has already arrived). At this point, you can do a fast cut. You need to test the packet delay between the two devices before the fast cut, so you can get the value of the delay Nms (1ms or more) mentioned in the following scheme. At this time, B to A can send a link delay detection message. After A receives, one situation is to immediately reply to B. After receiving the reply, B calculates the time difference (from issue to recovery), and then divides by 2 to do For the N delay time, the other case is 200ms. If the response message has not been received, we will send another link delay detection message (request message). If the response message is received, it will be judged. The serial number carried in the message is known as the response to the first detection message or the response of the second detection message. The time difference is calculated (from issue to recovery), and then divided by 2, as the N delay time. If the time of sending and receiving is not equal, it is still divided by 2, which is the N delay time. If the link detection packet is discarded, the normal lacp exchange message should also be discarded, and the platform will not publish the item. The project can wait for 100-200ms and continue to send the link delay detection message until it is recycled, and then proceed to the next step.

After the link delay between the two devices is calculated, the switch can be fast-cut, but the cpu is busy. Because there are multiple CPUs, B can send the fast-cut notification packet on the idle cpu. There is a delay of N ms (N obtained by the link detection packet exchange), and then local fast cut, that is, the restored member port is quickly added to the aggregation group. This fast cut notification message is sent from port 1 of B. A intercepts and terminates the message from port 1, and then triggers the fast cut of port A of the A device. If the notification message is lost (the probability is very small), there is no problem, the B--A direction will also have this process, that is, the first LCP message received by A is also processed similarly (calculation delay N, Then A sends a quick cut to notify the message and then cuts it.) If the message is not lost, A has done a fast cut, then there is no need to process the first lcp message of B (that is, there is no need to send a fast cut notification message after fast cut). By analogy, each link performs this interaction, and needs to update the number of entries (number of links) for the last time. Finally, the link is restored. For devices with multiple CPUs, it can be guaranteed when the CPU is busy. You can still quickly add the restored members to the aggregation group on the free cpu.

In order to solve this problem, it is necessary to try to shorten the time difference between the two groups to join the aggregation group, so the driver module needs to be driven to perform fast switching processing. Therefore, a new method is proposed to ensure that the traffic after the faulty link is restored can be reduced. The cost of packet loss restores the business.

In an example, for example, a certain customer requirement, FIG. 9 is a schematic diagram of network load sharing when the vsc link fails in the embodiment. For example, FIG. 9 shows that a link of the SG1 in the aggregated link environment is required to be restored after the fault is recovered. The convergence time is within 5ms, and the node failure, that is, the network convergence time after the network device 1 is powered off and restarted is within 100ms, the present disclosure can solve the problem. Description of the requirements: When a link in the aggregation group recovers, the convergence time is within 5ms, and the convergence time of the node is restored within 100ms. With the embodiment, the aggregation port restores the normal load sharing requirement of the traffic with a minimum packet loss cost in the case of failure recovery.

Example 4

Embodiments of the present disclosure also provide a storage medium having stored therein a computer program, wherein the computer program is configured to execute the steps of any one of the method embodiments described above.

Optionally, in the embodiment, the above storage medium may be configured to store a computer program for performing the following steps:

S1. The first device negotiates with the second device to obtain a predetermined time, where the predetermined time is used to identify a transmission time of the communication link between the first device and the second device.

S2. The first device sends, to the second device, indication information for recovering the communication link.

S3. The first device resumes the communication link at a predetermined time after the indication information is sent.

Optionally, in the embodiment, the foregoing storage medium may include, but is not limited to, a USB flash drive, a Read-Only Memory (ROM), and a Random Access Memory (RAM). A variety of media that can store computer programs, such as hard drives, disks, or optical disks.

Embodiments of the present disclosure also provide an electronic device including a memory and a processor having a computer program stored therein, the processor being configured to execute a computer program to perform the steps of any one of the method embodiments described above.

Optionally, the electronic device may further include a transmission device and an input and output device, wherein the transmission device is connected to the processor, and the input and output device is connected to the processor.

Optionally, in this embodiment, the foregoing processor may be configured to perform the following steps by using a computer program:

S1. The first device negotiates with the second device to obtain a predetermined time, where the predetermined time is used to represent a transmission time of the communication link between the first device and the second device.

For example, the specific examples in this embodiment may refer to the examples described in the foregoing embodiments and the optional embodiments, and details are not described herein again.

It will be apparent to those skilled in the art that the various modules or steps of the present disclosure described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein. The steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated as a single integrated circuit module. As such, the disclosure is not limited to any specific combination of hardware and software.

The above description is only a preferred embodiment of the present disclosure, and is not intended to limit the disclosure, and various changes and modifications may be made to the present disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the scope of the present disclosure are intended to be included within the scope of the present disclosure.

Industrial applicability

As described above, the link recovery method, device, system, storage medium, and electronic device provided by the embodiments of the present invention have the following beneficial effects: the technology for over-packaging when recovering communication links between devices in the related art is solved. The problem is reduced traffic loss during failure recovery.

Claims

A link recovery method includes:

The first device negotiates with the second device to obtain a predetermined time, where the predetermined time is used to represent a transmission time of a communication link between the first device and the second device;

The first device sends indication information for restoring the communication link to the second device, and the first device resumes the communication link at the predetermined time after transmitting the indication information.
The method of claim 1, wherein before the first device sends the indication information to the second device for restoring the indication information, the method further comprises:

The first device determines to resume the communication link with the second device.
The method of claim 2, wherein before the first device determines to resume the communication link with the second device, the method further comprises:

The first device receives the link aggregation control protocol LACP packet, where the LACP packet is used to indicate that the communication link through which the LACP packet is restored is unobstructed.
The method of claim 3, wherein the determining, by the first device, that the communication link with the second device is restored comprises:

Determining, by the first device, whether the LACP packet is from a port of the communication link;

In the case where it is determined that the LACP message is from a port of the communication link, the first device determines to resume the communication link with the second device.
The method of claim 1, wherein before the first device negotiates with the second device to obtain a predetermined time, the method further comprises:

The first device detects a packet delay time with the second device, where the predetermined time is greater than or equal to the packet delay time.
The method of claim 5 wherein said predetermined time is one-half of said packet delay time.
The method of claim 1 wherein said recovering said communication link by said first device comprises:

The first device adds the communication link to the LACP aggregation group, where the member in the LACP aggregation group is used to transmit data between the first device and the second device.
The method of claim 1, wherein after the first device recovers the communication link, the method further comprises:

The first device exchanges traffic data with the second device over the communication link.
The method according to claim 5, wherein the detecting, by the first device, a packet delay time between the packet and the second device comprises:

Sending, by the first device, a request message for detecting a link delay to the second device;

Receiving, by the first device, a response message that is sent by the second device according to the request packet;

The first device calculates the transceiver packet delay time according to the difference between the receiving time of the response message and the sending time of the request message.
The method according to claim 9, wherein the request message carries a first message sequence number, and the response message carries a second message sequence number, wherein the first message sequence number and the second message The text number corresponds to.
A link recovery method includes:

And the second device negotiates with the first device to obtain a predetermined time, where the predetermined time is used to represent a transmission time of the communication link between the first device and the second device;

Receiving, by the second device, indication information that is sent by the first device to recover the communication link;

After receiving the indication information, the second device recovers the communication link according to the indication information.
The method of claim 11, wherein the recovering, by the second device, the communication link according to the indication information comprises:

The second device adds the communication link to the link aggregation control protocol LACP aggregation group, where the member in the LACP aggregation group is used to transmit data between the first device and the second device. .
The method of claim 11, wherein after the second device recovers the communication link according to the indication information, the method further comprises:

The second device exchanges traffic data with the first device over the communication link.
A link recovery device, applied to a first device, comprising:

a negotiation module, configured to negotiate with the second device to obtain a predetermined time, where the predetermined time is used to represent a transmission time of a communication link between the first device and the second device;

a sending module, configured to send, to the second device, indication information for recovering the communication link;

And a recovery module configured to resume the communication link at the predetermined time after transmitting the indication information.
A link recovery device is applied to a second device, including:

a negotiation module, configured to negotiate with the first device to obtain a predetermined time, where the predetermined time is used to represent a transmission time of a communication link between the first device and the second device;

a receiving module, configured to receive indication information sent by the first device for recovering the communication link;

The recovery module is configured to restore the communication link according to the indication information after receiving the indication information.
A link recovery system includes a first device and a second device,

The first device includes:

a first negotiation module, configured to negotiate with a second device to obtain a predetermined time, where the predetermined time is used to represent a transmission time of a communication link between the first device and the second device;

a sending module, configured to send, to the second device, indication information for recovering the communication link;

a first recovery module, configured to resume the communication link at the predetermined time after transmitting the indication information;

The second device includes:

a second negotiation module, configured to negotiate with the first device to obtain the predetermined time;

a receiving module, configured to receive indication information sent by the first device for recovering the communication link;

The second recovery module is configured to restore the communication link according to the indication information after receiving the indication information.
A storage medium having stored therein a computer program, wherein the computer program is arranged to execute the method of any one of claims 1 to 13 at runtime.
An electronic device comprising a memory and a processor, wherein the memory stores a computer program, the processor being arranged to execute the computer program to perform the method of any one of claims 1 to 13.