CN110278094A - 链路恢复方法及装置、系统、存储介质、电子装置 - Google Patents

Abstract

本发明提供了一种链路恢复方法及装置、系统、存储介质、电子装置，其中，该方法包括：第一设备与第二设备协商得到预定时间，其中，预定时间用于表征第一设备与第二设备之间的通信链路的传输时间；第一设备向第二设备发送用于恢复通信链路的指示信息，在发送指示信息之后的预定时间，第一设备恢复通信链路。通过本发明，解决了相关技术中在设备间恢复通信链路时丢包过多的技术问题。

Description

链路恢复方法及装置、系统、存储介质、电子装置

技术领域

本发明涉及通信领域，具体而言，涉及一种链路恢复方法及装置、系统、存储介质、电子装置。

背景技术

随着计算机及网络技术的高速发展和各种网络应用的不断涌现，基础数据通信网络的稳定性越来越重要。为了增加带宽，实现链路传输弹性和冗余等功能，交换机之间的连线一般是聚合链路，以实现出、入流量在各个成员口中的负载分担，聚合成员的状态有up和down状态，端口由down 到up的状态，称为链路汇聚控制协议(Link Aggregation ControlProtocol， LACP)恢复状态，此时就需要快速将本端口加入聚合组中，使该聚合链路可以很快参与后续的流量负载分担。

相关技术中的聚合功能作为一种数据中心技术，可以将来自客户机的请求分布到两个或更多的服务器上。相关技术中存在的问题是无法保证链路故障恢复过程中不出现大量的丢包，原因是：两台设备运行动态lacp，待端口up后，每条链路进行lacp协议交互，互不影响，待两端协商成功后，平台模块将激活的聚合组成员信息下发到驱动模块。首先平台模块无法保证两台设备间同时下发聚合组成员信息，其次，两台设备从平台模块到驱动模块下发聚合成员信息的流程也会有时延误差，就导致了两台设备底层聚合组成员表项不是同时更新，会导致一端成员加入聚合组另外一端成员后加入据聚合组，即两端加入聚合组的时间不能保持一致，两端加入聚合组时间差值越大，丢包的时间就越多，因为一端成员加入聚合组后流量就会立即负载分担到该端口，流量到达另一端，另一端由于未加入聚合组还处于去激活状态，即端口处于block状态，所以流量无法通过以至于出现大量的丢包，丢包时间和两端加入聚合组不一致的时间相同。

针对相关技术中存在的上述问题，目前尚未发现有效的解决方案。

发明内容

本发明实施例提供了一种链路恢复方法及装置、系统、存储介质、电子装置。

根据本发明的一个实施例，提供了一种链路恢复方法，包括：第一设备与第二设备协商得到预定时间，其中，所述预定时间用于表征所述第一设备与所述第二设备之间的通信链路的传输时间；所述第一设备向所述第二设备发送用于恢复所述通信链路的指示信息，在发送所述指示信息之后的所述预定时间，所述第一设备恢复所述通信链路。

根据本发明的一个实施例，提供了另一种链路恢复方法，包括：第二设备与第一设备协商得到预定时间，其中，所述预定时间用于表征所述第一设备与所述第二设备之间的通信链路的传输时间；所述第二设备接收第一设备发送的用于恢复所述通信链路的指示信息；所述第二设备在接收到所述指示信息后，根据所述指示信息恢复所述通信链路。

根据本发明的另一个实施例，提供了一种链路恢复装置，应用在第一设备，包括：协商模块，用于与第二设备协商得到预定时间，其中，所述预定时间用于表征所述第一设备与所述第二设备之间的通信链路的传输时间；发送模块，用于向所述第二设备发送用于恢复所述通信链路的指示信息；恢复模块，用于在发送所述指示信息之后的所述预定时间，恢复所述通信链路。

根据本发明的另一个实施例，提供了另一种链路恢复装置，应用在第二设备，包括：协商模块，用于与第一设备协商得到预定时间，其中，所述预定时间用于表征所述第一设备与所述第二设备之间的通信链路的传输时间；接收模块，用于接收第一设备发送的用于恢复所述通信链路的指示信息；恢复模块，用于在接收到所述指示信息后，根据所述指示信息恢复所述通信链路。

根据本发明的又一个实施例，提供了一种链路恢复系统，包括第一设备、第二设备，所述第一设备包括：第一协商模块，用于与第二设备协商得到预定时间，其中，所述预定时间用于表征所述第一设备与所述第二设备之间的通信链路的传输时间；发送模块，用于向所述第二设备发送用于恢复所述通信链路的指示信息；第一恢复模块，用于在发送所述指示信息之后的所述预定时间，恢复所述通信链路；所述第二设备包括：第二协商模块，用于与第一设备协商得到所述预定时间；接收模块，用于接收第一设备发送的用于恢复所述通信链路的指示信息；第二恢复模块，用于在接收到所述指示信息后，根据所述指示信息恢复所述通信链路。

根据本发明的又一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本发明的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

通过本发明，在发送用于恢复通信链路的指示信息给第二设备后的预定时间，第一设备再恢复通信链路，考虑第一设备检测与第二设备之间的收发包延迟时间，第一设备和第二设备可以同时恢复通信链路，解决了相关技术中在设备间恢复通信链路时丢包过多的技术问题，减少了在故障恢复时的流量丢失。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明实施例的网络构架图；

图2是根据本发明实施例的一种链路恢复方法的流程图；

图3是根据本发明实施例的一种链路恢复装置的结构框图；

图4是根据本发明实施例的另一种链路恢复装置的结构框图；

图5为本实施例一种基于自定义协商机制实现聚合端口在链路恢复过程中实现快速收敛的方法示意图；

图6是本实施例一种基于自定义协商机制实现聚合端口在链路恢复过程中实现快速收敛的系统图；

图7是本实施例网络负载分担示意图；

图8是本实施例中3链路出故障时的网络负载分担示意图；

图9是本实施例中vsc链路出故障时的网络负载分担示意图；

图10是本实施例的报文格式示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

实施例1

本申请实施例可以运行于图1所示的网络架构上，图1是本发明实施例的网络构架图，如图1所示，该网络架构包括：第一设备、第二设备，其中，第一设备与第二设备之间通过聚合链路进行交互。

在本实施例中提供了一种运行于上述网络架构的链路恢复方法，图2 是根据本发明实施例的一种链路恢复方法的流程图，如图2所示，该流程包括如下步骤：

步骤S202，第一设备与第二设备协商得到预定时间，其中，预定时间用于表征第一设备与第二设备之间的通信链路的传输时间；

步骤S204，第一设备向第二设备发送用于恢复所述通信链路的指示信息；

步骤S206，在发送指示信息之后的预定时间，第一设备恢复通信链路。

在本实施例中还提供了一种运行于上述网络架构的链路恢复方法，如图2所示，该流程包括如下步骤：

步骤S302，第二设备与第一设备协商得到预定时间，其中，预定时间用于表征第一设备与第二设备之间的通信链路的传输时间；

步骤S304，第二设备接收第一设备发送的用于恢复通信链路的指示信息；

步骤S306，第二设备在接收到指示信息后，根据指示信息恢复通信链路。

通过上述步骤，在发送用于恢复通信链路的指示信息给第二设备后的预定时间，第一设备再恢复通信链路，考虑第一设备检测与第二设备之间的收发包延迟时间，第一设备和第二设备可以同时恢复通信链路，解决了相关技术中在设备间恢复通信链路时丢包过多的技术问题，减少了在故障恢复时的流量丢失。

可选地，上述步骤的执行主体第一设备，第二设备可以为实体，软件，服务器，路由设备等，但不限于此。

可选地，在第一设备向第二设备发送用于恢复指示信息之前，还包括：第一设备确定恢复与第二设备之间的通信链路。在第一设备确定恢复与第二设备之间的通信链路之前，还包括：第一设备接收链路汇聚控制协议 LACP报文，其中，LACP报文用于表征恢复LACP报文所经由的通信链路通畅。

可选的，第一设备确定恢复与第二设备之间的通信链路包括：第一设备确定LACP报文是否来自通信链路的端口；通信链路包括两个端口，分别在第一设备侧和第二设备侧，第一设备可以从第一设备侧的端口接收 LACP报文；在确定出LACP报文来自通信链路的端口的情况下，即表明 LACP报文经由的通信链路通畅，具体是第一设备与第二设备间的通信链路通畅，第一设备确定恢复与第二设备之间的通信链路。

可选的，在第一设备与第二设备协商得到预定时间之前，方法还包括：第一设备检测与第二设备之间的收发包延迟时间，其中，预定时间大于或等于收发包延迟时间。

在一个优选的示例中，预定时间为收发包延迟时间的一半，用于充分考虑指示信息到达第二设备的传输时间。当然也可以是其他的时间，如可以考虑第二设备响应指示信息已经从接收到指示信息到恢复链路完成的时间。本实施例中，收发包延迟时间是报文从第一设备到第二设备，在从第二设备回到第一设备的时间，当然也可以用其他的传输时间表征。

可选的，第一设备恢复通信链路包括：第一设备将通信链路加入到 LACP聚合组，其中，LACP聚合组中的成员用于传输第一设备与第二设备之间的数据。在第一设备恢复通信链路之后，方法还包括:第一设备通过通信链路与第二设备交互流量数据。

在本实施例中，第一设备检测与第二设备之间的收发包延迟时间包括：

S11，第一设备向第二设备发送用于检测链路延迟的请求报文；

S12，第一设备接收第二设备根据请求报文反馈的应答报文；

S13，第一设备根据应答报文的接收时间与请求报文的发送时间之差计算收发包延迟时间。即使用接收时间减去发送时间得到收发包延迟时间。在应答报文携带第一设备接收到请求报文的时间戳时，也可以是使用该时间戳与请求报文的发送时间只差来计算收发包延迟时间，这样计算出的收发包延迟时间理论上上述示例的一半。

可选的，请求报文携带第一报文序号，应答报文携带第二报文序号，其中，第一报文序号与第二报文序号对应。第一设备可以周期性地发送请求报文，第一设备接收到多个请求报文后，也会反馈多个应答报文，使用对应序号的请求报文和应答报文可以保证收发包延迟时间的精确性。

可选的，第二设备根据指示信息恢复通信链路包括：第二设备将通信链路加入到链路汇聚控制协议LACP聚合组，其中，LACP聚合组中的成员用于传输第一设备与第二设备之间的数据。在第二设备根据指示信息恢复通信链路之后，方法还包括:第二设备通过通信链路与第一设备交互流量数据。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如 ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

在本实施例中还提供了一种链路恢复装置，系统，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图3是根据本发明实施例的一种链路恢复装置的结构框图，如图3所示，应用在第一设备，该装置包括：

协商模块30，用于与第二设备协商得到预定时间，其中，预定时间用于表征第一设备与第二设备之间的通信链路的传输时间；

发送模块32，用于向第二设备发送用于恢复通信链路的指示信息；

恢复模块34，用于在发送指示信息之后的预定时间，恢复通信链路。

图4是根据本发明实施例的另一种链路恢复装置的结构框图，如图4 所示，应用在第二设备，该装置包括：

协商模块40，用于与第一设备协商得到预定时间，其中，预定时间用于表征第一设备与第二设备之间的通信链路的传输时间；

接收模块42，用于接收第一设备发送的用于恢复通信链路的指示信息；

恢复模块44，用于在接收到指示信息后，根据指示信息恢复通信链路。

本实施例还提供一种链路恢复系统，包括图3所示的第一设备，图4 所示的第二设备。上述实施例1中可选示例中的操作步骤也可以通过模块或单元的形式实现在第一设备或第二设备中。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

实施例3

本实施例用于对本申请的方案进行补偿和详细说明：

本实施例提供了一种基于自定义协商机制实现聚合端口在链路恢复过程中实现快速收敛的方法和系统，能够保证网络与网络之间的数据报文在聚合组成员链路恢复时，流量能重新迅速的分担到所有的聚合组成员端口上，降低丢包率。

本实施例的一种基于自定义协议实现聚合端口在链路恢复过程中实现快速收敛的方法和系统，对于网络中的物理设备(如上述实施例中的第一设备和第二设备)设置其聚合组成员列表，所谓聚合组成员列表存储聚合组所有成员信息。

本实施例的方法包括：聚合链路恢复时判断是否收到lacp报文，如果收到lacp报文，就通告lacp模块，lacp模块收集需要的信息，同时发送链路延迟检测报文，报文格式如图10所示，图10是本实施例的报文格式示意图，测试两台设备之间的收发包延迟时间，之后发送快切报文(报文格式如图10所示)到对端，对端收到快切报文立即将成员加入lacp聚合组，本端延时一定时间(如延迟时间的一半)后立即做快切，将恢复的链路加入lacp聚合组，通过这种协商机制完成两端链路恢复动作基本保持同步的功能，业务基本不会中断，大大降低了聚合链路恢复的收敛时间。

可选的，图10所示的报文使用特殊的DMAC：0x 01d0d0 11 22 33，特殊的以太类型：0x2234

报文协议交互字段说明：

Version：当前版本1.0

Type：1表示链路延迟检测报文，2表示快切通知报文

Flag：对于链路延迟检测报文有效，1表示请求，2表示应答。对于快切通知报文无效

seq Num：对于链路延迟检测报文有效，对于快切通知报文无效

在链路延迟检测报文需要序列号，比如一端向另一端发了一个链路延迟检测报文(请求报文)，过了200ms，还没有收到应答报文，可以再发送一个链路延迟检测报文(请求报文)，后续若收到应答报文，通过判断序列号就知道是针对第一个检测报文的应答还是第二个检测报文的应答了，这样才能正确的计算N。

本实施例的一种基于自定义协议实现聚合端口在链路恢复过程中实现快速收敛的系统，包括：存储模块、流量模块、链路快速恢复检测模块、故障恢复处理模块。

所述存储模块，用于存储聚合组成员列表。所述聚合组成员列表用于存储聚合组所有成员的信息。

所述流量转发模块，用于根据存储模块存储的聚合组成员列表进行流量的转发。

所述链路快速恢复检测模块，用于检测网络设备聚合链路之间交互的 lacp协议，通过判断该协议在加上自己定义的链路检测协议、快切通告协议以及协商规则来完成链路恢复的检测功能。

所述故障恢复处理模块，用于发现聚合链路间发送的自定义快切报文，将所述故障恢复的聚合组成员信息加入聚合组列表，流量实现快速恢复。

对于相关技术中的聚合链路恢复策略，不能满足收敛时间的技术缺陷，当交换机检测到其中一条故障链路恢复时，根据端口up状态进行快切，无法做到设备两端的端口同时检测到up，同时进行快切，即成员的添加，会导致一端的端口加入lacp聚合组，另一端还没有加入聚合组，结果从加入聚合组的一端发到没有加入聚合组一端的流量就会丢失很多，以至于收敛时间无法满足当前网络设备故障恢复收敛时间的要求。为了解决该问题，本实施例提出本方案，即当其中一条故障聚合组成员口恢复时，根据截获的lacp协议，定制自己的协议，通过发送自定义协议完成快速链路切换，本方法的实施，极大的减少了由于端口在故障恢复时导致流量严重丢失的问题。

在本实施例的聚合链路恢复时的数据分析时，对于网络报文来说，网络环境中使用聚合链路实现流量的转发是非常普遍的，但是链路故障也是经常存在的，链路故障丢包时间目前能满足要求，但是故障恢复无法满足，原因是：两台设备运行动态lacp，待端口up后，每条链路进行lacp协议交互，互不影响，待两端协商成功后，平台模块将聚合组成员信息下发到驱动模块。首先平台模块无法保证两台设备同时下发聚合组成员信息，其次，两台设备从平台模块到驱动模块的聚合组成员信息下发流程也会有时延误差，就导致了两台设备底层表项不是同时更新，从而导致严重丢包，时间在3s左右，而本实施例正好能解决该问题，使两端切换时的时间基本保持一致，收敛时间在5ms以内。

图5为本实施例一种基于自定义协商机制实现聚合端口在链路恢复过程中实现快速收敛的方法示意图，如图5所示，该方法包括：

步骤1：判断是否收到lacp报文。

本实施例中，首先判断是否收到lacp报文，如果收到lacp报文，就向对端发送一个链路延时检测报文，检测延时时间，本端收到应答，计算延时间；

步骤2：依据步骤1，立即向对端发送通知快切报文，该报文是自定义报文，通知对端立即快切，将端口加入lacp聚合组。

步骤3：依据步骤2，本端延时一定时间(步骤1计算的延时间的一半)；

步骤4：在步骤3的基础上，将该端口加入聚合组列表，完成链路的恢复。

图6是本实施例一种基于自定义协商机制实现聚合端口在链路恢复过程中实现快速收敛的系统图，如图6所示，该系统包括：存储模块、流量模块、链路恢复检测模块、故障恢复处理模块。

所述存储模块，用于存储聚合组成员列表。所述聚合组成员列表用于存储聚合组所有成员的信息，可以创建一个聚合组，该组里加上若干成员，通过链表保存一份该聚合组对应的所有成员，作为存储模块，例如附图7，

图7是本实施例网络负载分担示意图，聚合链路里有三条链路，存储模块存储着这三条聚合组成员。

所述流量转发模块，用于根据存储模块存储的聚合组成员列表进行流量的转发，例如附图8，图8是本实施例中3链路出故障时的网络负载分担示意图，当故障的聚合组成员状态恢复时，根据自定义报文协商机制，将恢复的成员加入存储模块，流量依据hash原则，立即将流量hash到lacp 组所有的成员上，使该端口状态立即恢复到流量负载分担状态。

所述链路快速恢复检测模块，用于检测网络设备之间故障聚合成员端口是否恢复，具体就是检测是否收到lacp报文，如果收到lacp，立即向对端发送链路延时检测报文，本端收到应答报文，立即计算延时时间，并且立即向对端发送自定义的快切通知报文，对端收到快切通知报文立即快切，本端按照延时时间的一半延后立即进行快速切换处理，将恢复的端口加入到lacp聚合组内，完成聚合链路恢复的动作，保证丢包数在5ms以内。

所述故障恢复处理模块，在自定义协商成功之后，将恢复的链路加入聚合组，流量迅速恢复到该端口。

如附图7所示，A B两台设备，中间有传输，4个端口运行lacp协议，端口up后，项目模块上报到平台模块，平台模块收到端口up消息后，会开始lacp协议交互，协议交互是基于链路的，4条链路都会各自交互。A 先发包或B先发包是随机的，比如A先发包(A--B方向)，A从端口1发了一个lacp交互报文给B的端口1，B收到1口上来的lacp报文，驱动模块截获这个报文(不影响正常上送平台模块，每个端口从down变为up 后，只截获一次)，给驱动lacp模块发个通告消息(消息只包含源端口就可以)，驱动lacp模块收到消息后，可以获取两个信息：报文从端口1收上来，端口1连接的链路是up(因为报文已经过来了)。此时可以做快切了，快切前需要先测试两台设备之间的收发包延迟时间，从而可以获取后面方案提到的延迟Nms(大于等于1ms)的值。此时，B到A可以发送链路延迟检测报文，A收到后，一种情况是立刻回复给B，B收到回复后，计算时间差(从发出到回收)，然后除以2，做为N延时时间，另外一种情况是过了200ms，还没有收到应答报文，我们会再发送一个链路延迟检测报文(请求报文)，后续若收到应答报文，通过判断报文携带的序列号就知道是针对第一个检测报文的应答还是第二个检测报文的应答了，收到应答后计算时间差，然后除以2，做为N延时时间。若这个链路检测报文丢弃，则正常的lacp交换报文应该也会丢弃，平台模块也不会下发聚合组成员信息表项。项目可以等待100-200ms，继续发送链路延迟检测报文，直到回收后，再进行下一步。

两台设备间的链路延迟计算出来后，可以进行快切了。B要先发快切通知报文然后再本地快切，发包后可以有个N ms的延时(上面通过链路检测报文交互得到的N)，然后再进行本地快切。这个快切通知报文从B 的1口发送出去。A从1口截获并终结这个报文，然后触发A设备1口的快切。若这个通知报文丢失(概率很小)，也没问题，B--A方向也会有这个流程，即A收到B的第一个lacp报文也做类似的处理(计算延时N，然后A发快切通知报文后快切)。若这个报文没有丢失，A已做过快切，则不需要处理B的第一个lacp报文了(即不需要发快切通知报文后快切)。以此类推，每条链路都做这种交互，需要更新n次(链路的个数)表项，最后完成链路的恢复。

如附图7所示，AB两台设备，中间有传输，假如A B两台设备都是多cpu情况，处理机制和实例基本差不多，只是在cpu繁忙的时候可以切到空闲cpu上处理，这是cpu的保护机制。4个端口运行lacp协议，端口 up后，上报平台模块，平台模块收到这个消息，会开始lacp协议交互，协议交互是基于链路的，4条链路都会各自交互。A先发包或B先发包是随机的，比如A先发包(A--B方向)，A从端口1发了一个lacp交互报文给B的端口1，B收到1口上来的lacp报文，驱动模块截获这个报文(不影响正常上送平台模块，每个端口从down变为up后，只截获一次)，给驱动lacp模块发个通告消息(消息只包含源端口就可以)，驱动lacp模块收到消息后，可以获取两个信息：报文从端口1收上来，端口1链接的链路是up(因为报文已经过来了)。此时可以做快切了，快切前需要先测试两台设备之间的收发包延迟，从而可以获取后面方案提到的延迟Nms(大于等于1ms)的值。此时，B到A可以发送链路延迟检测报文，A收到后，一种情况是立刻回复给B，B收到回复后，计算时间差(从发出到回收)，然后除以2，做为N延时时间，另外一种情况是过了200ms，还没有收到应答报文，我们会再发送一个链路延迟检测报文(请求报文)，后续若收到应答报文，通过判断报文携带的序列号就知道是针对第一个检测报文的应答还是第二个检测报文的应答了，计算时间差(从发出到回收)，然后除以2，做为N延时时间，若是发送和接收的时间不对等，依然除以2，做为N延时时间。若这个链路检测报文丢弃，则正常的lacp交换报文应该也会丢弃，平台也不会下发表项。项目可以等待100-200ms，继续发送链路延迟检测报文，直到回收后，再进行下一步操作。

两台设备间的链路延迟计算出来后，可以进行快切了，但是此时发现 cpu比较繁忙，由于有多个cpu，B可以在空闲的cpu上先发快切通知报文，发包后可以有个N ms的延时(上面通过链路检测报文交互得到的N)，然后再进行本地快切，即快速将恢复的成员端口加入聚合组。这个快切通知报文从B的1口发送出去。A从1口截获并终结这个报文，然后触发A设备1口的快切。若这个通知报文丢失(概率很小)，也没问题，B--A方向也会有这个流程，即A收到B的第一个lacp报文也做类似的处理(计算延时N，然后A发快切通知报文后快切)。若这个报文没有丢失，A已做过快切，则不需要处理B的第一个lacp报文了(即不需要发快切通知报文后快切)。以此类推，每条链路都做这种交互，需要更新n次(链路的个数)表项，最后完成链路的恢复，对于有多个cpu的设备，能保证在 cpu繁忙的时候依然可以在空闲cpu上实现快速将恢复的成员加入聚合组的功能。

为了解决该问题，需要设法使两端加入聚合组的时间差尽量缩短，于是需要驱动模块来做快速切换处理，所以本文提出一种新的方法，保证故障链路恢复后的流量能以更少的丢包代价恢复业务。

在一个示例中，例如某客户需求，图9是本实施例中vsc链路出故障时的网络负载分担示意图，例如图9所示：要求聚合链路环境中SG1的一条链路在故障恢复后收敛时间在5ms以内，节点故障，即网络设备1断电重启后恢复收敛时间在100ms以内，本发明就可以解决该问题。需求描述：聚合组的一条链路故障恢复时，收敛时间要求在5ms以内，节点故障恢复时收敛时间在100ms以内。通过本实施例，实现了聚合口在故障恢复的情况下，以最少的丢包代价恢复流量正常负载分担的要求。

实施例4

本发明的实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：

S1，第一设备与第二设备协商得到预定时间，其中，预定时间用于表征第一设备与第二设备之间的通信链路的传输时间；

S2，第一设备向第二设备发送用于恢复通信链路的指示信息；

S3，在发送指示信息之后的预定时间，第一设备恢复通信链路。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，第一设备与第二设备协商得到预定时间，其中，预定时间用于表征第一设备与第二设备之间的通信链路的传输时间；

S2，第一设备向第二设备发送用于恢复通信链路的指示信息；

S3，在发送指示信息之后的预定时间，第一设备恢复通信链路。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (18)

1.一种链路恢复方法，其特征在于，包括：

第一设备与第二设备协商得到预定时间，其中，所述预定时间用于表征所述第一设备与所述第二设备之间的通信链路的传输时间；

所述第一设备向所述第二设备发送用于恢复所述通信链路的指示信息，在发送所述指示信息之后的所述预定时间，所述第一设备恢复所述通信链路。

2.根据权利要求1所述的方法，其特征在于，在所述第一设备向所述第二设备发送用于恢复所述指示信息之前，所述方法还包括：

第一设备确定恢复与第二设备之间的通信链路。

3.根据权利要求2所述的方法，其特征在于，在所述第一设备确定恢复与第二设备之间的通信链路之前，所述方法还包括：

所述第一设备接收链路汇聚控制协议LACP报文，其中，所述LACP报文用于表征恢复所述LACP报文所经由的通信链路通畅。

4.根据权利要求3所述的方法，其特征在于，所述第一设备确定恢复与第二设备之间的通信链路包括：

所述第一设备确定所述LACP报文是否来自所述通信链路的端口；

在确定出所述LACP报文来自所述通信链路的端口的情况下，所述第一设备确定恢复与第二设备之间的通信链路。

5.根据权利要求1所述的方法，其特征在于，在第一设备与第二设备协商得到预定时间之前，所述方法还包括：

所述第一设备检测与所述第二设备之间的收发包延迟时间，其中，所述预定时间大于或等于所述收发包延迟时间。

6.根据权利要求5所述的方法，其特征在于，所述预定时间为所述收发包延迟时间的一半。

7.根据权利要求1所述的方法，其特征在于，所述第一设备恢复所述通信链路包括：

所述第一设备将所述通信链路加入到LACP聚合组，其中，所述LACP聚合组中的成员用于传输所述第一设备与所述第二设备之间的数据。

8.根据权利要求1所述的方法，其特征在于，在所述第一设备恢复所述通信链路之后，所述方法还包括:

所述第一设备通过所述通信链路与所述第二设备交互流量数据。

9.根据权利要求5所述的方法，其特征在于，所述第一设备检测与所述第二设备之间的收发包延迟时间包括：

所述第一设备向所述第二设备发送用于检测链路延迟的请求报文；

所述第一设备接收所述第二设备根据所述请求报文反馈的应答报文；

所述第一设备根据所述应答报文的接收时间与所述请求报文的发送时间之差计算所述收发包延迟时间。

10.根据权利要求9所述的方法，其特征在于，所述请求报文携带第一报文序号，所述应答报文携带第二报文序号，其中，所述第一报文序号与所述第二报文序号对应。

11.一种链路恢复方法，其特征在于，包括：

第二设备与第一设备协商得到预定时间，其中，所述预定时间用于表征所述第一设备与所述第二设备之间的通信链路的传输时间；

所述第二设备接收第一设备发送的用于恢复所述通信链路的指示信息；

所述第二设备在接收到所述指示信息后，根据所述指示信息恢复所述通信链路。

12.根据权利要求11所述的方法，其特征在于，所述第二设备根据所述指示信息恢复所述通信链路包括：

所述第二设备将所述通信链路加入到链路汇聚控制协议LACP聚合组，其中，所述LACP聚合组中的成员用于传输所述第一设备与所述第二设备之间的数据。

13.根据权利要求11所述的方法，其特征在于，在所述第二设备根据所述指示信息恢复所述通信链路之后，所述方法还包括:

所述第二设备通过所述通信链路与第一设备交互流量数据。

14.一种链路恢复装置，其特征在于，应用在第一设备，包括：

协商模块，用于与第二设备协商得到预定时间，其中，所述预定时间用于表征所述第一设备与所述第二设备之间的通信链路的传输时间；

发送模块，用于向所述第二设备发送用于恢复所述通信链路的指示信息；

恢复模块，用于在发送所述指示信息之后的所述预定时间，恢复所述通信链路。

15.一种链路恢复装置，其特征在于，应用在第二设备，包括：

协商模块，用于与第一设备协商得到预定时间，其中，所述预定时间用于表征所述第一设备与所述第二设备之间的通信链路的传输时间；

接收模块，用于接收第一设备发送的用于恢复所述通信链路的指示信息；

恢复模块，用于在接收到所述指示信息后，根据所述指示信息恢复所述通信链路。

16.一种链路恢复系统，包括第一设备、第二设备，其特征在于，

所述第一设备包括：

第一协商模块，用于与第二设备协商得到预定时间，其中，所述预定时间用于表征所述第一设备与所述第二设备之间的通信链路的传输时间；

发送模块，用于向所述第二设备发送用于恢复所述通信链路的指示信息；

第一恢复模块，用于在发送所述指示信息之后的所述预定时间，恢复所述通信链路；

所述第二设备包括：

第二协商模块，用于与第一设备协商得到所述预定时间；

接收模块，用于接收第一设备发送的用于恢复所述通信链路的指示信息；

第二恢复模块，用于在接收到所述指示信息后，根据所述指示信息恢复所述通信链路。

17.一种存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至13任一项中所述的方法。

18.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至13任一项中所述的方法。