CN102946321B - 一种基于irf网络的故障处理方法和设备 - Google Patents

一种基于irf网络的故障处理方法和设备 Download PDF

Info

Publication number
CN102946321B
CN102946321B CN201210391897.6A CN201210391897A CN102946321B CN 102946321 B CN102946321 B CN 102946321B CN 201210391897 A CN201210391897 A CN 201210391897A CN 102946321 B CN102946321 B CN 102946321B
Authority
CN
China
Prior art keywords
frame
polymerized
equipment
member port
port
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201210391897.6A
Other languages
English (en)
Other versions
CN102946321A (zh
Inventor
吕辉
戴一凡
王佳炳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
New H3C Information Technologies Co Ltd
Original Assignee
Hangzhou H3C Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou H3C Technologies Co Ltd filed Critical Hangzhou H3C Technologies Co Ltd
Priority to CN201210391897.6A priority Critical patent/CN102946321B/zh
Publication of CN102946321A publication Critical patent/CN102946321A/zh
Application granted granted Critical
Publication of CN102946321B publication Critical patent/CN102946321B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

本发明公开了一种基于IRF网络的故障处理方法和设备,该方法包括:Recovery设备配置跨框聚合成员端口为动态聚合的非选中状态,并对其它端口进行MAD DOWN操作;在所述Recovery设备需要成为工作状态时,所述Recovery设备配置所述跨框聚合成员端口为动态聚合的选中状态,并对所述其它端口进行MAD Restore处理。本发明实施例中,可以保证业务不被长时间中断,并提高IRF网络的可靠性。

Description

一种基于IRF网络的故障处理方法和设备
技术领域
本发明涉及通信技术领域,尤其是涉及一种基于IRF(IntelligentResilientFramework,智能弹性架构)网络的故障处理方法和设备。
背景技术
IRF可集合多台设备的硬件资源和软件处理能力,实现多台设备的协同工作、统一管理和不间断维护;IRF链路故障会导致一个IRF变成多个新的IRF,这些IRF拥有相同的IP地址等配置,会引起地址冲突,并导致故障在网络中扩大;为提高系统可用性,MAD(Multi-ActiveDetection,多主用检测)机制提供一种检测和处理机制,以保证这种故障不会出现;其中,MAD的特点包括:
(1)分裂检测,通过LACP(LinkAggregationControlProtocol,链路聚合控制协议)、BFD(BidirectionalForwardingDetection,双向转发检测)、ARP(AddressResolutionProtocol,地址解析协议)或者ND(NeighborDiscovery,邻居发现)协议等来检测网络中是否存在多个IRF。
(2)冲突处理,在IRF分裂后,对于LACPMAD检测,先比较IRF中成员设备的数量,数量最多的IRF处于工作状态,其设备为Active(主用)设备,其它IRF迁移到禁用状态,其设备为Recovery(恢复)设备;如果成员设备数量相等,Master(主)成员编号最小的IRF处于工作状态,其它IRF迁移到禁用状态;对于BFDMAD/ARPMAD/NDMAD检测等,Master成员编号最小的IRF处于工作状态,其它IRF迁移到禁用状态。进一步的,处于禁用状态的Recovery设备会关闭所有物理端口(通常为业务接口),以保证不再转发业务报文。
(3)MAD故障恢复,IRF链路故障导致IRF分裂时会引起多Active冲突,因此需要修复故障IRF链路,使冲突IRF合并为一个IRF,恢复MAD故障;如果出现故障的是Active状态的IRF,则进行MAD故障恢复前,需启用Recovery状态的IRF,使其接替原IRF工作,保证业务尽量少受影响,再恢复MAD故障;如果在MAD故障恢复前,处于Recovery状态的IRF也出现故障,则需要将故障IRF和故障链路都修复后,才让冲突IRF重新合并为一个IRF,恢复MAD故障。
现有技术中,当MAD检测发现堆叠分裂时,会将Recovery设备的所有物理端口DOWN(故障),即Recovery设备不能转发业务报文,而Active设备可以继续工作;但是,如果之后Active设备由于下电或故障等情况无法继续工作时,Recovery设备无法解除物理端口的DOWN状态,造成业务长时间中断。
如图1所示,为IRF网络的组网示意图,设备M和设备S组成一个IRF系统,当通过MAD检测到网络中存在IRF冲突时,设备M成为Active设备,设备S成为Recovery设备,且设备S需要将所有物理端口MADDOWN,网络中所有业务流量在设备M上处理;此后如果设备M发生故障,则会导致业务长时间中断。
发明内容
本发明提出一种基于IRF网络的故障处理方法和设备,以避免业务的长时间中断。
为了达到上述目的,本发明实施例提供一种基于智能弹性架构IRF网络的故障处理方法,该方法应用于堆叠链路发生故障后的IRF网络中,该方法包括以下步骤:
恢复Recovery设备在堆叠链路发生故障,且自身处于禁用状态时,配置自身的跨框聚合成员端口为动态聚合的非选中状态,并对所述跨框聚合成员端口之外的其它端口进行多主用检测MAD故障DOWN操作;
所述Recovery设备根据所述跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的主用Active设备的MAD报文,确定所述Recovery设备需要成为工作状态或者不需要成为工作状态;
在所述Recovery设备需要成为工作状态时,所述Recovery设备配置所述跨框聚合成员端口为动态聚合的选中状态,并对所述跨框聚合成员端口之外的其它端口进行MAD还原Restore处理。
所述Recovery设备根据所述跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的主用Active设备的MAD报文,确定所述Recovery设备需要成为工作状态或者不需要成为工作状态,具体包括:
如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自所述Active设备的MAD报文,则所述Recovery设备确定自身不需要成为工作状态;或者,
如果没有跨框聚合成员端口上接收到来自所述Active设备的MAD报文,则所述Recovery设备统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;
如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则所述Recovery设备确定自身需要成为工作状态;
如果处于DOWN状态的跨框聚合成员端口的数量大于处于UP状态的跨框聚合成员端口的数量,则所述Recovery设备确定自身不需要成为工作状态。
所述方法进一步包括:所述Recovery设备在跨框聚合成员端口上接收到MAD报文时,如果所述MAD报文中携带的区域标识DomainID与所述Recovery设备的DomainID相同,则确定所述跨框聚合成员端口上接收到来自所述Active设备的MAD报文;否则,确定所述跨框聚合成员端口上没有接收到来自所述Active设备的MAD报文。
本发明实施例提供一种基于智能弹性架构IRF网络的故障处理方法,该方法应用于堆叠链路发生故障后的IRF网络中,该方法包括以下步骤:
主用Active设备根据自身的跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的恢复Recovery设备的多主用检测MAD报文,确定所述Active设备对端口需要进行MAD故障DOWN操作或者不需要进行MADDOWN操作;
在需要进行MADDOWN操作时,所述Active设备对所有端口进行MADDOWN操作。
所述主用Active设备根据自身的跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的恢复Recovery设备的多主用检测MAD报文,确定所述Active设备对端口需要进行MAD故障DOWN操作或者不需要进行MADDOWN操作的过程,进一步包括:
如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文,则所述Active设备确定自身不需要对端口进行MADDOWN操作;或者,
如果没有跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文,则所述Active设备统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;
如果处于UP状态的跨框聚合成员端口的数量小于处于DOWN状态的跨框聚合成员端口的数量,则所述Active设备确定自身需要对端口进行MADDOWN操作,并对所有端口进行MADDOWN操作;
如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则所述Active设备确定自身不需要对端口进行MADDOWN操作。
所述方法进一步包括:所述Active设备在跨框聚合成员端口上接收到MAD报文时,如果所述MAD报文中携带的区域标识DomainID与所述Active设备的DomainID相同,则确定所述跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文;否则,确定所述跨框聚合成员端口上没有接收到来自所述Recovery设备的MAD报文。
本发明实施例提供一种基于智能弹性架构IRF网络的故障处理设备,应用于堆叠链路发生故障后的IRF网络中,所述故障处理设备具体为堆叠链路发生故障前的恢复Recovery设备,且所述Recovery设备包括:
第一处理模块,用于在堆叠链路发生故障,且本设备处于禁用状态时,配置本设备的跨框聚合成员端口为动态聚合的非选中状态,并对所述跨框聚合成员端口之外的其它端口进行多主用检测MAD故障DOWN操作;
确定模块,用于根据所述跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的主用Active设备的MAD报文,确定所述Recovery设备需要成为工作状态或者不需要成为工作状态;
第二处理模块,用于在本设备需要成为工作状态时,配置所述跨框聚合成员端口为动态聚合的选中状态,并对所述跨框聚合成员端口之外的其它端口进行MAD还原Restore处理。
所述确定模块,具体用于如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自所述Active设备的MAD报文,则确定本设备不需要成为工作状态;或者,
如果没有跨框聚合成员端口上接收到来自所述Active设备的MAD报文,则统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则确定本设备需要成为工作状态;如果处于DOWN状态的跨框聚合成员端口的数量大于处于UP状态的跨框聚合成员端口的数量,则确定本设备不需要成为工作状态。
所述确定模块,还用于在跨框聚合成员端口上接收到MAD报文时,如果所述MAD报文中携带的区域标识DomainID与本设备的DomainID相同,则确定所述跨框聚合成员端口上接收到来自所述Active设备的MAD报文;否则,确定所述跨框聚合成员端口上没有接收到来自所述Active设备的MAD报文。
本发明实施例提供一种基于智能弹性架构IRF网络的故障处理设备,应用于堆叠链路发生故障后的IRF网络中,所述故障处理设备具体为堆叠链路发生故障前的主用Active设备,且所述Active设备包括:
确定模块,用于根据本设备的跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的恢复Recovery设备的多主用检测MAD报文,确定本设备对端口需要进行MAD故障DOWN操作或者不需要进行MADDOWN操作;
处理模块,用于在需要进行MADDOWN操作时,对所有端口进行MADDOWN操作。
所述确定模块,具体用于如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文,则确定本设备不需要对端口进行MADDOWN操作;或者,
如果没有跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文,则统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;如果处于UP状态的跨框聚合成员端口的数量小于处于DOWN状态的跨框聚合成员端口的数量,则确定本设备需要对端口进行MADDOWN操作;如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则确定本设备不需要对端口进行MADDOWN操作。
所述确定模块,还用于在跨框聚合成员端口上接收到MAD报文时,如果所述MAD报文中携带的区域标识DomainID与本设备的DomainID相同,则确定所述跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文;否则,确定所述跨框聚合成员端口上没有接收到来自所述Recovery设备的MAD报文。
与现有技术相比,本发明实施例至少具有以下优点:本发明实施例中,在IRF网络分裂之后,Recovery设备能够检测到Active设备是否出现故障,且当检测到Active设备出现故障而无法正常工作时,Recovery设备能够自动恢复为Active设备,以保证业务不被长时间中断,提高IRF网络的可靠性。
附图说明
图1是现有技术中IRF网络的组网示意图;
图2是本发明实施例的应用场景示意图;
图3是本发明实施例提出的一种基于IRF网络的故障处理方法流程图;
图4是本发明实施例提出的一种Recovery设备的结构示意图;
图5是本发明实施例提出的一种Active设备的结构示意图。
具体实施方式
针对现有技术中存在的问题,IRF网络中的堆叠链路发生故障之后,本发明实施例提出一种基于IRF网络的故障处理方法,处于禁用状态的Recovery设备能够检测到处于工作状态的Active设备是否可用,且当Active设备不可用时,Recovery设备能够自动成为处于工作状态的Active设备,且不可用的Active设备能够自动成为处于禁用状态的Recovery设备,从而保证业务不被长时间中断,提高IRF网络的可靠性。
本发明实施例提出的基于IRF网络的故障处理方法中,对所有跨框聚合成员端口使能MAD检测(如LACPMAD检测、BFDMAD检测、ARPMAD检测、NDMAD检测等)或者对一个跨框聚合成员端口使能MAD检测,并在堆叠链路发生故障后对所有跨框聚合成员端口使能MAD检测;在IRF网络的堆叠链路发生故障后,可以通过MAD检测到多个IRF冲突,导致IRF网络包括处于工作状态的Active设备和处于禁用状态的Recovery设备;以图2为本发明实施例的应用场景示意图,设备M与设备S堆叠在一起组成IRF网络,在IRF网络的堆叠链路发生故障后,设备M为Active设备,设备S为Recovery设备;在设备M上,端口a和端口b属于跨框聚合成员端口;在设备S上,端口d和端口e属于跨框聚合成员端口。
本发明实施例中,考虑到Active设备可能连接有独立设备(不与Recovery设备直接连接或间接连接,如图2中的设备C),因此在执行本发明实施例之前,还可以判断是否采用本发明实施例提出的故障处理方法,如果采用则进行后续流程;在一种优选的实施方式中,需要在堆叠链路发生故障前,统计所有设备(Recovery设备和Active设备)的跨框聚合成员端口数量和跨框聚合成员端口之外的其它UP(正常)端口数量;如果跨框聚合成员端口的数量大于其它UP端口的数量,则采用本发明实施例提出的故障处理方法。
在图2所示的应用场景下,设备M统计端口a和端口b属于跨框聚合成员端口,端口c属于其它UP端口,设备S统计端口d和端口e属于跨框聚合成员端口;因此,跨框聚合成员端口的数量大于其它UP端口的数量,即后续采用本发明实施例提出的故障处理方法。
如图3所示,在堆叠链路发生故障后的IRF网络中,针对堆叠链路发生故障前的Recovery设备,本发明实施例提出的故障处理方法包括以下步骤:
步骤301,Recovery设备在堆叠链路发生故障,且自身处于禁用状态时,配置自身的跨框聚合成员端口为动态聚合的非选中状态(即跨框聚合成员端口不能被动态聚合选中),并对跨框聚合成员端口之外的其它端口进行MADDOWN操作;其中,处于动态聚合的非选中状态的端口为UP状态,能够处理MAD报文(基于不同的MAD检测方式,可以为LACP报文、BFD报文等,后续以LACP报文为例),但不能处理MAD报文之外的其它报文。
在图2所示的应用场景下,设备S为Recovery设备,且跨框聚合成员端口为端口d和端口e,因此设备S需要修改端口d和端口e的聚合配置,使端口d和端口e为动态聚合的非选中状态(即不能被动态聚合选中),只能处理Active设备(即设备M)的LACP报文;此外,设备S还需要将端口d和端口e之外的其它端口(即设备S与设备M之间的非跨框聚合成员端口,图中未体现)MADDOWN,使所有业务流量均在M设备上运作。
本发明实施例中,在配置跨框聚合成员端口为动态聚合的非选中状态的过程中,具体的配置方式为修改跨框聚合成员端口的聚合配置;在图2所示的应用场景下,端口d和端口a组成某聚合口(如聚合口1),端口e和端口b组成某聚合口(如聚合口2);在聚合口1、端口d、端口a的聚合配置一致时,则端口d和端口a均为动态聚合的选中状态,此时通过修改端口d的聚合配置(如将端口d支持的VLAN由VLAN1修改为VLAN1和VLAN2),使得端口d的聚合配置与聚合口1的聚合配置不一致,则会导致端口d为动态聚合的非选中状态;同理,通过修改端口e的聚合配置,使得端口e的聚合配置与聚合口2的聚合配置不一致,则会导致端口e为动态聚合的非选中状态。
步骤302,Recovery设备根据跨框聚合成员端口的状态以及跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的Active设备的MAD报文(如LACP报文),确定Recovery设备需要成为工作状态或者不需要成为工作状态;其中,在Recovery设备需要成为工作状态时,表示Active设备不可用(如Active设备重启或者故障等),在Recovery设备不需要成为工作状态时,表示Active设备可用。
本发明实施例中,Recovery设备确定自身需要成为工作状态或者不需要成为工作状态的过程,进一步包括:
情况一、如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自Active设备的MAD报文(如LACP报文),则认为Active设备能够正常工作,Recovery设备确定自身不需要成为工作状态,即Recovery设备不需要进行任何处理。
在图2所示的应用场景下,设备S为Recovery设备,跨框聚合成员端口为端口d和端口e;如果端口d的状态为UP状态且端口d上接收到来自Active设备的MAD报文,和/或,端口e的状态为UP状态且端口e上接收到来自Active设备的MAD报文,则Recovery设备不需要成为工作状态。
情况二、如果没有跨框聚合成员端口上接收到来自Active设备的MAD报文,则Recovery设备统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则认为Active设备已不可用,Recovery设备确定自身需要成为工作状态。
在图2所示的应用场景下,设备S为Recovery设备,跨框聚合成员端口为端口d和端口e;如果端口d和端口e上均没有接收到来自Active设备的MAD报文,则Recovery设备需要统计端口d和端口e中处于UP状态的数量以及处于DOWN状态的数量;如果端口d和端口e的状态均为UP状态,则UP状态的数量大于DOWN状态的数量,即Recovery设备需要成为工作状态。
情况三、如果没有在跨框聚合成员端口上接收到来自Active设备的MAD报文,则Recovery设备统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;如果处于DOWN状态的跨框聚合成员端口的数量大于处于UP状态的跨框聚合成员端口的数量,则Recovery设备确定自身不需要成为工作状态,即Recovery设备不需要进行任何处理。
在图2所示应用场景下,设备S为Recovery设备,跨框聚合成员端口为端口d和端口e;如果端口d和端口e上均没有接收到来自Active设备的MAD报文,则Recovery设备需要统计端口d和端口e中处于UP状态的数量以及处于DOWN状态的数量;如果端口d和端口e的状态均为DOWN状态,则DOWN状态的数量大于UP状态的数量,Recovery设备不需要成为工作状态。
本发明实施例中,以LACPMAD检测为例,考虑到在LACPMAD检测机制中,LACP报文中将携带DomainID(区域标识,用于识别堆叠)和ActiveID(主用标识,用于表示此堆叠的Master),且在堆叠分裂之后,Active设备与Recovery设备的DomainID依然相同;基于此,为了获知跨框聚合成员端口上接收到的MAD报文是否为来自Active设备的MAD报文;则:Recovery设备在跨框聚合成员端口上接收到MAD报文时,如果MAD报文中携带的DomainID与Recovery设备的DomainID相同,则确定该跨框聚合成员端口上接收到来自Active设备(即堆叠链路发生故障前与Recovery设备为同一堆叠中的Active设备)的MAD报文;否则,确定该跨框聚合成员端口上没有接收到来自堆叠链路发生故障前的Active设备的MAD报文。
在上述过程中,为了使得Recovery设备能够尽快识别到Active设备的异常,以决定自身是否需要成为工作状态,可以设定当堆叠分裂之后,Recovery设备和Active设备发送LACP报文的时间为每秒1个。
步骤303,在Recovery设备需要成为工作状态时,Recovery设备配置跨框聚合成员端口为动态聚合的选中状态(即还原跨框聚合成员端口的聚合配置),并对跨框聚合成员端口之外的其它端口进行MADRestore(还原)处理。
在图2所示的应用场景下,设备S为Recovery设备,且跨框聚合成员端口为端口d和端口e,设备S修改端口d和端口e的聚合配置,使端口d和端口e为动态聚合的非选中状态(即不能被动态聚合选中)之后,如果Recovery设备需要成为工作状态,则需要还原端口d和端口e的聚合配置,使端口d和端口e为动态聚合的选中状态(即能够被动态聚合选中)。
本发明的上述实施例中,Recovery设备会配置跨框聚合成员端口为动态聚合的选中状态,并对跨框聚合成员端口之外的其它端口进行MADRestore处理,而Active设备也需要在相应情况下进行MADDOWN操作,以避免Recovery设备和Active设备均正常工作时所造成的问题,为此:
在堆叠链路发生故障后的IRF网络中,针对堆叠链路发生故障前的Active设备,本发明实施例提出的故障处理方法还包括以下步骤:
Active设备在堆叠链路发生故障,且自身处于工作状态时,根据自身的跨框聚合成员端口的状态以及跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的Recovery设备的MAD报文,确定Active设备对端口需要进行MADDOWN操作或者不需要进行MADDOWN操作;并在需要进行MADDOWN操作时,对所有端口进行MADDOWN操作。
本发明实施例中,Active设备确定自身对端口需要进行MADDOWN操作或者不需要进行MADDOWN操作的过程,进一步包括:
情况一、如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自Recovery设备的MAD报文(如LACP报文),则Active设备确定自身不需要对端口进行MADDOWN操作,即不进行任何处理。
在图2所示的应用场景下,设备M为Active设备,跨框聚合成员端口为端口a和端口b;如果端口a的状态为UP状态且端口a上接收到来自Recovery设备的MAD报文,和/或,端口b的状态为UP状态且端口b上接收到来自Recovery设备的MAD报文,则Active设备不对端口进行MADDOWN操作。
情况二、如果没有在跨框聚合成员端口上接收到来自Recovery设备的MAD报文,则Active设备统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;如果处于UP状态的跨框聚合成员端口的数量小于处于DOWN状态的跨框聚合成员端口的数量,则Active设备认为自身不可用,且Recovery设备会进行相关的MADRestore处理;为了保证Recovery设备与Active设备之间不产生冲突,Active设备确定自身需要对端口进行MADDOWN操作,并对所有端口进行MADDOWN操作。
在图2所示的应用场景下,设备M为Active设备,跨框聚合成员端口为端口a和端口b;如果端口a和端口b上均没有接收到来自Recovery设备的MAD报文,则Active设备需要统计端口a和端口b中处于UP状态的数量以及处于DOWN状态的数量;如果端口a和端口b的状态均为DOWN状态,则UP状态的数量小于DOWN状态的数量,即Active设备不可用,Active设备需要对端口进行MADDOWN操作,并对所有端口进行MADDOWN操作。
情况三、如果没有跨框聚合成员端口上接收到来自Recovery设备的MAD报文,则Active设备统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则Active设备确定自身不需要对端口进行MADDOWN操作,即不进行任何处理。
在图2所示的应用场景下,设备M为Active设备,跨框聚合成员端口为端口a和端口b;如果端口a和端口b上均没有接收到来自Recovery设备的MAD报文,则Active设备需要统计端口a和端口b中处于UP状态的数量以及处于DOWN状态的数量;如果端口a和端口b的状态均为UP状态,则UP状态的数量大于DOWN状态的数量,此时Active设备不需要对端口进行MADDOWN操作,即不进行任何处理。
本发明实施例中,以LACPMAD检测为例,考虑到在LACPMAD检测机制中,LACP报文中携带DomainID和ActiveID,且在堆叠分裂之后,Active设备与Recovery设备的DomainID依然相同;基于此,为了获知跨框聚合成员端口上接收到的MAD报文是否为来自Recovery设备的MAD报文;则:Active设备在跨框聚合成员端口上接收到MAD报文时,如果MAD报文中携带的DomainID与Active设备的DomainID相同,则确定跨框聚合成员端口上接收到来自Recovery设备(即堆叠链路发生故障前与Active设备为同一堆叠中的Recovery设备)的MAD报文;否则,确定跨框聚合成员端口上没有接收到来自堆叠链路发生故障前的Recovery设备的MAD报文。
本发明实施例中,是以LACP协议的实现为例说明的,实际应用中也可通过其它协议(如MSTP(MultipleSpanningTreeProtocol多实例生成树协议)等)实现,任何协议按照本发明实施例方案进行改进的都属于本发明范围。
本发明实施例中,考虑到分裂为多个堆叠系统的情况,相当于存在多个Recovery设备,各Recovery设备独立运行本发明实施例提供的技术方案,因此当Active设备不可用时,各Recovery设备都将重新变成工作状态,但是由于MAD检测机制仍然存在且生效,因此在比较变成工作状态的各Recovery设备之后,将只有一个继续处于工作状态,其它重新变成禁用状态。
基于与上述方法同样的发明构思,本发明实施例中还提供了一种基于智能弹性架构IRF网络的故障处理设备,应用于堆叠链路发生故障后的IRF网络中,述故障处理设备具体为堆叠链路发生故障前的恢复Recovery设备,如图4所示,所述Recovery设备包括:
第一处理模块11,用于在堆叠链路发生故障,且本设备处于禁用状态时,配置本设备的跨框聚合成员端口为动态聚合的非选中状态,并对所述跨框聚合成员端口之外的其它端口进行多主用检测MAD故障DOWN操作;
确定模块12,用于根据所述跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的主用Active设备的MAD报文,确定所述Recovery设备需要成为工作状态或者不需要成为工作状态;
第二处理模块13,用于在本设备需要成为工作状态时,配置所述跨框聚合成员端口为动态聚合的选中状态,并对所述跨框聚合成员端口之外的其它端口进行MAD还原Restore处理。
所述确定模块12,具体用于如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自所述Active设备的MAD报文,则确定本设备不需要成为工作状态;或者,
如果没有跨框聚合成员端口上接收到来自所述Active设备的MAD报文,则统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则确定本设备需要成为工作状态;如果处于DOWN状态的跨框聚合成员端口的数量大于处于UP状态的跨框聚合成员端口的数量,则确定本设备不需要成为工作状态。
所述确定模块12,还用于在跨框聚合成员端口上接收到MAD报文时,如果所述MAD报文中携带的区域标识DomainID与本设备的DomainID相同,则确定所述跨框聚合成员端口上接收到来自所述Active设备的MAD报文;否则,确定所述跨框聚合成员端口上没有接收到来自所述Active设备的MAD报文。
其中,本发明装置的各个模块可以集成于一体,也可以分离部署。上述模块可以合并为一个模块,也可以进一步拆分成多个子模块。
基于与上述方法同样的发明构思,本发明实施例中还提供了一种基于智能弹性架构IRF网络的故障处理设备,应用于堆叠链路发生故障后的IRF网络中,所述故障处理设备具体为堆叠链路发生故障前的主用Active设备,如图5所示,所述Active设备包括:
确定模块21,用于根据本设备的跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的恢复Recovery设备的多主用检测MAD报文,确定本设备对端口需要进行MAD故障DOWN操作或者不需要进行MADDOWN操作;
处理模块22,用于在需要进行MADDOWN操作时,对所有端口进行MADDOWN操作。
所述确定模块21,具体用于如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文,则确定本设备不需要对端口进行MADDOWN操作;或者,
如果没有跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文,则统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;如果处于UP状态的跨框聚合成员端口的数量小于处于DOWN状态的跨框聚合成员端口的数量,则确定本设备需要对端口进行MADDOWN操作;如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则确定本设备不需要对端口进行MADDOWN操作。
所述确定模块21,还用于在跨框聚合成员端口上接收到MAD报文时,如果所述MAD报文中携带的区域标识DomainID与本设备的DomainID相同,则确定所述跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文;否则,确定所述跨框聚合成员端口上没有接收到来自所述Recovery设备的MAD报文。
其中,本发明装置的各个模块可以集成于一体,也可以分离部署。上述模块可以合并为一个模块,也可以进一步拆分成多个子模块。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
本领域技术人员可以理解附图只是一个优选实施例的示意图,附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中,也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
以上公开的仅为本发明的几个具体实施例,但是,本发明并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims (8)

1.一种基于智能弹性架构IRF网络的故障处理方法,该方法应用于堆叠链路发生故障后的IRF网络中,其特征在于,该方法包括以下步骤:
恢复Recovery设备在堆叠链路发生故障,且自身处于禁用状态时,配置自身的跨框聚合成员端口为动态聚合的非选中状态,并对所述跨框聚合成员端口之外的其它端口进行多主用检测MAD故障DOWN操作;
所述Recovery设备根据所述跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的主用Active设备的MAD报文,确定所述Recovery设备是否需要成为工作状态;
在所述Recovery设备需要成为工作状态时,所述Recovery设备配置所述跨框聚合成员端口为动态聚合的选中状态,并对所述跨框聚合成员端口之外的其它端口进行MAD还原Restore处理;
所述Recovery设备在跨框聚合成员端口上接收到MAD报文时,如果所述MAD报文中携带的区域标识DomainID与所述Recovery设备的DomainID相同,则确定所述跨框聚合成员端口上接收到来自所述Active设备的MAD报文;否则,确定所述跨框聚合成员端口上没有接收到来自所述Active设备的MAD报文。
2.如权利要求1所述的方法,其特征在于,确定所述Recovery设备是否需要成为工作状态,具体包括:
如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自所述Active设备的MAD报文,则所述Recovery设备确定自身不需要成为工作状态;或者,
如果没有跨框聚合成员端口上接收到来自所述Active设备的MAD报文,则所述Recovery设备统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;
如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则所述Recovery设备确定自身需要成为工作状态;
如果处于DOWN状态的跨框聚合成员端口的数量大于处于UP状态的跨框聚合成员端口的数量,则所述Recovery设备确定自身不需要成为工作状态。
3.一种基于智能弹性架构IRF网络的故障处理方法,该方法应用于堆叠链路发生故障后的IRF网络中,其特征在于,该方法包括以下步骤:
主用Active设备根据自身的跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的恢复Recovery设备的多主用检测MAD报文,确定所述Active设备对端口是否需要进行MAD故障DOWN操作;
在需要进行MADDOWN操作时,所述Active设备对所有端口进行MADDOWN操作;
所述Active设备在跨框聚合成员端口上接收到MAD报文时,如果所述MAD报文中携带的区域标识DomainID与所述Active设备的DomainID相同,则确定所述跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文;否则,确定所述跨框聚合成员端口上没有接收到来自所述Recovery设备的MAD报文。
4.如权利要求3所述的方法,其特征在于,确定所述Active设备对端口是否需要进行MAD故障DOWN操作或,进一步包括:
如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文,则所述Active设备确定自身不需要对端口进行MADDOWN操作;或者,
如果没有跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文,则所述Active设备统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;
如果处于UP状态的跨框聚合成员端口的数量小于处于DOWN状态的跨框聚合成员端口的数量,则所述Active设备确定自身需要对端口进行MADDOWN操作;
如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则所述Active设备确定自身不需要对端口进行MADDOWN操作。
5.一种基于智能弹性架构IRF网络的故障处理设备,应用于堆叠链路发生故障后的IRF网络中,其特征在于,所述故障处理设备具体为堆叠链路发生故障前的恢复Recovery设备,且所述Recovery设备包括:
第一处理模块,用于在堆叠链路发生故障,且本设备处于禁用状态时,配置本设备的跨框聚合成员端口为动态聚合的非选中状态,并对所述跨框聚合成员端口之外的其它端口进行多主用检测MAD故障DOWN操作;
确定模块,用于根据所述跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的主用Active设备的MAD报文,确定所述Recovery设备是否需要成为工作状态;
第二处理模块,用于在本设备需要成为工作状态时,配置所述跨框聚合成员端口为动态聚合的选中状态,并对所述跨框聚合成员端口之外的其它端口进行MAD还原Restore处理;
所述确定模块,还用于在跨框聚合成员端口上接收到MAD报文时,如果所述MAD报文中携带的区域标识DomainID与本设备的DomainID相同,则确定所述跨框聚合成员端口上接收到来自所述Active设备的MAD报文;否则,确定所述跨框聚合成员端口上没有接收到来自所述Active设备的MAD报文。
6.如权利要求5所述的设备,其特征在于,
所述确定模块,具体用于如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自所述Active设备的MAD报文,则确定本设备不需要成为工作状态;或者,
如果没有跨框聚合成员端口上接收到来自所述Active设备的MAD报文,则统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则确定本设备需要成为工作状态;如果处于DOWN状态的跨框聚合成员端口的数量大于处于UP状态的跨框聚合成员端口的数量,则确定本设备不需要成为工作状态。
7.一种基于智能弹性架构IRF网络的故障处理设备,应用于堆叠链路发生故障后的IRF网络中,其特征在于,所述故障处理设备具体为堆叠链路发生故障前的主用Active设备,且所述Active设备包括:
确定模块,用于根据本设备的跨框聚合成员端口的状态以及所述跨框聚合成员端口上是否接收到来自堆叠链路发生故障前的恢复Recovery设备的多主用检测MAD报文,确定本设备对端口是否需要进行MAD故障DOWN操作;
处理模块,用于在需要进行MADDOWN操作时,对所有端口进行MADDOWN操作;
所述确定模块,还用于在跨框聚合成员端口上接收到MAD报文时,如果所述MAD报文中携带的区域标识DomainID与本设备的DomainID相同,则确定所述跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文;否则,确定所述跨框聚合成员端口上没有接收到来自所述Recovery设备的MAD报文。
8.如权利要求7所述的设备,其特征在于,
所述确定模块,具体用于如果有跨框聚合成员端口的状态为正常UP状态,且该跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文,则确定本设备不需要对端口进行MADDOWN操作;或者,
如果没有跨框聚合成员端口上接收到来自所述Recovery设备的MAD报文,则统计处于UP状态的跨框聚合成员端口的数量以及处于DOWN状态的跨框聚合成员端口的数量;如果处于UP状态的跨框聚合成员端口的数量小于处于DOWN状态的跨框聚合成员端口的数量,则确定本设备需要对端口进行MADDOWN操作;如果处于UP状态的跨框聚合成员端口的数量大于处于DOWN状态的跨框聚合成员端口的数量,则确定本设备不需要对端口进行MADDOWN操作。
CN201210391897.6A 2012-10-16 2012-10-16 一种基于irf网络的故障处理方法和设备 Active CN102946321B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201210391897.6A CN102946321B (zh) 2012-10-16 2012-10-16 一种基于irf网络的故障处理方法和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201210391897.6A CN102946321B (zh) 2012-10-16 2012-10-16 一种基于irf网络的故障处理方法和设备

Publications (2)

Publication Number Publication Date
CN102946321A CN102946321A (zh) 2013-02-27
CN102946321B true CN102946321B (zh) 2016-06-29

Family

ID=47729230

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201210391897.6A Active CN102946321B (zh) 2012-10-16 2012-10-16 一种基于irf网络的故障处理方法和设备

Country Status (1)

Country Link
CN (1) CN102946321B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107547271B (zh) * 2017-08-15 2021-03-02 新华三技术有限公司 堆叠设备的恢复方法及装置
CN108337159B (zh) * 2018-01-31 2021-05-28 新华三技术有限公司 端口操作控制方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101414932A (zh) * 2007-10-15 2009-04-22 华为技术有限公司 长距离无源光网络系统中告警管理的方法、系统及装置
CN102315975A (zh) * 2011-10-17 2012-01-11 杭州华三通信技术有限公司 一种基于irf系统的故障处理方法及其设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8055467B2 (en) * 2008-12-17 2011-11-08 Lsi Corporation Method of generating a restricted inline resistive fault pattern and a test pattern generator

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101414932A (zh) * 2007-10-15 2009-04-22 华为技术有限公司 长距离无源光网络系统中告警管理的方法、系统及装置
CN102315975A (zh) * 2011-10-17 2012-01-11 杭州华三通信技术有限公司 一种基于irf系统的故障处理方法及其设备

Also Published As

Publication number Publication date
CN102946321A (zh) 2013-02-27

Similar Documents

Publication Publication Date Title
CN102347867B (zh) 一种堆叠分裂检测的处理方法和设备
US8169896B2 (en) Connectivity fault management traffic indication extension
US7940645B2 (en) Protection switching method based on change in link status in ethernet link aggregation sublayer
CN102315975B (zh) 一种基于irf系统的故障处理方法及其设备
CN105656645B (zh) 堆叠系统的故障处理的决策方法和装置
CN102546222B (zh) 备份系统及故障检测处理方法
CN102882704B (zh) 一种issu的软重启升级过程中的链路保护方法和设备
CN102223258B (zh) 一种防止bfd会话中断的方法和设备
CN104113428B (zh) 一种设备管理装置和方法
EP3029883B1 (en) Network protection method and apparatus, next-ring node, and system
CN102255751A (zh) 一种堆叠冲突的处理方法和设备
CN101674208A (zh) 一种lacp mad检测的方法及设备
TWI455525B (zh) 環狀網路之復原方法
CN103220189B (zh) 一种mad检测备份方法和设备
CN108337159B (zh) 端口操作控制方法及装置
CN102244589B (zh) 处理虚拟交换单元系统中链路故障的方法及对端设备
WO2017000096A1 (zh) 一种链路恢复方法和网络设备
EP2677702A2 (en) A method and apparatus for load balance
WO2016091094A1 (zh) 一种光传送网的保护倒换方法及装置
CN102946321B (zh) 一种基于irf网络的故障处理方法和设备
CN101980478A (zh) 设备故障的检测处理方法、装置和网络设备
CN103414591A (zh) 一种端口故障恢复时的快速收敛方法和系统
CN103746912A (zh) 一种基于子环链路的数据报文传输方法和设备
EP2573977A1 (en) Subnet protection method and device for transport multi-protocol label switching (tmpls) network
CN106130783B (zh) 一种端口故障处理方法及装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CP03 Change of name, title or address

Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No.

Patentee after: NEW H3C TECHNOLOGIES Co.,Ltd.

Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base

Patentee before: HANGZHOU H3C TECHNOLOGIES Co.,Ltd.

CP03 Change of name, title or address
TR01 Transfer of patent right

Effective date of registration: 20230612

Address after: 310052 11th Floor, 466 Changhe Road, Binjiang District, Hangzhou City, Zhejiang Province

Patentee after: H3C INFORMATION TECHNOLOGY Co.,Ltd.

Address before: 310052 Changhe Road, Binjiang District, Hangzhou, Zhejiang Province, No. 466

Patentee before: NEW H3C TECHNOLOGIES Co.,Ltd.

TR01 Transfer of patent right