CN115484218A - 故障处理方法、交换设备、存储介质 - Google Patents

Abstract

本发明提供了一种故障处理方法、交换设备、存储介质，跨设备链路聚合交换系统的第一设备和第二设备之间连接有peer‑link链路，在所述peer‑link链路处于故障状态的情况下，当所述第二设备检测到所述第一设备的运行状态变更为故障状态，所述第二设备接管所述第一设备与网元进行的数据交换处理。根据本发明实施例提供的方案，在peer‑link链路处于故障状态，当第一设备出现故障，能够通过第二设备接管跨设备链路聚合交换系统的数据交换功能，从而避免了网络节点出现异常，有效提高了通信系统的稳定性。

Description

故障处理方法、交换设备、存储介质

技术领域

本发明涉及但不限于通信领域，尤其涉及一种故障处理方法、交换设备、存储介质。

背景技术

交换系统是网络节点的重要组成部分，随着通信技术的发展，跨设备链路聚合技术开始应用到各种交换系统。应用跨设备链路聚合技术的交换系统包括第一设备和第二设备，通过绑定第一设备和第二设备的通信端口得到跨设备聚合链路，再通过跨设备聚合链路与网元建立通信连接，能够有效提高数据交换的可靠性。

第一设备和第二设备之间配置有对等(peer-link)链路，通过peer-link链路传递与跨设备聚合链路相关联的硬件表项。根据有关协议，当peer-link链路出现故障，第二设备会断开与网元的通信连接，由第一设备单独完成数据交换。但是，若此时第一设备出现故障，交换系统无法进行数据交换，导致网络节点出现异常，无法保障网络的稳定性和可靠性。

发明内容

以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。

本发明实施例提供了一种故障处理方法、交换设备、存储介质，能够减少第一设备故障对交换系统的影响，提高网络的稳定性和可靠性。

第一方面，本发明实施例提供了一种故障处理方法，应用于跨设备链路聚合交换系统的第二设备，所述跨设备链路聚合交换系统还包括第一设备，所述第一设备和所述第二设备之间连接有peer-link链路，所述故障处理方法包括：

在所述peer-link链路处于故障状态的情况下，当检测到所述第一设备的运行状态变更为故障状态，接管所述第一设备与网元的数据交换处理。

第二方面，本发明实施例还提供了一种故障处理方法，应用于跨设备链路聚合交换系统的第一设备，所述跨设备链路聚合交换系统还包括第二设备，所述第一设备和所述第二设备之间连接有peer-link链路，所述故障处理方法包括：

在所述peer-link链路处于故障状态的情况下，当检测到所述第一设备发生故障，向所述第二设备发送第一故障通知，以使所述第二设备在根据所述第一故障通知确定所述第一设备的运行状态变更为故障状态的情况下，接管所述第一设备与网元的数据交换处理。

第三方面，本发明实施例提供了一种交换设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面所述的故障处理方法，或者，所述处理器执行所述计算机程序时实现如第二方面所述的故障处理方法。

本发明实施例包括：跨设备链路聚合交换系统的第一设备和第二设备之间连接有peer-link链路，在所述peer-link链路处于故障状态的情况下，当所述第二设备检测到所述第一设备的运行状态变更为故障状态，所述第二设备接管所述第一设备与网元进行的数据交换处理。根据本发明实施例提供的方案，在peer-link链路处于故障状态，当第一设备出现故障，能够通过第二设备接管跨设备链路聚合交换系统的数据交换功能，从而避免了网络节点出现异常，有效提高了通信系统的稳定性。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

图1是本发明一个实施例提供的应用于第二设备的故障处理方法的流程图；

图2是本发明另一个实施例提供的网络节点的装置示意图；

图3是本发明另一个实施例提供的确定第一设备出现故障的流程图；

图4是本发明另一个实施例提供的更新第二设备的硬件表项的流程图；

图5是本发明另一个实施例提供的更新第一设备的硬件表项的流程图；

图6是本发明另一个实施例提供的恢复跨设备聚合链路的流程图；

图7是本发明另一个实施例提供的第二设备出现故障的处理流程图；

图8是本发明另一个实施例提供的第二设备退出退避状态的流程图；

图9是本发明另一个实施例提供的应用于第一设备的故障处理方法的流程图；

图10是本发明另一个实施例提供的更新第一设备的硬件表项的流程图；

图11是本发明另一个实施例提供的恢复跨设备聚合链路的流程图；

图12是本发明另一个实施例提供的第二设备出现故障的处理流程图；

图13是本发明另一个实施例提供的确定第二设备出现故障的流程图；

图14是本发明的示例的网络节点的结构图；

图15是本发明的示例的故障处理方法的流程图；

图16是本发明另一个实施例提供的跨设备链路聚合交换设备的装置图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书、权利要求书或上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

本发明提供了一种故障处理方法、交换设备、存储介质，跨设备链路聚合交换系统的第一设备和第二设备之间连接有peer-link链路，在所述peer-link链路处于故障状态的情况下，当所述第二设备检测到所述第一设备的运行状态变更为故障状态，所述第二设备接管所述第一设备与网元进行的数据交换处理。根据本发明实施例提供的方案，在peer-link链路处于故障状态，当第一设备出现故障，能够通过第二设备接管跨设备链路聚合交换系统的数据交换功能，从而避免了网络节点出现异常，有效提高了通信系统的稳定性。

下面结合附图，对本发明实施例作进一步阐述。

如图1所示，图1是本发明一个实施例提供的一种故障处理方法的流程图，该故障处理方法应用于跨设备链路聚合交换系统的第二设备，所述跨设备链路聚合交换系统还包括第一设备，所述第一设备和所述第二设备之间连接有对等peer-link链路，所述故障处理方法包括但不限于有步骤S100：

步骤S100，在peer-link链路处于故障状态的情况下，当检测到第一设备的运行状态变更为故障状态，接管第一设备与网元的数据交换处理。

需要说明的是，跨设备链路聚合交换系统的设备可以是常见的交换机或者路由设备，本实施例对具体的设备类型不多作限定，能够组成跨设备链路聚合系统，并通过跨设备聚合链路与网元进行数据交换处理即可。可以理解的是，本实施例的网元可以是服务器或者网关设备等网络节点中的设备，能够通过跨设备聚合链路与交换设备进行数据交互即可，本实施例对网元的具体类型和具体数量不多作限定，并且，本领域技术人员有动机根据网元的具体数量从交换设备中选取出对应的端口数量。例如，如图2所示，网络节点包括跨设备链路聚合交换系统和至少两个网元，其中，跨设备链路聚合交换系统包括第一设备220和第二设备230，第一设备220和第二设备230之间连接有peer-link链路，两个网元分别为跨设备链路聚合交换系统的上下游设备，其中，第一网元210连接于跨设备链路聚合交换系统的上行方向，第二网元240连接于跨设备链路聚合交换系统的下行方向。另外，由于上下游分别设置有网元，因此在第一设备220中选取第一端口221和第三端口222，在第二设备中选取第二端口231和第四端口232，第一端口221与第一网元210之间连接有第一通信链路，第二端口231与第一网元210之间连接有第二通信链路，第三端口222与第二网元240之间连接有第三通信链路，第四端口232与第二网元240之间连接有第四通信链路；通过绑定第一端口221与第二端口231得到针对第一网元210的跨设备聚合链路，通过绑定第三端口222和第四端口232得到针对第二网元240的跨设备聚合链路。当然，上述图2中所示的结构仅为示例性说明，本领域技术人员有动机根据实际需求调整设备和跨设备聚合链路的数量、类型和连接顺序，这并不会对本实施例的技术方案造成限定。

可以理解的是，peer-link链路为连接在peer-link端口的通信链路，因此，对于peer-link链路的故障检测，可以通过检测peer-link端口的状态实现，本领域技术人员熟知如何判断链路状态，在此不多作赘述。

值得注意的是，对于现有协议中的规定，当peer-link链路出现故障后，第二设备会进行退避操作，断开与上下游设备的链路，仅由第一设备承载数据交换功能，但是第二设备本身是处于正常运行的状态，因此，在出现第一设备发生故障的情况下，相比起现有协议中第二设备保持退避状态造成跨设备链路聚合交换系统停止工作，本实施例的技术方案能够利用第一设备的故障状态唤醒第二设备，使得第二设备恢复与网元的通信连接，并且接管第一设备在先承载的数据交换功能，能够确保跨设备链路聚合交换系统持续运行，确保网络节点的稳定性。

另外，参照图3，在一实施例中，第一设备和第二设备之间还连接有备选传输链路，第一设备的运行状态变更为故障状态由以下步骤确定：

步骤S300，获取到第一设备通过备选传输链路发送的第一故障通知，第一故障通知由第一设备在发生故障的情况下生成并发送；

或者，

步骤S310，检测到备选传输链路异常；

或者，

步骤S320，通过备选传输链路向第一设备发送保活报文，在预设的保活周期内未接收到第一设备通过备选传输链路反馈的保活响应报文。

需要说明的是，在步骤S300中，在第一设备发生故障或者设备重启时，是能够在设备关闭之前发送第一故障通知的，例如，第一设备在整机异常之前向第二设备发送死亡通告报文，又如，在执行重启之前向第二设备发送设备重启相关的消息，也可以通过其他触发信息告知第二设备，本实施例对消息类型不多作限定。

需要说明的是，在步骤S300中，通过发送第一故障通知的方式将第一设备的故障告知第二设备是较为准确的方式，第二设备误判的可能性较低，但是，第一故障通知通常是在第一设备检测到即将故障时生成，也可能出现第一设备的故障发生了，但是第一故障通知未能及时发出的情况，例如第一设备检测到重启指令之后开始生成和发送第一故障通知，但是在发送之前已经执行重启，此时第一故障通知并未发出，而第一设备已经进入故障状态，因此，除了步骤S300的故障检测方式以外，还可以通过备选传输链路的异常检测来确定第一设备的运行状态。在本实施例的技术方案中，由于备选传输链路是第一设备和第二设备之间的传输链路，由于本实施例的技术方案是建立在第二设备正常运行的前提下，因此当第一设备出现故障导致数据无法收发，备选传输链路会出现异常，确定第一设备的运行状态变更为故障状态。需要说明的是，在步骤S310中通过传输链路的异常确定第一设备故障的方式中，也可以针对第一设备和第二设备之间的其他可用传输链路，除了peer-link链路之外的任意链路均可，本实施例对此不多作限定。

需要说明的是，在步骤S320中，备选传输链路可以采用第一设备和第二设备之间的Keepalive链路，因此，能够通过该链路向第一设备发送保活报文，在第一设备处于正常运行状态之下，能够响应保活报文，并且反馈保活响应报文，而考虑到第一设备的资源分配，可能需要一定时间才可以响应保活报文，因此可以设定保活周期，在该周期内未接收到保活响应报文，则可以确定第一设备处于故障状态。当然，也可以采用其他报文的检测实现第一设备运行状态的确定，例如通过心跳报文检测等，在此不多作赘述，能够通过报文交互方式确定第一设备的运行状态即可。

值得注意的是，步骤S300、步骤S310和步骤S320可以是任选其一，也可以是两个以上组合为条件集合，例如，在备选传输链路出现故障的情况下，也可能是第一设备的运行状态未发生变更，而仅仅是备选传输链路对应的端口出现故障，此时可以更换一条新的传输链路，通过保活报文的方式确定第一设备的运行状况，又如，在更换一条新的传输链路之后，接收到第一设备发送的触发信息，则可以确定并非备选传输链路本身出现故障，而是第一设备出现故障。当然，本领域技术人员也可以通过其他方式或者多种条件的组合确定第一设备的运行状态变更为故障状态，在此不多作限定。

另外，在一实施例中，第二设备通过第二通信链路与网元通信连接，第一设备和第二设备之间还连接有备选传输链路，参照图4，在一实施例中，在图1所示的步骤S100中，在检测到第一设备的运行状态变更为故障状态之前，还包括但不限于有以下步骤：

步骤S400，当检测到peer-link链路的运行状态变更为故障状态，关闭第二通信链路；

步骤S410，获取第一设备通过备选传输链路发送的第一更新信息，其中，第一更新信息表征第一设备的硬件表项的变更；

步骤S420，根据第一更新信息更新第二设备的硬件表项。

值得注意的是，可以通过关闭第二设备中与第二通信链路所对应的通信端口，实现第二通信链路的关闭，例如图2所示的结构中，当peer-link链路出现故障，第二设备230根据现有协议执行退避操作，断开第二端口231，并进入退避状态。

本领域技术人员熟知的是，在跨设备链路聚合交换系统中，peer-link链路用于传递第一设备和第二设备的硬件表项的更新信息，硬件表项通常包括通信端口所连接的设备的表项信息，例如介质访问控制(Media Access Control，MAC)地址表、路由表和地址解析协议(Address Resolution Protocol，ARP)表等信息，因此硬件表项的更新信息的数据量通常不大，当peer-link链路处于故障状态下，为了确保第二设备能够以正确的硬件表项接管交换功能，可以通过备选传输链路第一设备和第二设备之间实现第一更新信息的传递，其中，备选传输链路可以是第一设备和第二设备之间任意的可用链路，例如可以采用保活(Keepalive)链路作为备选传输链路，本领域技术人员有能力根据交互的数据量从任意一条可通信的传输链路选取备选传输链路，本实施例对此不多作限定。并且，备选传输链路的数量也可以是任意，例如在图2所示的结构中，第一设备220和第二设备230中分别有两个端口，用于实现上下游的数据交换，因此，可以针对第一端口221和第二端口231选定一条第一备选传输链路，针对第三端口222和第四端口232选定一条第二备选传输链路，当然，也可以仅选定一条备选传输链路，本实施例对此不用多作限定，根据实际需求确定备选传输链路的数量即可。

需要说明的是，在第二设备接管交换功能之后，通过改变硬件表项所指定的端口，使得数据通过第二通信链路进行收发，硬件表项在交换设备中的使用方法为本领域技术人员熟知的技术，在此不多作赘述。

另外，第一设备通过第一通信链路与网元通信连接，第一通信链路和第二通信链路归属于同一条跨设备聚合链路，参照图5，在一实施例中，在执行完图1所示的步骤S100之后，还包括但不限于有以下步骤：

步骤S500，在peer-link链路维持在故障状态的情况下，当检测第一设备的运行状态变更为正常运行状态，获取第二更新信息，通过备选传输链路将第二更新信息发送至第一设备，以使第一设备根据第二更新信息更新第一设备的硬件表项，并维持第一通信链路处于关闭状态，其中，第二更新信息表征第二设备的硬件表项的变更。

需要说明的是，在执行完图1所示的步骤S100后，第二设备完成对第一设备的接管，跨设备链路聚合交换系统通过第二设备与上下游设备进行数据交换，在这个过程中，虽然第一设备可以通过设备修复或者重启等方式从故障中恢复，但是若peer-link链路依然处于故障状态，第一设备和第二设备无法恢复跨设备聚合链路的连接方式，因此，可以通过维持第一通信链路处于关闭状态的方式，保持第一设备处于退避状态，维持由第二设备单独进行数据交换的工作方式。

可以理解的是，在本实施例的场景下，第二设备与网元通信连接并且承载跨设备链路聚合交换系统的数据交换功能，而在此过程中，第二设备的硬件表项可能会发生变化，而第一设备虽然处于退避状态，但是故障已经解除，此时通过备选传输链路将第二设备的硬件表项同步至第一设备，以确保跨设备链路聚合交换系统的两个设备中的硬件表项同步。

值得注意的是，在第二设备承载数据交换，第一设备处于退避状态的场景下，既可以对第一设备和第二设备的职能重新确定，即将当前的第二设备确定为第一设备，将当前的第一设备确定为第二设备，再利用备选传输链路执行上述实施例中记载的故障处理方法，也可以保持在先确定的职能不变，在peer-link链路恢复正常后重新建立跨设备聚合链路，本实施例对此不多作限定。

另外，参照图6，在一实施例中，在图5所示的步骤S400中，在通过备选传输链路将第二更新信息发送至第一设备之后，还包括但不限于有以下步骤：

步骤S600，当检测到peer-link链路的运行状态变更为正常运行状态，通过第二通信链路协同第一通信链路恢复与网元的基于跨设备聚合链路的数据交换处理，其中，第一通信链路由第一设备在检测到peer-link链路的运行状态变更为正常运行状态的情况下打开。

需要说明的是，基于上述实施例的描述，当第一设备从故障恢复，由于peer-link链路维持故障状态，因此不能实现跨设备链路聚合，保持关闭第一通信链路，通过第二设备的第二端口承载数据交换功能，但当peer-link链路恢复为正常运行状态，则跨设备链路聚合具备了硬件基础，此时为了实现更好的系统稳定性和交换性能，第一设备可以重新打开第一通信链路，使得跨设备聚合链路交换系统重新通过跨设备聚合链路与网元进行数据交换处理，本领域技术人员熟知如何在具备硬件基础且交换系统无故障的情况下实现跨设备链路聚合，在此不多作赘述。

另外，参照图7，在一实施例中，在执行完图4所示的步骤S400之后，还包括但不限于有以下步骤：

步骤S700，在检测到第二设备发生故障的情况下，生成第二故障通知，并通过备选传输链路将第二故障通知发送至第一设备，以使第一设备在根据第二故障通知确定第二设备的运行状态变更为故障状态的情况下，通过打开第一通信链路接管第二设备与网元的数据交换处理。

值得注意的是，在peer-link链路维持故障状态，并且第一设备维持退避状态的情况下，当第二设备出现故障，可以通过上述实施例中描述的第二设备接管第一设备的方式，由第一设备打开第一通信链路，恢复与网元的通信连接，从而接管第二设备，确保跨设备链路聚合交换系统能够维持交换功能，提高网络的稳定性。

值得注意的是，采用了本实施例的技术方案，在peer-link链路处于故障状态的情况下，第一设备和第二设备之间可以形成相互保护的状态，其中一个设备出现故障，唤醒另一个设备对网络节点的交换功能进行接管，能够有效提高网络的稳定性。

需要说明的是，第二设备生成第二故障通知，并发送至第一设备的方法，可以参考图3所示实施例的步骤S300的描述中第一设备向第二设备发送第一故障通知的原理，区别仅在于收发的主体不同，为了叙述简便在此不赘述。

另外，参照图8，在一实施例中，图1所示的步骤S100之后，还包括但不限于有以下步骤：

步骤S800，重新打开处于关闭状态的所述第二通信链路。

值得注意的是，在peer-link链路出现故障后，根据现有协议第二设备进入退避状态，当第一设备进一步出现故障后，交换系统产生二次故障，根据上述实施例的描述，可以通过第二设备接管第一设备，以维持交换系统的交换功能。由于第二设备进行退避操作的方式是断开第二通信链路，因此，当第二设备被唤醒之后，可以重新打开第二通信链路，建立与网元的通信连接，从而实现交换功能的快速恢复，提高网络的稳定性。

另外，参照图9，图9提供了一种故障处理方法，应用于跨设备链路聚合交换系统的第一设备，跨设备链路聚合交换系统还包括第二设备，第一设备和第二设备之间连接有peer-link链路，该故障处理方法包括但不限于有步骤S900：

步骤S900，在peer-link链路处于故障状态的情况下，当检测到第一设备发生故障，向第二设备发送第一故障通知，以使第二设备在根据第一故障通知确定第一设备的运行状态变更为故障状态的情况下，接管第一设备与网元的数据交换处理。

需要说明的是，通过第二设备接管第一设备与网元进行数据交换处理的原理和方式可以参考图1所示实施例记载的技术方案，区别在于本实施例的技术方案是以第一设备作为执行主体进行描述，为了叙述简便在此不重复赘述。

需要说明的是，根据现有协议的规定，当第二设备处于退避状态，第一设备一旦出现故障，并不会执行任何操作，导致跨设备链路聚合交换系统停止工作，影响网络的稳定，因此，需要唤醒第二设备对第一设备与网元的数据交换处理进行接管，当然，可以通过第二设备对第一设备的运行状态进行检测，但是第二设备检测的方式可能存在误判，因此，为了提高第二设备确定第一设备故障状态的准确性，可以在检测到故障出现的情况下向第二设备发送第一故障通知，具体原理和方式可以参考图3中所示实施例步骤S300的描述，在此不多作赘述。

另外，参照图10，在一实施例中，第一设备通过第一通信链路与网元通信连接，第一通信链路和第二通信链路归属于同一条跨设备聚合链路，在执行完图9所示实施例中的步骤S900之后，还包括但不限于有以下步骤：

步骤S1000，在peer-link链路维持在故障状态的情况下，当第一设备的运行状态变更为正常运行状态，获取第二设备通过备选传输链路发送的第二更新信息，其中，第二更新信息表征第二设备的硬件表项的变更；

步骤S1010，根据第二更新信息更新第一设备的硬件表项；

步骤S1020，维持第一通信链路处于关闭状态。

需要说明的是，本实施例的技术方案与图5所示实施例记载的技术方案相类似，区别在于本实施例的技术方案是以第一设备作为执行主体进行描述，第一设备恢复正常运行状态后，保持退避状态并通过第二更新信息更新第一设备的硬件表项流程和原理可以参考图5所示实施例的描述，为了叙述简便在此不重复赘述。

另外，参照图11，在执行完图10所示实施例中的步骤S1020之后，还包括但不限于有以下步骤：

步骤S1100，当检测到peer-link链路的运行状态变更为正常运行状态，打开第一通信链路；

步骤S1110，通过第一通信链路协同第二通信链路恢复与网元的基于跨设备聚合链路的数据交换处理。

需要说明的是，本实施例的技术方案与图5所示实施例记载的技术方案相类似，区别在于本实施例的技术方案是以第一设备作为执行主体进行描述，第一设备重新打开第一通信链路的流程和原理可以参考图5所示实施例的描述，为了叙述简便在此不重复赘述。

另外，参照图12，在一实施例中，在执行完图10所示实施例中的步骤S1010之后，还包括但不限于有以下步骤：

步骤S1200，在peer-link链路处于故障状态的情况下，当检测到第二设备的运行状态变更为故障状态，打开第一通信链路以接管第二设备与网元的数据交换处理。

需要说明的是，本实施例的技术方案与图6所示实施例记载的技术方案相类似，区别在于本实施例的技术方案是以第一设备作为执行主体进行描述，第一设备接管第二设备的流程和原理可以参考图6所示实施例的描述，为了叙述简便在此不重复赘述。

另外，参照图13，在一实施例中，图12所示实施例中，第一设备对第二设备的运行状态检测包括但不限于有以下步骤：

步骤S1300，获取到第二设备通过备选传输链路发送的第二故障通知，第二故障通知由第二设备在发生故障的情况下生成并发送；

或者，

步骤S1310，检测到备选传输链路异常；

或者，

步骤S1320，通过备选传输链路向第二设备发送保活报文，在预设的保活周期内未接收到第二设备通过备选传输链路反馈的保活响应报文。

需要说明的是，本实施例的技术方案与图3所示实施例记载的技术方案相类似，区别在于本实施例的技术方案是以第一设备对第二设备进行检测，而图3所示实施例是第二设备对第一设备进行检测，其检测的具体原理和步骤除了执行主体和信息传递方向之外没有区别，为了叙述简便在此不重复赘述。

为了更好地说明本发明的技术方案，以下提出一个具体示例，在该示例中，网络节点以图14所示的结构为例，如图14所示，以交换机A作为第一设备，交换机B作为第二设备，在交换机A中设置有端口A1和端口A2，在交换机B中设置有端口B1和B2，交换机A和交换机B组成一套跨设备链路聚合交换机系统，其中，端口A1和端口B1绑定得到跨设备聚合链路，端口A2和端口B2绑定得到跨设备聚合链路，备选传输链路以Keepalive链路为例，交换机A的故障以重启故障为例，对交换机A的故障判定方式以交换机A主动发送死亡通告报文为例；

在图14的结构基础上，参考图15，该故障处理方法包括但不限于有以下步骤：

步骤S1510，跨设备链路聚合交换机系统与网关设备和服务器连接，其中，端口A1与网关设备之间连接有第一通信链路，端口B1与网关设备之间连接有第二通信链路，端口A2与服务器之间连接有第三通信链路，端口B2与服务器之间连接有第四通信链路；

步骤S1520，交换机B确定peer-link链路发生故障；

步骤S1521，交换机B将端口B1、端口B2停用，断开第二通信链路和第四通信链路，从而中断与网关设备和服务器的通信，进入退避状态，保留交换机A和交换机B之间的keepalive链路正常通信；

步骤S1522，交换机A维持工作，并通过keepalive链路将交换机A的硬件表项的变化与交换机B进行同步；

步骤S1530,交换机A出现整机重启故障，并在重启前通过Keepalive链路向交换机B发出死亡通告报文；

步骤S1531，交换机B重新启用端口B1和端口B2，打开第二通信链路和第四通信链路，交换机B与网关设备和服务器之间恢复正常通信；

步骤S1540，交换机A完成重启，peer-link链路维持故障；

步骤S1541，交换机A维持端口A1和端口A2关闭，保持断开第一通信链路和第三通信链路，维持退避状态；

步骤S1542，交换机B与交换机A之间通过keepalive链路进行硬件表项同步；

步骤S1550，peer-link链路故障消除，交换机A打开端口A1和端口A2，打开第一通信链路和第三通信链路，交换机A重新加入跨设备链路聚合，交换机A和交换机B形成完整的跨设备链路聚合系统。

由以上的技术方案可见，与现有的跨设备链路聚合故障处理方法相比，通过本示例的技术方案，只需要跨设备链路聚合交换机系统第一设备和第二设备之间存在可以通信的链路，则在第一设备peer-link链路故障之后，如果再出现第一设备异常，第二设备即可迅速接管整个网络节点的交换功能，并且在第一设备和peer-link链路恢复正常之后，重新建立跨设备链路聚合系统，形成互为保护的状态。可以避免在peer-link链路故障之后再发生第一设备故障的情况下出现的网络节点的通信异常，而且在整个过程中第二设备可以维持正常的备份关系，同时第二设备之间还能保持整体硬件表项的同步，大幅提升了网络的稳定性和可靠性。

另外，参照图16，本发明的一个实施例还提供了一种跨设备链路聚合交换设备，该跨设备链路聚合交换设备1600包括：存储器1610、处理器1620及存储在存储器1610上并可在处理器1620上运行的计算机程序。

处理器1620和存储器1610可以通过总线或者其他方式连接。

实现上述实施例的故障处理方法所需的非暂态软件程序以及指令存储在存储器1610中，当被处理器1620执行时，执行上述实施例中的应用于第二设备的故障处理方法，例如，执行以上描述的图1中的方法步骤S100、图3中的方法步骤S300至步骤S320、图4中的方法步骤S400至步骤S420、图5中的方法步骤S500、图6中的方法步骤S600、图7中的方法步骤S700和图8中的方法步骤S800；或者，执行上述实施例中的应用于第一设备的故障处理方法，例如，执行以上描述的图9中的方法步骤S900、图10中的方法步骤S1000至步骤S1020、图11中的方法步骤S1100至步骤S1110、图12中的方法步骤S1200、图13中的方法步骤S1300至步骤S1320；或者，执行上述实施例中的应用于跨设备链路聚合交换系统的故障处理方法，例如，执行图15中的方法步骤S1510至步骤S1550。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

此外，本发明的一个实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令被一个处理器或控制器执行，例如，被上述跨设备链路聚合交换系统实施例中的一个处理器执行，可使得上述处理器执行上述实施例中的应用于第二设备的故障处理方法，例如，执行以上描述的图1中的方法步骤S100、图3中的方法步骤S300至步骤S320、图4中的方法步骤S400至步骤S420、图5中的方法步骤S500、图6中的方法步骤S600、图7中的方法步骤S700和图8中的方法步骤S800；或者，执行上述实施例中的应用于第一设备的故障处理方法，例如，执行以上描述的图9中的方法步骤S900、图10中的方法步骤S1000至步骤S1020、图11中的方法步骤S1100至步骤S1110、图12中的方法步骤S1200、图13中的方法步骤S1300至步骤S1320；或者，执行上述实施例中的应用于跨设备链路聚合交换系统的故障处理方法，例如，执行图15中的方法步骤S1510至步骤S1550。本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

以上是对本发明的较佳实施进行了具体说明，但本发明并不局限于上述实施方式，熟悉本领域的技术人员在不违背本发明精神的前提下还可作出种种的等同变形或替换，这些等同的变形或替换均包含在本发明权利要求所限定的范围内。

Claims (15)

1.一种故障处理方法，应用于跨设备链路聚合交换系统的第二设备，所述跨设备链路聚合交换系统还包括第一设备，所述第一设备和所述第二设备之间连接有对等peer-link链路，所述故障处理方法包括：

在所述peer-link链路处于故障状态的情况下，当检测到所述第一设备的运行状态变更为故障状态，接管所述第一设备与网元的数据交换处理。

2.根据权利要求1所述的方法，其特征在于，所述第一设备和所述第二设备之间还连接有备选传输链路，所述第一设备的运行状态变更为故障状态由以下至少之一的方式确定：

获取到所述第一设备通过所述备选传输链路发送的第一故障通知，所述第一故障通知由所述第一设备在发生故障的情况下生成并发送；

或者，

检测到所述备选传输链路异常；

或者，

通过所述备选传输链路向所述第一设备发送保活报文，在预设的保活周期内未接收到所述第一设备通过所述备选传输链路反馈的保活响应报文。

3.根据权利要求1所述的方法，其特征在于，所述第二设备通过第二通信链路与所述网元通信连接，所述第一设备和所述第二设备之间还连接有备选传输链路，在检测到所述第一设备的运行状态变更为故障状态之前，所述方法包括：

当检测到所述peer-link链路的运行状态变更为故障状态，关闭所述第二通信链路；

获取所述第一设备通过所述备选传输链路发送的第一更新信息，其中，所述第一更新信息表征所述第一设备的硬件表项的变更；

根据所述第一更新信息更新所述第二设备的硬件表项。

4.根据权利要求3所述的方法，其特征在于，所述第一设备通过第一通信链路与所述网元通信连接，所述第一通信链路和所述第二通信链路归属于同一条跨设备聚合链路，在所述接管所述第一设备与网元的数据交换处理之后，所述方法还包括：

在所述peer-link链路维持在故障状态的情况下，当检测所述第一设备的运行状态变更为正常运行状态，获取第二更新信息，通过所述备选传输链路将所述第二更新信息发送至所述第一设备，以使所述第一设备根据所述第二更新信息更新所述第一设备的硬件表项，并维持所述第一通信链路处于关闭状态，其中，所述第二更新信息表征所述第二设备的硬件表项的变更。

5.根据权利要求4所述的方法，其特征在于，在所述通过所述备选传输链路将所述第二更新信息发送至所述第一设备之后，所述方法还包括：

当检测到所述peer-link链路的运行状态变更为正常运行状态，通过所述第二通信链路协同所述第一通信链路恢复与所述网元的基于跨设备聚合链路的数据交换处理，其中，所述第一通信链路由所述第一设备在检测到所述peer-link链路的运行状态变更为正常运行状态的情况下打开。

6.根据权利要求4所述的方法，其特征在于，在所述通过所述备选传输链路将所述第二更新信息发送至所述第一设备之后，所述方法还包括：

在检测到所述第二设备发生故障的情况下，生成第二故障通知，并通过所述备选传输链路将所述第二故障通知发送至所述第一设备，以使所述第一设备在根据所述第二故障通知确定所述第二设备的运行状态变更为故障状态的情况下，通过打开所述第一通信链路接管所述第二设备与所述网元的数据交换处理。

7.根据权利要求3所述的方法，其特征在于，在所述接管所述第一设备与网元的数据交换处理之前，所述方法还包括：

重新打开处于关闭状态的所述第二通信链路。

8.一种故障处理方法，应用于跨设备链路聚合交换系统的第一设备，所述跨设备链路聚合交换系统还包括第二设备，所述第一设备和所述第二设备之间连接有peer-link链路，所述故障处理方法包括：

在所述peer-link链路处于故障状态的情况下，当检测到所述第一设备发生故障，向所述第二设备发送第一故障通知，以使所述第二设备在根据所述第一故障通知确定所述第一设备的运行状态变更为故障状态的情况下，接管所述第一设备与网元的数据交换处理。

9.根据权利要求8所述的方法，其特征在于，所述第一设备和所述第二设备之间还连接有备选传输链路，在所述向所述第二设备发送第一故障通知之前，所述方法还包括：

在所述peer-link链路处于故障状态的情况下，生成第一更新信息，所述第一更新信息表征所述第一设备的硬件表项的变更；

通过所述备选传输链路向所述第二设备发送所述第一更新信息，以使所述第二设备根据所述第一更新信息更新所述第二设备的硬件表项。

10.根据权利要求9所述的方法，其特征在于，所述第一设备通过第一通信链路与所述网元通信连接，所述第一通信链路和所述第二通信链路归属于同一条跨设备聚合链路，在所述向所述第二设备发送第一故障通知，以使所述第二设备在根据所述第一故障通知确定所述第一设备的运行状态变更为故障状态的情况下，接管所述第一设备与网元的数据交换处理之后，所述方法还包括：

在所述peer-link链路维持在故障状态的情况下，当所述第一设备的运行状态变更为正常运行状态，获取所述第二设备通过所述备选传输链路发送的第二更新信息，其中，所述第二更新信息表征所述第二设备的硬件表项的变更；

根据所述第二更新信息更新所述第一设备的硬件表项；

维持所述第一通信链路处于关闭状态。

11.根据权利要求10所述的方法，其特征在于，在所述根据所述第二更新信息更新所述第一设备的硬件表项之后，所述方法还包括：

当检测到所述peer-link链路的运行状态变更为正常运行状态，打开所述第一通信链路；

通过所述第一通信链路协同所述第二通信链路恢复与所述网元的基于跨设备聚合链路的数据交换处理。

12.根据权利要求10所述的方法，其特征在于，在所述根据所述第二更新信息更新所述第一设备的硬件表项之后，所述方法还包括：

在所述peer-link链路处于故障状态的情况下，当检测到所述第二设备的运行状态变更为故障状态，打开所述第一通信链路以接管所述第二设备与网元的数据交换处理。

13.根据权利要求12所述的方法，其特征在于，所述第二设备的运行状态变更为故障状态由以下至少之一的方式确定：

获取到所述第二设备通过所述备选传输链路发送的第二故障通知，所述第二故障通知由所述第二设备在发生故障的情况下生成并发送；

或者，

检测到所述备选传输链路异常；

或者，

通过所述备选传输链路向所述第二设备发送保活报文，在预设的保活周期内未接收到所述第二设备通过所述备选传输链路反馈的保活响应报文。

14.一种交换设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任意一项所述的故障处理方法，或者，所述处理器执行所述计算机程序时实现如权利要求8至13中任意一项所述的故障处理方法。

15.一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行如权利要求1至13中任意一项所述的故障处理方法。

Images