CN102932183B - 双上行链路故障处理方法及设备 - Google Patents

双上行链路故障处理方法及设备 Download PDF

Info

Publication number
CN102932183B
CN102932183B CN201210437342.0A CN201210437342A CN102932183B CN 102932183 B CN102932183 B CN 102932183B CN 201210437342 A CN201210437342 A CN 201210437342A CN 102932183 B CN102932183 B CN 102932183B
Authority
CN
China
Prior art keywords
group
port
smlk
message
equipment
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
CN201210437342.0A
Other languages
English (en)
Other versions
CN102932183A (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 CN201210437342.0A priority Critical patent/CN102932183B/zh
Publication of CN102932183A publication Critical patent/CN102932183A/zh
Application granted granted Critical
Publication of CN102932183B publication Critical patent/CN102932183B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了双上行链路故障处理方法及设备。该链路上配置了SMLK组和MTLK组,该方法包括:当双上行链路中配置了MTLK组的设备发现MTLK组的上行口从Up变为Down时,先将该上行口阻塞,再将该组的下行口先Down然后又立即Up;当双上行链路中配置了SMLK组的设备发现SMLK组的Active端口从Up变为Down时,将该端口的状态变为Standby,并将原Standby端口切换到Active状态,并从SMLK组当前Active端口发送Flush报文,然后将SMLK组的状态置为非激活状态,且设定在非激活状态下,SMLK组的Standby端口不阻塞任何报文。本发明在双上行链路故障时避免了链路出现环路,同时使得周边设备正常通信。

Description

双上行链路故障处理方法及设备
技术领域
本发明涉及双上行组网技术领域,具体涉及双上行链路故障处理方法及设备。
背景技术
首先给出双上行组网中如下技术术语的解释:
灵活链路(SMLK,Smart Link)组:每个组内只包含两个端口,其中一个为主端口,另一个为从端口。正常情况下,只有一个端口处于转发(Active)状态,另一个端口被阻塞,处于待命(Standby)状态。当处于Active状态的端口出现链路故障(包括端口断掉(Down)、以太网操作管理和维护(OAM,Operations,Administration and Maintenance)检测到单向链路等)时,SMLK组会自动将该端口阻塞,并将原阻塞的处于Standby状态的端口切换到Active状态。
监控链路(MTLK,Monitor Link)组:每个组由上行接口和下行接口共同组成。一个MTLK组可以有多个上行接口或下行接口,但一个接口只能属于一个MTLK组。它通过监控设备的上行接口,根据其正常(Up)/Down状态的变化来触发下行接口Up/Down状态的变化,从而触发下游设备上的拓扑协议进行链路切换。
连通错误检测-连续性检测功能(CFD-CC,Connectivity Fault Detection-Continuity Check):遵循电气和电子工程师协会(IEEE,Institute of Electricaland Electronics Engineers)802.1ag的连通错误管理(CFM,Connectivity FaultManagement)协议和电信联盟远程通信标准化组织(ITU-T,ITUTelecommunication Standardization Sector)的Y.1731协议。它是一种二层链路上基于虚拟局域网(VLAN,Virtual Local Area Network)的端到端OAM机制,主要用于在二层网络中检测链路连通性,确认故障并确定故障发生的位置。CC表示CFD的连续性检测功能,通过发送/接收CC类报文来检测链路上是否出现故障,从而感知链路是否是连续性的。
Flush报文:当Smart Link组发生链路切换时,原有的转发表项将不适用于新的拓扑网络,需要网络中的所有设备进行媒体访问控制(MAC,MediaAccess Control)地址转发表项和地址解析协议(ARP,Address ResolutionProtocol)/邻居发现(ND,Neighbors Discovery)表项的更新。这时,SmartLink组通过发送Flush报文通知其它设备进行MAC地址转发表项和ARP/ND表项的刷新操作。Flush报文是普通的组播数据报文,会被阻塞的接收端口丢弃。
当下游设备连接到上游设备时,使用单上行方式容易出现单点故障,造成业务中断。因此通常采用双上行方式,即将一台下游设备同时连接到两台上游设备,以最大限度地避免单点故障,提高网络可靠性。双上行组网虽然能提高网络可靠性,但又引入了环路问题。SMLK与MTLK的组网解决方案,由于配置简单、切换速度快而受到专业人士的青睐。
图1给出了现有的一种SMLK组和MTLK组的组网示意图,如图1所示,在设备C上有一个SMLK组,其中一个端口P4为主端口,另一个端口P5为从端口。正常情况下,只有P4处于Active状态,P5被阻塞,处于Standby状态。当处于Active状态的P4所在链路出现链路故障时,SMLK组会自动将该端口P4阻塞,并将原阻塞的处于Standby状态的端口P5切换到Active状态。
在设备B和设备D上,分别有一个MTLK组。在设备B上,P2为上行接口,P3为下行接口;在设备D上,P7为上行接口,P6为下行接口。通过监控P2和P7的Up/Down状态的变化来触发下行接口P3和P6的Up/Down状态的变化,从而触发下游设备上的SMLK组进行链路切换。
这样就可以简单高速地解决双上行链路的环路问题,从而有效支持了链路备份。
但是,现有技术中通过监控设备的上行接口,根据其Up/Down状态的变化来触发下行接口直接Up/Down状态的变化,过于简单粗暴。而且现场运用环境中,如图1中的设备B和设备D不可能只用来连接设备A和设备C,必然还会用来做其他连接使用。图2给出了现有的另一种SMLK组和MTLK组的组网示意图,如图2所示,设备Z通过设备B与上行设备X通信,设备W通过设备D与上行设备X通信。如图2中的设备Z和设备W,在P2和P7端口所在链路出现故障时,就会出现无法与上行设备X通信的情况。
发明内容
本发明提供双上行链路故障处理方法及设备,以在双上行链路故障时避免链路出现环路,同时使得周边设备正常通信。
本发明的技术方案是这样实现的:
一种双上行链路故障处理方法,该链路上配置了灵活链路SMLK组和监控链路MTLK组,该方法包括:
当双上行链路中配置了MTLK组的设备发现MTLK组的上行口从正常Up变为断掉Down时,先将该上行口阻塞,再将该组的下行口先断掉然后又立即恢复正常;
当双上行链路中配置了SMLK组的设备发现SMLK组的转发Active端口从正常Up变为断掉Down时,将该端口的状态变为待命Standby,并将原待命端口切换到转发状态,并从SMLK组当前处于转发状态的端口即转发端口发送刷新Flush报文,然后将SMLK组的状态置为非激活状态,且设定在非激活状态下,SMLK组的待命端口不阻塞任何报文。
所述将SMLK组的状态置为非激活状态之后进一步包括:
当所述配置了SMLK组的设备发现SMLK组的待命端口从断掉恢复正常时,从该端口发送刷新-连续性检测Flush-CC报文,然后从该SMLK组的转发端口查收该报文,判断是否查收到,若是,先将该SMLK组置为激活状态,然后再从该SMLK组的待命端口发送Flush报文;否则,只从该SMLK组的待命端口发送Flush报文,而保持SMLK组的非激活状态不变。
所述从该端口发送Flush-CC报文之后进一步包括:
当所述配置了MTLK组的设备从MTLK组的下行口接收到该Flush-CC报文时,将该报文从该组的上行口转发出去,即使上行口处于阻塞状态;
当所述配置了MTLK组的设备从MTLK组的上行口接收到该Flush-CC报文时,将该报文从下行口转发出去。
所述方法进一步包括:
当所述配置了SMLK组的设备发现SMLK组的待命端口从正常变为断掉时,将SMLK组置为非激活状态,且设定在非激活状态下,SMLK组的待命端口不阻塞任何报文。
所述从SMLK组的转发端口发送Flush报文之后进一步包括:
当所述配置了MTLK组的设备从MTLK组的下行口接收到该Flush刷新报文时,若该MTLK组的上行口正常且非阻塞,则将该报文直接从上行口转发出去,若该MTLK组的上行口正常且阻塞,则先清除该阻塞状态,然后将该报文从上行口转发出去。
所述方法进一步包括:
当所述配置了MTLK组的设备发现MTLK组的上行口从断掉变为正常时,将该MTLK组的下行口先断掉然后又立即恢复正常。
一种双上行链路系统,包括:配置了MTLK组的第一设备和配置了SMLK组的第二设备,其中:
第一设备:当发现MTLK组的上行口从正常Up变为断掉Down时,先将该上行口阻塞,再将该组的下行口先断掉然后又立即恢复正常;
第二设备:当发现SMLK组的转发端口从正常变为断掉时,将该端口的状态变为待命Standby,并将原待命端口切换到转发Active状态,从SMLK组当前处于转发状态的端口即转发端口发送刷新Flush报文,然后将SMLK组的状态置为非激活状态,且设定在非激活状态下,SMLK组的待命端口不阻塞任何报文。
所述第二设备进一步用于,当发现SMLK组的待命端口从断掉恢复正常时,从待命端口发送刷新Flush-连续性检测CC报文,然后从该SMLK组的转发端口查收该报文,判断是否查收到,若是,先将该SMLK组置为激活状态,然后再从该SMLK组的待命端口发送Flush报文;否则,只从该SMLK组的待命端口发送Flush报文,而保持SMLK组的非激活状态不变。
所述第一设备进一步用于,当从MTLK组的下行口接收到Flush-CC报文时,将该报文从该组的上行口转发出去,即使上行口处于阻塞状态;当从MTLK组的上行口接收到Flush-CC报文时,将该报文从下行口转发出去。
所述第二设备进一步用于,当发现SMLK组的待命端口从正常变为断掉时,将SMLK组置为非激活状态,且设定在非激活状态下,SMLK组的待命端口不阻塞任何报文。
所述第一设备进一步用于,当发现MTLK组的上行口从断掉变为正常时,将该MTLK组的下行口先断掉然后又立即恢复正常。
所述第一设备进一步用于,当从MTLK组的下行口接收到Flush报文时,若该MTLK组的上行口正常且非阻塞,则将该报文直接从上行口转发出去,若该MTLK组的上行口正常且阻塞,则先清除该阻塞状态,然后将该报文从上行口转发出去。
与现有技术相比,应用本发明后,在双上行链路故障时,能够避免链路出现环路,同时使得周边设备正常通信。
附图说明
图1为现有的一种SMLK组和MTLK组的组网示意图;
图2为现有的另一种SMLK组和MTLK组的组网示意图;
图3为本发明实施例一提供的双上行链路故障时,SMLK组的处理方法流程图;
图4为本发明实施例二提供的双上行链路故障时,MTLK组的处理方法流程图;
图5为本发明应用示例中双上行链路初始正常情况下的组网示意图;
图6为本发明应用示例中双上行链路故障处理后的组网示意图;
图7为本发明实施例一提供的双上行链路上的设备的组成示意图;
图8为本发明实施例提供的双上行链路系统的组成示意图。
具体实施方式
下面结合附图及具体实施例对本发明再作进一步详细的说明。
首先说明一下,本发明中,处于Standby状态的端口也简称为Standby端口,处于Active状态的端口也简称为Active端口。
以下分别给出双上行链路出现故障时,SMLK组和MTLK组的处理流程。
图3为本发明实施例一提供的双上行链路故障时,SMLK组的处理方法流程图,如图3所示,其具体步骤如下:
步骤300:初始时,SMLK组的主、从端口都Up,SMLK组处于激活状态。
步骤301:当SMLK组处于Active状态的端口从Up变为Down,将该端口的状态变为Standby,并将原阻塞的处于Standby状态的端口切换到Active状态。
步骤302:从SMLK组的新Active端口发送Flush报文用于刷新表项,然后将SMLK组的状态由激活状态变为非激活状态,且本发明设定在非激活状态下,SMLK组的standby端口不阻塞任何报文。
这里的表项指MAC地址转发表项和ARP表项,或者MAC地址转发表项、ARP表项和ND表项。
步骤303:当SMLK组处于Standby状态的端口从Down恢复Up时,立即从该端口发送一个Flush-CC报文,然后从该SMLK组的Active端口查收该报文。
当Flush-CC报文到达MTLK组时,相应的处理见图4所示实施例的步骤404、406。
步骤304:判断是否从SMLK组的Active端口收到了从该组的Standby端口发出去的Flush-CC报文,若是,执行步骤305;否则,执行步骤306。
步骤305:先将该SMLK组置为激活状态,然后再从该SMLK组的Standby端口发送一个Flush报文对链路的表项进行刷新,本流程结束。
当Flush报文到达MTLK组时,相应的处理见图4所示实施例的步骤405、406。
步骤306:从该SMLK组的Standby端口发送一个Flush报文对链路的表项进行刷新,保持SMLK组的非激活状态不变。
在实际应用中还存在这样一种情况:SMLK组的Standby端口从Up变为Down,此时,需要将SMLK组置为非激活状态。之后,当Standby端口从Down恢复Up时,则执行步骤303~306。
需要说明的是,由于SMLK组的Active端口肯定是处于Up状态的,所以不存在SMLK组的Active端口从Down变为Up的说法。
图4为本发明实施例二提供的双上行链路故障时,MTLK组的处理方法流程图,如图4所示,其具体步骤如下:
步骤401:当MTLK组的上行口从Up变为Down时,先将该上行口阻塞,再将该组的下行口先Down掉然后又立即恢复Up。
步骤402:当MTLK组的上行口从Down变为Up时,将该组的下行口先Down掉然后又立即恢复Up。
步骤403:当MTLK组的下行口从Up到Down或者从Down到Up时,MTLK组都不作任何特殊处理。
步骤404:当从MTLK组的下行口收到Flush-CC报文时,将该报文从该组的上行口转发出去,即使上行口处于阻塞状态。
当MTLK组的上行口处于阻塞状态下,本发明设定该上行口只能转发Flush-CC报文和Flush报文,其它报文则一律丢弃;同时对于flush报文,在转发之前需要先清除上行口的阻塞状态。
步骤405:当从MTLK组的下行口收到Flush报文时,会根据该报文刷新表项,同时,若该MTLK组的上行口Up且非阻塞,则将该报文直接从上行口转发出去,若该MTLK组的上行口Up且阻塞,则先清除该阻塞状态,然后将该报文从上行口转发出去,若该MTLK组的上行口Down,则丢弃该报文。
步骤406:当从MTLK组的上行口收到Flush报文或者Flush-CC报文时,只将该报文从下行口转发出去,不作其它处理。
需要说明的是,对于图4中的6个步骤,在实际执行时并没有严格的先后顺序,只要满足了某个步骤中设定的条件,就执行该步骤中对应的动作即可。
由于上、下行设备之间有可能经过多台设备而不是只有一台,所以本发明也支持中间多台设备的情况,为了更好地说明本发明,以下给出本发明的应用示例。
图5为本发明应用示例中双上行链路初始正常情况下的组网示意图,如图5所示,在设备D上配置SMLK组,在设备B、设备C、设备F和设备E上配置MTLK组。设备D上的SMLK组处于激活状态,且SMLK组的P6为主端口,处于Active状态,P7为从端口,处于Standby状态。设备B、设备C、设备F和设备E上的MTLK组的成员端口都处于Up且非阻塞的状态。其中,设备B上,P2为MTLK组的上行口,P3为MTLK组的下行口;设备C上,P4为MTLK组的上行口,P5为MTLK组的下行口;设备F上,P11为MTLK组的上行口,P10为MTLK组的下行口;设备E上,P9为MTLK组的上行口,P8为MTLK组的下行口。正常情况下,下行设备Z依次经过设备D、设备C、设备B、设备A与上行设备X进行通信;设备Y可以经过设备C、设备B、设备A与上行设备X进行通信,还可以经过设备C、设备D与下行设备Z进行通信;设备W可以经过设备E、设备F、设备A与上行设备X进行通信,还可以经过设备E、设备F、设备A、设备B、设备C、设备D与下行设备Z进行通信。
以下给出SMLK组、MTLK组的端口从Up变为Down以及从Down恢复为Up的处理流程示例。需要说明的是,设备E、F上的处理同设备C、B上的处理完全类同,以下仅给出设备C、B上的处理,对于设备E、F上的处理不再赘述。
(一)首先给出SMLK组的主端口从Up变为Down以及从Down恢复Up的处理流程示例:
当图5中的设备C的下行口P5从Up变为Down后,有以下设备需要作出以下处理:
1)设备C的P5从Up变为Down,会导致直连的端口P6也Down;
2)P6为设备D的SMLK组的主端口,处于Active状态,所以按照图3所示流程,设备D会首先将SMLK组的Active端口P6的状态变成Standby,将Standby端口P7的状态变成Active;
3)设备D从新的Active端口P7发送Flush报文用于刷新表项;
4)设备D将SMLK组置为非激活状态,且设定在非激活状态下,SMLK组的standby端口不阻塞任何报文。
图6为本发明应用示例中双上行链路故障处理后的组网示意图,经过上述1)~4)的处理后,此时,如图6所示,下行设备Z依次经过设备D、设备E、设备F、设备A与上行设备X进行通信;设备Y可以经过设备C、设备B、设备A与上行设备X进行通信,还可以经过设备C、设备B、设备A、设备F、设备E、设备D与下行设备Z进行通信;设备W可以经过设备E、设备F、设备A与上行设备X进行通信,还可以经过设备E、设备D与下行设备Z进行通信。设备D上的SMLK组处于非激活状态,P5、P6处于Down状态,设备C和设备B上的MTLK组都处于Up状态。
需要说明的是,对于MTLK组来说,MTLK组的状态是由其上行口的状态来决定的。例如:对设备C的MTLK组来说,虽然其下行口P5Down了,但是其上行口P4是Up且非阻塞的,这样,设备C的MTLK组的状态也是Up的。
当图6中的设备C的下行口P5从Down恢复为Up后,有以下设备需要作出以下处理:
1)设备C的下行口P5从Down变为Up,会导致直连的端口P6也Up;
2)P6为设备D的SMLK组的主端口,处于Standby状态,所以按照图3所示流程,首先会立即从该端口发送一个Flush-CC报文,从该组的Active端口P7查收报文;
3)若设备D从端口P7收到自己发出的Flush-CC报文,则先将SMLK组置为激活状态,此时端口P7依然处于Active状态,端口P6依然处于Standby状态;
配置有MTLK组的设备C和设备B接收到Flush-CC报文后,会将该报文从对应上行口P4、P2转发出去;
4)设备D再从端口P6发送一个Flush报文对链路的表项进行刷新。
该Flush报文到达设备C、设备B时,设备C、设备B根据该报文刷新表项,同时直接将该报文从上行口P4、P2转发出去。由于上行口P4、P2都未被阻塞,因此,无需作清除上行口的阻塞状态的操作。
此时,如图6所示,下行设备Z依次经过设备D、设备E、设备F、设备A与上行设备X进行通信;设备Y可以经过设备C、设备B、设备A与上行设备X进行通信,还可以经过设备C、设备B、设备A、设备F、设备E、设备D与下行设备Z进行通信;设备W可以经过设备E、设备F、设备A与上行设备X进行通信,还可以经过设备E、设备D与下行设备Z进行通信。设备D上的SMLK组处于激活状态,端口P6处于Standby状态;设备C和设备B上的MTLK组都处于Up状态。
(二)其次给出MTLK组的上行口从Up变为Down以及从Down恢复Up的处理流程。
当图5中的设备B的上行口P2从Up变为Down后,有以下设备需要作出以下处理:
1)设备B的上行口P2从Up变为Down,且P2为设备B的MTLK组的上行口,所以按照图4所示流程,会先将上行口P2阻塞掉,将下行口P3先Down掉,然后又立即Up起来;
2)当设备B的下行口P3迅速Down掉然后又立即Up时,设备C的上行口P4也会从Up变为Down,然后再Up起来,且P4为设备C的MTLK组的上行口,所以按照图4所示流程,会先将上行口P4阻塞掉,将下行口P5先Down掉,然后又立即Up起来;
3)当设备C的下行口P5迅速Down掉然后又立即Up时,设备D的端口P6也会从Up变为Down,然后再Up,且P6为设备D的SMLK组的主端口,处于Active状态,所以按照图3所示流程,会首先将SMLK组的Active端口P6变成Standby状态,Standby端口P7会变成Active状态;
4)设备D从新的Active端口P7发送Flush报文用于刷新表项;
5)设备D将SMLK组置为非激活状态;
6)当设备C的下行口P5再次Up时,设备D的端口P6也随之Up,由于P6为SMLK组的主端口,处于Standby状态,所以按照图3所示流程,首先会立即从该端口发送一个Flush-CC报文,然后从该组的Active端口P7查收报文;
配置有MTLK组的设备C和设备B接收到Flush-CC报文后,将该报文从对应上行口P4、P2转发出去;
7)由于上行口P2Down了,所以设备D没有从端口P7收到自己发出的Flush-CC报文,则再从端口P6发送一个Flush报文对链路的表项进行刷新。
当该Flush报文到达设备C时,设备C会根据该报文刷新表项,同时由于MTLK组的上行口P4Up且阻塞,则先清除上行口P4的阻塞状态,然后将该报文从上行口P4转发出去;当该Flush报文到达设备B时,设备B根据该报文刷新表项,同时由于上行口P2Down了,所以设备B不会作转发报文的操作,也不会作清除上行口P2的阻塞状态的操作。
此时,如图6所示,下行设备Z依次经过设备D、设备E、设备F、设备A与上行设备X进行通信;设备Y可以经过设备C、设备D、设备E、设备F、设备A与上行设备X进行通信,还可以经过设备C、设备D与下行设备Z进行通信;设备W可以经过设备E、设备F、设备A与上行设备X进行通信,还可以经过设备E、设备D与下行设备Z进行通信。设备D上的SMLK组处于非激活状态,P1、P2处于Down状态,设备B上的MTLK组处于Down状态同时上行口为Down且阻塞的状态,设备C上的MTLK组处于Up状态。
当图6中的设备B的上行口P2从Down恢复为Up后,有以下设备需要作出以下处理:
1)设备B的上行口P2从Down恢复为Up,且P2为设备B的MTLK组的上行口,所以按照图4所示流程,会将下行口P3Down掉,然后又立即Up起来;
2)当设备B的P3迅速Down掉然后又立即Up起来时,设备C的P4也会从Up变为Down,然后再立即Up起来,且P4为设备C的MTLK组的上行口,所以按照图4所示流程,会先将上行口P4阻塞掉,将下行口P5Down掉,然后又立即Up起来;
3)当设备C的P5迅速Down掉然后又立即Up起来时,设备D的P6也会从Up变为Down,然后再Up起来,且P6为设备D的SMLK组的主端口,处于Standby状态,所以按照图3所示流程,当P6从Up变为Down时,只将设备D的SMLK组置为非激活状态即可,不作其它处理;
4)当P6从Down恢复为Up时,首先会立即从该端口发送一个Flush-CC报文,然后从该组的Active端口P7查收该报文;
配置有MTLK组的设备C和设备B接收到该Flush-CC报文后,会将该报文从对应上行口P4、P2转发出去;
5)设备D从端口P7收到自己发出去的Flush-CC报文,先将SMLK组置为激活状态,此时,端口P7依然处于Active状态,端口P6依然处于Standby状态;
6)设备D从Standby端口P6发送一个Flush报文对链路的表项进行刷新。
当该Flush报文到达设备C时,设备C会根据该报文刷新表项,同时由于MTLK组的上行口P4Up且非阻塞,则直接将该报文从上行口P4转发出去;当该Flush报文到达设备B时,设备B会根据该报文刷新表项,同时由于MTLK组的上行口P2Up且阻塞,则先清除上行口P2的阻塞状态,然后将该报文从上行口P2转发出去。
此时,如图6所示,下行设备Z依次经过设备D、设备E、设备F、设备A与上行设备X进行通信;设备Y可以经过设备C、设备B、设备A与上行设备X进行通信,还可以经过设备C、设备B、设备A、设备F、设备E、设备D与下行设备Z进行通信;设备W可以经过设备E、设备F、设备A与上行设备X进行通信,还可以经过设备E、设备D与下行设备Z进行通信。设备D上的SMLK组处于激活状态,P6处于Standby状态。设备C和设备B上的MTLK组都处于Up状态。
由上述示例可以看出:应用本发明后,当双上行链路出现故障后,链路中不会出现环路,同时链路周边的设备如:设备X、Y、Z、W之间仍可正常通信。例如:当MTLK组的上行口Down后,由于下行口会先Down然后又立即Up起来,因此不会出现MTLK组的上、下行口同时Down的情况,保证了链路周边设备仍可正常通信;同时,当SMLK组的Active端口down时,不阻塞新Standby端口的报文转发,从而保证了链路通信不中断,如:当图5中设备B的端口P2Down时,由于SMLK组的端口P6即使是Standby状态但不阻塞报文,因此,整个链路仍是通的,链路周边设备仍可正常通信。
图7为本发明实施例一提供的双上行链路上的设备的组成示意图,该设备配置了SMLK组,如图7所示,该设备包括:端口监测模块71和表项刷新触发模块72,其中:
端口监测模块71:当发现SMLK组的Active端口从Up变为Down时,将该端口的状态变为Standby,并将原Standby端口切换到Active状态,向表项刷新触发模块72发送表项刷新指示;当发现SMLK组的Standby端口从Down恢复Up时,向表项刷新触发模块72发送Flush-CC指示;当发现SMLK组的Standby端口从Up变为Down时,将SMLK组置为非激活状态。
表项刷新触发模块72:当接收到端口监测模块71发来的表项刷新指示时,从SMLK组的新Active端口发送Flush报文用于刷新链路的表项,然后将SMLK组的状态置为非激活状态,且设定在非激活状态下,SMLK组的Standby端口不阻塞任何报文;当接收到端口监测模块71发来的Flush-CC指示时,从Standby端口发送Flush-CC报文,然后从该SMLK组的Active端口查收该报文,判断是否查收到,若是,先将该SMLK组置为激活状态,然后再从该SMLK组的Standby端口发送Flush报文对链路的表项进行刷新;否则,只从该SMLK组的Standby端口发送Flush报文,而保持SMLK组的非激活状态不变。
以下给出本发明实施例二提供的双上行链路上的设备的组成,该设备配置了MTLK组,该设备包括:上行口监测模块和表项刷新处理模块,其中:
上行口监测模块:当发现MTLK组的上行口从Up变为Down时,先将该上行口阻塞,再将该组的下行口先Down然后又立即恢复Up;当发现MTLK组的上行口从Down变为Up时,将该组的下行口先Down然后又立即恢复Up。
表项刷新处理模块:当从MTLK组的下行口接收到Flush报文时,根据该报文刷新表项,同时,若该MTLK组的上行口Up且非阻塞,则将该报文直接从上行口转发出去,若该MTLK组的上行口Up且阻塞,则先清除该阻塞状态,然后将该报文从上行口转发出去,若该MTLK组的上行口Down,则丢弃该报文;当从MTLK组的上行口接收到Flush报文,只将该报文从下行口转发出去;当从MTLK组的下行口接收到Flush-CC报文时,将该报文从该组的上行口转发出去,即使上行口处于阻塞状态;当从MTLK组的上行口接收到Flush-CC报文时,将该报文转发出去。
图8为本发明实施例提供的双上行链路系统的组成示意图,如图8所示,其主要包括:配置了MTLK组的第一设备81和配置了SMLK组的第二设备82,其中:
第一设备:当发现MTLK组的上行口从Up变为Down时,先将该上行口阻塞,再将该组的下行口先Down掉然后又立即Up起来;当发现MTLK组的上行口从Down变为Up时,将该组的下行口先Down掉然后又立即Up起来;当从MTLK组的下行口接收到Flush报文时,根据该报文刷新表项,同时,若该MTLK组的上行口Up且非阻塞,则将该报文直接从上行口转发出去,若该MTLK组的上行口Up且阻塞,则先清除该阻塞状态,然后将该报文从上行口转发出去;当从MTLK组的下行口接收到Flush-CC报文时,将该报文从该组的上行口转发出去,即使上行口处于阻塞状态,当从MTLK组的上行口接收到Flush-CC报文时,将该报文从下行口转发出去。
第二设备:当发现SMLK组的Active端口从Up变为Down时,将该端口的状态变为Standby,并将原Standby端口切换到Active状态,从SMLK组当前Active端口发送Flush报文用于刷新链路的表项,然后将SMLK组的状态置为非激活状态,且设定在非激活状态下,SMLK组的Standby端口不阻塞任何报文;当发现SMLK组的Standby端口从Down恢复为Up时,从Standby端口发送Flush-CC报文,然后从该SMLK组的Active端口查收该报文,判断是否查收到,若是,先将该SMLK组置为激活状态,然后再从该SMLK组的Standby端口发送Flush报文对链路的表项进行刷新;否则,只从该SMLK组的Standby端口发送Flush报文,而保持SMLK组的非激活状态不变;当发现SMLK组的Standby端口从Up变为Down时,将SMLK组置为非激活状态。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。

Claims (12)

1.一种双上行链路故障处理方法,该链路上配置了灵活链路SMLK组和监控链路MTLK组,其特征在于,该方法包括:
当双上行链路中配置了MTLK组的设备发现MTLK组的上行口从正常Up变为断掉Down时,先将该上行口阻塞,再将该组的下行口先断掉然后又立即恢复正常;
当双上行链路中配置了SMLK组的设备发现SMLK组的转发Active端口从正常Up变为断掉Down时,将该端口的状态变为待命Standby,并将原待命端口切换到转发状态,并从SMLK组当前处于转发状态的端口即转发端口发送刷新Flush报文,然后将SMLK组的状态置为非激活状态,且设定在非激活状态下,SMLK组的待命端口不阻塞任何报文。
2.根据权利要求1所述的方法,其特征在于,所述将SMLK组的状态置为非激活状态之后进一步包括:
当所述配置了SMLK组的设备发现SMLK组的待命端口从断掉恢复正常时,从该端口发送刷新-连续性检测Flush-CC报文,然后从该SMLK组的转发端口查收该报文,判断是否查收到,若是,先将该SMLK组置为激活状态,然后再从该SMLK组的待命端口发送Flush报文;否则,只从该SMLK组的待命端口发送Flush报文,而保持SMLK组的非激活状态不变。
3.根据权利要求2所述的方法,其特征在于,所述从该端口发送Flush-CC报文之后进一步包括:
当所述配置了MTLK组的设备从MTLK组的下行口接收到该Flush-CC报文时,将该报文从该组的上行口转发出去,即使上行口处于阻塞状态;
当所述配置了MTLK组的设备从MTLK组的上行口接收到该Flush-CC报文时,将该报文从下行口转发出去。
4.根据权利要求2所述的方法,其特征在于,所述方法进一步包括:
当所述配置了SMLK组的设备发现SMLK组的待命端口从正常变为断掉时,将SMLK组置为非激活状态,且设定在非激活状态下,SMLK组的待命端口不阻塞任何报文。
5.根据权利要求1所述的方法,其特征在于,所述从SMLK组的转发端口发送Flush报文之后进一步包括:
当所述配置了MTLK组的设备从MTLK组的下行口接收到该刷新Flush报文时,若该MTLK组的上行口正常且非阻塞,则将该报文直接从上行口转发出去,若该MTLK组的上行口正常且阻塞,则先清除该阻塞状态,然后将该报文从上行口转发出去。
6.根据权利要求1所述的方法,其特征在于,所述方法进一步包括:
当所述配置了MTLK组的设备发现MTLK组的上行口从断掉变为正常时,将该MTLK组的下行口先断掉然后又立即恢复正常。
7.一种双上行链路系统,其特征在于,包括:配置了MTLK组的第一设备和配置了SMLK组的第二设备,其中:
第一设备:当发现MTLK组的上行口从正常Up变为断掉Down时,先将该上行口阻塞,再将该组的下行口先断掉然后又立即恢复正常;
第二设备:当发现SMLK组的转发端口从正常变为断掉时,将该端口的状态变为待命Standby,并将原待命端口切换到转发Active状态,从SMLK组当前处于转发状态的端口即转发端口发送刷新Flush报文,然后将SMLK组的状态置为非激活状态,且设定在非激活状态下,SMLK组的待命端口不阻塞任何报文。
8.根据权利要求7所述的系统,其特征在于,所述第二设备进一步用于,当发现SMLK组的待命端口从断掉恢复正常时,从待命端口发送刷新Flush-连续性检测CC报文,然后从该SMLK组的转发端口查收该报文,判断是否查收到,若是,先将该SMLK组置为激活状态,然后再从该SMLK组的待命端口发送Flush报文;否则,只从该SMLK组的待命端口发送Flush报文,而保持SMLK组的非激活状态不变。
9.根据权利要求8所述的系统,其特征在于,所述第一设备进一步用于,当从MTLK组的下行口接收到Flush-CC报文时,将该报文从该组的上行口转发出去,即使上行口处于阻塞状态;当从MTLK组的上行口接收到Flush-CC报文时,将该报文从下行口转发出去。
10.根据权利要求8所述的系统,其特征在于,所述第二设备进一步用于,当发现SMLK组的待命端口从正常变为断掉时,将SMLK组置为非激活状态,且设定在非激活状态下,SMLK组的待命端口不阻塞任何报文。
11.根据权利要求8所述的系统,其特征在于,所述第一设备进一步用于,当发现MTLK组的上行口从断掉变为正常时,将该MTLK组的下行口先断掉然后又立即恢复正常。
12.根据权利要求8所述的系统,其特征在于,所述第一设备进一步用于,当从MTLK组的下行口接收到Flush报文时,若该MTLK组的上行口正常且非阻塞,则将该报文直接从上行口转发出去,若该MTLK组的上行口正常且阻塞,则先清除该阻塞状态,然后将该报文从上行口转发出去。
CN201210437342.0A 2012-11-06 2012-11-06 双上行链路故障处理方法及设备 Active CN102932183B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201210437342.0A CN102932183B (zh) 2012-11-06 2012-11-06 双上行链路故障处理方法及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201210437342.0A CN102932183B (zh) 2012-11-06 2012-11-06 双上行链路故障处理方法及设备

Publications (2)

Publication Number Publication Date
CN102932183A CN102932183A (zh) 2013-02-13
CN102932183B true CN102932183B (zh) 2015-03-18

Family

ID=47646890

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201210437342.0A Active CN102932183B (zh) 2012-11-06 2012-11-06 双上行链路故障处理方法及设备

Country Status (1)

Country Link
CN (1) CN102932183B (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103152262B (zh) * 2013-02-25 2016-08-03 华为技术有限公司 一种连接建立的方法和设备
WO2014139175A1 (zh) * 2013-03-15 2014-09-18 华为技术有限公司 双上行相切环收敛的方法、设备和系统
CN103618630B (zh) * 2013-12-06 2017-09-12 北京东土科技股份有限公司 一种基于双上行链路的数据安全传输方法及设备
CN107948105B (zh) * 2018-01-02 2020-08-25 联想(北京)有限公司 控制设备的端口状态的方法和系统
CN109194592B (zh) * 2018-09-25 2021-06-25 盛科网络(苏州)有限公司 一种解决multi-link网络中孤岛问题的方法和系统
CN115941590B (zh) * 2023-03-02 2023-05-16 新华三工业互联网有限公司 双上行组网的流量转发方法、装置及系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101414972A (zh) * 2008-11-18 2009-04-22 福建星网锐捷网络有限公司 信息更新方法及其更新装置
CN101465813A (zh) * 2009-01-08 2009-06-24 杭州华三通信技术有限公司 一种主备链路切换方法、环形组网及交换设备
US7602706B1 (en) * 2003-05-15 2009-10-13 Cisco Technology, Inc. Inter-ring protection for shared packet rings
CN101616066A (zh) * 2008-06-27 2009-12-30 中兴通讯股份有限公司 用于双上行组网的切换方法
CN101640644A (zh) * 2009-09-01 2010-02-03 杭州华三通信技术有限公司 基于灵活链路组的流量均衡方法和设备
CN102340392A (zh) * 2010-07-26 2012-02-01 杭州华三通信技术有限公司 一种提高无源光网络系统中业务可靠性的方法和系统
CN102412984A (zh) * 2011-10-24 2012-04-11 杭州华三通信技术有限公司 一种转发表项的管理方法和设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090262790A1 (en) * 2008-04-17 2009-10-22 Alcatel Lucent Method of recovery from active port tx failure in y-cable protected pair

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7602706B1 (en) * 2003-05-15 2009-10-13 Cisco Technology, Inc. Inter-ring protection for shared packet rings
CN101616066A (zh) * 2008-06-27 2009-12-30 中兴通讯股份有限公司 用于双上行组网的切换方法
CN101414972A (zh) * 2008-11-18 2009-04-22 福建星网锐捷网络有限公司 信息更新方法及其更新装置
CN101465813A (zh) * 2009-01-08 2009-06-24 杭州华三通信技术有限公司 一种主备链路切换方法、环形组网及交换设备
CN101640644A (zh) * 2009-09-01 2010-02-03 杭州华三通信技术有限公司 基于灵活链路组的流量均衡方法和设备
CN102340392A (zh) * 2010-07-26 2012-02-01 杭州华三通信技术有限公司 一种提高无源光网络系统中业务可靠性的方法和系统
CN102412984A (zh) * 2011-10-24 2012-04-11 杭州华三通信技术有限公司 一种转发表项的管理方法和设备

Also Published As

Publication number Publication date
CN102932183A (zh) 2013-02-13

Similar Documents

Publication Publication Date Title
CN102932183B (zh) 双上行链路故障处理方法及设备
CN102394787B (zh) 基于epa交换机的双链路冗余控制方法
CN102904818B (zh) 一种arp信息表项更新方法及装置
JP6076373B2 (ja) 相互接続ノードの状態変化に対応する技術
CN102098201B (zh) 一种实现l2tp用户接入备份的方法及网络系统
US9218230B2 (en) Method for transmitting messages in a redundantly operable industrial communication network and communication device for the redundantly operable industrial communication network
CN100454880C (zh) 一种实现环网保护的方法及系统
JP2011504693A (ja) 産業用イーサネットネットワークに基づいた故障処理方法、システム、および交換装置
CN102255757B (zh) 一种链路切换方法及其装置
CN101079781A (zh) 一种工业以太网快速冗余的实现方法
CN101227371B (zh) 同级交换机设备间的备份切换方法和装置
CN102055658B (zh) 快速环网保护协议单环组网中实现故障保护的方法及设备
CN103107940B (zh) 用于设备级环网的冗余网关系统
CN102891769A (zh) 链路故障通告方法和设备
CN101873244A (zh) 一种多环路自动保护的方法
CN103607293A (zh) 一种流量保护方法及设备
CN104135417A (zh) 一种以太环网链路中断快速恢复的方法及相应的以太环网
US8959386B2 (en) Network and expansion unit and method for operating a network
KR101825030B1 (ko) PoE를 이용한 링 네트워크 장치, 시스템 및 네트워크 장애 복구 방법
CN100484044C (zh) 检测默认网关工作状态的方法及其装置
CN101641915B (zh) 重构通信网络的方法
RU2563142C2 (ru) Система базовых станций для железнодорожного применения и способ формирования сети базовых станций
CN109600290A (zh) 一种环形网络中多主共存的方法
CN101848128B (zh) 在多个环形拓扑间实现稳定通信的方法、系统及拓扑结构
JP5527613B2 (ja) ネットワーク中継システム及びネットワーク中継システムの障害検知方法

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: 20230602

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