CN101552725B - 聚合子链路恢复处理方法、***及设备 - Google Patents
聚合子链路恢复处理方法、***及设备 Download PDFInfo
- Publication number
- CN101552725B CN101552725B CN2009100839665A CN200910083966A CN101552725B CN 101552725 B CN101552725 B CN 101552725B CN 2009100839665 A CN2009100839665 A CN 2009100839665A CN 200910083966 A CN200910083966 A CN 200910083966A CN 101552725 B CN101552725 B CN 101552725B
- Authority
- CN
- China
- Prior art keywords
- port
- equipment
- state
- sublink
- transmit
- 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
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了聚合子链路恢复处理方法、***及设备。方法包括:为每个处于up状态的端口,在发送方向和接收方向分别定义两种状态:丢弃和转发;当第一设备发现本设备上聚合子链路的第一端口变为up状态时,将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向第二设备发送端口状态查询报文;第二设备接收端口状态查询报文,若发现本第二设备上所述聚合子链路的第二端口的接收方向的状态为转发,则向第一设备返回响应报文;第一设备接收所述响应报文,将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量。本发明可以消除聚合子链路恢复过程中的丢包现象。
Description
技术领域
本发明涉及链路聚合技术领域,具体涉及聚合子链路恢复处理方法、***及设备。
背景技术
在以太网交换领域,链路聚合技术有着非常广泛的应用。链路聚合指的是将多条物理链路绑定成一条逻辑链路(也称为聚合组)以创建更高带宽的接口。转发到聚合组的数据流量会在各个成员物理链路(也称为子链路)上负载分担,这样可以得到相当于各个子链路带宽之和的有效带宽。
除了能够提供高带宽,链路聚合技术还有一个重要作用,就是提供网络的高可靠性。聚合组内的各个子链路之间起着相互备份的作用,某个子链路出现故障(down)后,流量会重新负载分担到其它子链路,整个聚合组的流量转发并不会中断;当该子链路重新恢复正常(up)后,又会参与聚合组流量的负载分担。
图1-1-图1-4给出了现有技术一的聚合子链路恢复过程的处理方案。
如图1-1所示,设备A的四个端口P1~P4形成聚合组,设备B的四个端口P5~P8形成聚合组。初始时,P1和P5之间的链路处于故障(down)状态,其它三条链路处于正常(up)状态且为转发(forwarding)状态。这样,在设备A的交换芯片上聚合组实际只包含P2~P4三个端口,在设备B的交换芯片上聚合组实际只包含P6~P8三个端口。上行数据流会负载分担到P6~P8三个端口;同样地,下行数据流会负载分担到P2~P4三个端口。
某个时刻,连接P1和P5之间的链路恢复,即处于up状态,则在设备A、B上的P1和P5会加入各自的聚合组,并对流量进行负载分担。
这里以设备A为例来说明设备对聚合组的一个端口从down到up的处理过程,具体包括如下步骤01~03:
01:如图1-2所示,当端口P1由down变成up时,P1的状态先为丢弃(discarding)。这是因为:为防止二层环路的产生,端口由down变成up时,初始状态必须为discarding。
02:如图1-3所示,设备A发现P1的状态为up,则将P1加入交换芯片上的聚合组,这样交换芯片上的聚合组实际包含P1~P4四个端口,下行流量由P1~P4四个端口进行负载分担。但是,因为P1此时的状态是discarding,所以转发到此端口的流量会被交换芯片丢弃。
03:在P1加入聚合组后,设备A将P1的状态设置成forwarding,P1开始正常转发流量。
经过上述步骤01~03后,设备A对端口P1的恢复处理过程完成。设备B对端口P5的恢复处理过程与设备A相同。当设备A和B都完成恢复处理时,链路P1-P5进入到正常的数据转发状态。此时的***状态如图1-4所示。
从上述过程可以看出,聚合子链路恢复过程中,上、下行流量必然存在丢包问题,主要原因有两个:
第一,步骤02已完成而步骤03还未完成时会丢包。因为此时P1已加入聚合组并对流量进行负载分担,而此时P1的状态仍然为discarding,所以转发到P1的流量会被芯片丢弃,如图1-3所示。
第二,设备A和B对链路恢复的处理在时间上总会有先后,当一端处理已完成,但是另一端还没有处理完成时,从一台设备发出的流量到达另一台设备后就可能被丢弃。此时的***状态如图1-5所示:P1向P5发送的下行流量会被P5丢弃。
申请号为200810211996.5的专利申请提供了另一种聚合子链路恢复处理方案,具体如下:
设备A和设备B之间具有聚合链路,其中一条聚合子链路在设备A上的端口为a,在设备B上的端口为b,该聚合子链路down,且在某个时刻,端口a变为up,则:
设备A发现端口a的状态为up时,则设备A通过端口a向设备B的端口b发送一条端口状态更新报文。而此时,设备B的端口b可能已经处于up状态且已被设备B获知,也可能处于其它状态,则:
一、若端口b已经处于up状态且已被设备B获知,则端口b可以接收到设备A发来的端口状态更新报文,从而确认端口a已经处于up状态,则设备B通过端口b向端口a回复响应报文。端口a收到所述响应报文后,确认端口b也处于up状态。
经过上述过程,端口a、b都可确认对方端口都处于up状态,则设备A、B同时向平台模块上报端口状态变化信息,平台模块根据该端口状态变化信息进行运算,更新端口a、b为Selected状态。
二、若端口b未处于所述“已经处于up状态且已被设备B获知”的状态,则设备B无法收到设备a发来的端口状态更新报文,因此也不会向设备A发送响应报文,此时,端口a进入等待状态,等待设备B主动发来的端口状态更新报文。
此后,当设备B的端口b进入up状态且已被设备B获知时,设备B主动通过端口b向端口a发送端口状态更新报文,由于此时端口a已经处于up状态且已被设备A获知,则端口a会收到端口b发来的端口状态更新报文,并向端口b回复响应报文。
经过上述过程,端口a、b都可确认对方端口都处于up状态,则设备A、B同时向平台模块上报端口状态变化信息,平台模块根据该端口状态变化信息进行运算,更新端口a、b为Selected状态。
上述申请的缺点是:由于只有端口的状态为“Selected”后,转发到该端口上的流量才不会丢失,而,平台模块在设置端口a、b的Selected状态时,设置时间上可能会有先后,这样就可能产生丢包现象。例如:若端口a先被设置为Selected状态,而端口b后被设置为Selected状态,则端口a转发到端口b上的流量就有可能丢失。
发明内容
本发明提供聚合子链路恢复处理方法、***及设备,以消除聚合子链路恢复过程中的丢包现象。
本发明的技术方案是这样实现的:
一种聚合子链路恢复处理方法,为每个处于正常状态的端口,在发送方向和接收方向上分别定义两种状态:丢弃和转发,该方法包括:
第一设备发现本设备上聚合子链路的第一端口变为正常状态,则将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向第二设备发送端口状态查询报文;
第二设备接收端口状态查询报文,若发现本第二设备上所述聚合子链路的第二端口的接收方向的状态为转发,则向第一设备返回响应报文;
第一设备接收所述响应报文,将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量。
所述第二设备接收端口状态查询报文之后进一步包括:
第二设备发现本设备上所述聚合子链路的第二端口的接收方向的状态为丢弃,则等待至第二端口的接收方向的状态为转发时,向第一设备返回响应报文。
所述方法进一步包括:预设一等待时长,
所述第一设备向第二设备发送端口状态查询报文之后进一步包括:第一设备在预设等待时长内未收到第二设备发来的响应报文,则重复向第二设备发送端口状态查询报文。
所述第一设备重复向第二设备发送端口状态查询报文之后进一步包括:
第一设备发现重复预设次数发送端口状态查询报文后,仍未收到第二设备发来的响应报文,则自动将第一端口的发送方向的状态设置为:转发。
一种聚合子链路恢复处理***,该***包括:
第一设备,发现本设备上聚合子链路的第一端口变为正常状态,则将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向第二设备发送端口状态查询报文;接收第二设备发来的响应报文,将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量;
第二设备,从聚合子链路的第二端口接收第一设备发来的端口状态查询报文,若发现第二端口的接收方向的状态为转发,则向第一设备返回响应报文。
一种聚合子链路恢复处理设备,该设备包括:
第一模块,发现本设备上聚合子链路的第一端口变为正常状态,则将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向对端设备发送端口状态查询报文;
第二模块,从聚合子链路的第一端口接收对端设备发来的响应报文,将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量。
所述第一模块进一步用于,在向对端设备发送端口状态查询报文的同时,向定时模块发送启动指示;
且,所述设备进一步包括:
定时模块,接收启动指示后,开始计时;在定时时长到达后,向第二模块发送定时到达指示;
且,所述第二模块进一步用于,若在接收到定时到达指示时,未从聚合子链路的第一端口接收到对端设备发来的响应报文,则重复向对端设备发送端口状态查询报文。
所述设备进一步包括:
第三模块,从第一端口接收对端设备发来的端口状态查询报文,若发现第一端口接收方向的状态为:转发,则向对端设备返回响应报文。
所述第三模块包括:
第三子模块,从第一端口接收对端设备发来的端口状态查询报文,若发现第一端口的接收方向的状态为转发,则向第四子模块发送响应指示;若发现第一端口的接收方向的状态为丢弃,则等待至第一端口的接收方向的状态为转发时,向第四子模块发送响应指示;
第四子模块,当接收到第三子模块发来的响应指示时,向对端设备返回响应报文。
所述设备进一步包括:
计数模块,对第二模块重复发送端口状态查询报文的次数进行计数,当计数值到达预设次数时,向第二模块发送转发状态自动设置指示;
且,所述第二模块进一步用于,当收到计数模块发来的转发状态自动设置指示时,将聚合子链路的第一端口的发送方向的状态设置为:转发。
与现有技术相比,本发明为每个处于up状态的端口,在发送方向和接收方向上分别定义两种状态:丢弃和转发;当第一设备发现本设备上聚合子链路的第一端口变为up状态时,将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向第二设备发送端口状态查询报文;第二设备接收端口状态查询报文,若发现本第二设备上所述聚合子链路的第二端口的接收方向的状态为转发,则向第一设备返回响应报文;第一设备接收所述响应报文,将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量。本发明可以消除聚合子链路恢复过程中的丢包现象。
附图说明
图1-1为现有技术一的聚合子链路恢复过程的示意图一;
图1-2为现有技术一的聚合子链路恢复过程的示意图二;
图1-3为现有技术一的聚合子链路恢复过程的示意图三;
图1-4为现有技术一的聚合子链路恢复过程的示意图四;
图1-5为现有技术一的聚合子链路恢复过程的示意图五;
图2为本发明实施例提供的聚合子链路恢复处理流程图;
图3-1为应用本发明实施例的聚合子链路恢复过程的示意图一;
图3-2为应用本发明实施例的聚合子链路恢复过程的示意图二;
图3-3为应用本发明实施例的聚合子链路恢复过程的示意图三;
图3-4为应用本发明实施例的聚合子链路恢复过程的示意图四;
图3-5为应用本发明实施例的聚合子链路恢复过程的示意图五;
图4为本发明实施例提供的聚合子链路恢复处理***组成图。
具体实施方式
下面结合附图及具体实施例对本发明再作进一步详细的说明。
图2为本发明实施例提供的聚合子链路恢复处理流程图,如图2所示,本实施例中,设定设备A和B之间具有聚合链路,其中一条聚合子链路在设备A、B上的端口分别为端口a、b,其具体步骤如下:
步骤201:对于每个处于up状态的端口,在发送方向和接收方向分别定义如下状态:
发送方向:发送丢弃(Tx discarding)状态、发送转发(Tx forwarding)状态;
接收方向:接收丢弃(Rx discarding)状态、接收转发(Rx forwarding)状态。
其中,Tx discarding表示端口的发送方向处于discarding状态,即:端口虽处于up状态,但此时该端口还不被允许向外转发流量;
Tx forwarding表示端口的发送方向处于forwarding状态,即:端口处于up状态,且被允许向外转发流量;
Rx discarding表示端口的接收方向处于discarding状态,即:端口虽处于up状态,但不被允许接收流量,即此时转发给该端口的流量会被丢弃;
Rx forwarding表示端口的接收方向处于forwarding状态,即:端口处于up状态,且被允许接收流量,即转发给该端口的流量不会被丢弃。
对于每个处于up状态的端口,在该端口的发送方向和接收方向分别对应一个状态。对于发送方向,该状态为Tx discarding或者Tx forwarding;对于接收方向,该状态为Rx discarding或者Rx forwarding。
步骤202:预先设定处于Tx discarding状态的聚合子链路端口不分担聚合组的流量。
步骤203:设备A发现聚合子链路的一个端口a的状态由down变为up,则将端口a的发送方向的状态设置为Tx discarding、接收方向的状态设置为Rx discarding,并将端口a加入聚合组。
只要一个设备发现本设备的聚合子链路的端口up,就会将该端口的发送方向的状态先设置为Tx discarding、接收方向的状态先设置为Rxdiscarding。
本步骤中,虽然端口a加入了聚合组,但是由于其发送方向的状态为Tx discarding,因此,端口a并不分担聚合组的流量。
步骤204:设备A发现端口a已准备好转发流量、需要将端口a的发送方向的状态变为Tx forwarding,则向设备B的端口b发送端口状态查询报文。
步骤205:设备B的端口b收到端口状态查询报文,判断端口b的接收方向的状态是否为Rx forwarding,若是,执行步骤207;否则,执行步骤206。
对于一个聚合子链路端口来说,当该端口up后,若该端口所在设备发现该端口已作好了接收流量的准备,则设备会将该端口的接收方向的状态由Rx discarding变为Rx forwarding。
步骤206:设备B继续等待,当端口b的接收方向处于Rx forwarding状态时,执行步骤207。
步骤207:设备B通过端口b向端口a返回响应报文,设备A收到响应报文,将端口a的发送方向的状态更改为Tx forwarding,开始向端口b转发流量。
端口的状态变为Tx forwarding时,该端口开始分担聚合组的流量。
实际中,为了不让设备A无限期地等待设备B的响应报文,可作如下处理:预设一等待时长,若在预设等待时长内设备A未收到设备B发来的响应报文,则设备A重复向设备B发送端口状态查询报文,若重复预设次数发送端口状态查询报文后仍未收到设备B发来的响应报文,则设备A自动将端口a的状态更改为Tx forwarding。
需要说明的是,当设备A通过端口a向设备B的端口b发送端口状态查询报文时,设备B的端口b也可能还未处于up状态,此时,该报文不会到达设备B,则设备A发现在预设等待时长内未收到设备B发来的响应报文,会重复向设备B发送端口状态查询报文,若连续预定次数未收到设备A发来的响应报文,则设备A自动将端口a的状态更改为Tx forwarding。
由上述过程可以看出:对于聚合子链路两端的端口来说,当聚合子链路端口的状态为Tx discarding时,该端口不分担聚合组的流量;只有确认了对端端口的接收方向处于Rx forwarding状态后,本端端口的发送方向的状态才会被设置为Tx forwarding,即:只有在确认了对端端口已经作好接收流量的准备后,本端端口才开始分担聚合组的流量,这样,就避免了一方聚合子链路端口还未作好接收流量的准备、而对方端口已经开始发送流量的现象,完全消除了丢包现象的发生。
当设备B发现聚合子链路的端口b的状态由down变为up时,其处理过程可由上述设备A发现聚合子链路的端口a的状态由down变为up时的处理过程直接推理得到,在此不再赘述。
图3-1-图3-5为应用本发明实施例的聚合子链路恢复处理过程的示意图,具体如下:
图3-1与图1-1相同。
当P1和P5之间的链路恢复时,以设备A为例,处理过程如下:
01:如图3-2所示,设备A发现P1的状态由down变为up,则将P1的初始状态设置为:Tx discarding,Rx discarding。
02:如图3-3所示,设备A发现P1是聚合子链路端口,将P1加入交换芯片上的聚合组,这样交换芯片上的聚合组实际包含P1~P4四个端口,由于P1发送方向的状态是Tx discarding,因此P1不分担聚合组的流量,而是由P2~P4分担。
03:设备A通过P1向P5发送端口状态查询报文,P5在加入聚合组且设备B已将P5接收方向的状态设置成Rx forwarding后,向P1发送响应报文。
04:如图3-4所示,设备A从P1接收到来自P5的响应报文后,将P1发送方向的状态设置成Tx forwarding,聚合组的流量就可以正常分担到P1了。
经过01~04后,设备A到设备B方向的流量负载分担到P1~P4四个端口。
设备B对P5的处理与设备A对P1的处理类似,如图3-5所示,当设备B上的P5的发送方向的状态为Tx forwarding后,设备B到设备A方向的流量负载分担到P5~P8四个端口。
图4为本发明实施例提供的聚合子链路恢复处理***组成图,如图4所示,其主要包括:第一设备和第二设备,且第一、第二设备之间具有聚合链路,其中一条聚合子链路在第一、第二设备上的端口分别为第一、第二端口,其中:
第一设备:发现本设备上聚合子链路的第一端口变为up状态,则将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向第二设备发送端口状态查询报文;接收第二设备发来的响应报文,将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量。
第二设备:从聚合子链路的第二端口接收第一设备发来的端口状态查询报文,若发现第二端口的接收方向的状态为转发,则向第一设备返回响应报文。
实际应用中,第二设备可包括:
第一模块:从聚合子链路的第二端口接收第一设备发来的端口状态查询报文,若发现第二端口的接收方向的状态为转发,则向第二模块发送响应指示;若发现第二端口的接收方向的状态为丢弃,则等待至第二端口的接收方向的状态为转发时,向第二模块发送响应指示。
第二模块:当接收到第一模块发来的响应指示时,向第一设备返回响应报文。
实际应用中,第一设备可包括:
第一模块:发现本设备上聚合子链路的第一端口变为up状态,则将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向第二设备发送端口状态查询报文,向定时模块发送启动指示。
定时模块:接收启动指示后,开始计时;在定时时长到达后,向第二模块发送定时到达指示。
第二模块:从聚合子链路的第一端口接收到第二设备发来的响应报文,则将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量;若在接收到定时到达指示时,仍未收到第二设备发来的响应报文,则重复向第二设备发送端口状态查询报文。
实际应用中,第一设备还可包括:计数模块,对第二模块重复发送端口状态查询报文的次数进行计数,当计数值到达预设次数时,向第二模块发送转发状态自动设置指示。
同时,所述第二模块还用于,当收到计数模块发来的转发状态自动设置指示,将聚合子链路的第一端口的发送方向的状态设置为:转发。
以下给出本发明实施例提供的聚合子链路恢复处理设备的组成,其主要包括:第一模块和第二模块,其中:
第一模块:发现本设备上聚合子链路的第一端口变为up状态,则将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向对端设备发送端口状态查询报文。
第二模块:从聚合子链路的第一端口接收对端设备发来的响应报文,将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量。
实际应用中,第一模块还可用于,在向对端设备发送端口状态查询报文的同时,向定时模块发送启动指示;
同时,所述设备还包括:定时模块,接收启动指示后,开始计时;在定时时长到达后,向第二模块发送定时到达指示;
同时,第二模块还用于,若在接收到定时到达指示时,未从聚合子链路的第一端口接收到对端设备发来的响应报文,则重复向对端设备发送端口状态查询报文。
实际应用中,所述设备还可包括:计数模块,对第二模块重复发送端口状态查询报文的次数进行计数,当计数值到达预设次数时,向第二模块发送转发状态自动设置指示。
同时,所述第二模块还用于,当收到计数模块发来的转发状态自动设置指示时,将聚合子链路的第一端口的发送方向的状态设置为:转发。
实际应用中,所述设备还可包括:
第三模块,从第一端口接收对端设备发来的端口状态查询报文,若发现第一端口接收方向的状态为:转发,则向对端设备返回响应报文。
实际应用中,第三模块可包括:
第三子模块:从第一端口接收对端设备发来的端口状态查询报文,若发现第一端口的接收方向的状态为转发,则向第四子模块发送响应指示;若发现第一端口的接收方向的状态为丢弃,则等待至第一端口的接收方向的状态为转发时,向第四子模块发送响应指示。
第四子模块:当接收到第三子模块发来的响应指示时,向对端设备返回响应报文。
以上所述仅为本发明的过程及方法实施例,并不用以限制本发明,凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种聚合子链路恢复处理方法,其特征在于,为每个处于正常状态的端口,在发送方向和接收方向上分别定义两种状态:丢弃和转发,该方法包括:
第一设备发现本设备上聚合子链路的第一端口变为正常状态,则将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向第二设备发送端口状态查询报文;
第二设备接收端口状态查询报文,若发现本第二设备上所述聚合子链路的第二端口的接收方向的状态为转发,则向第一设备返回响应报文;
第一设备接收所述响应报文,将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量。
2.如权利要求要求1所述的方法,其特征在于,所述第二设备接收端口状态查询报文之后进一步包括:
第二设备发现本设备上所述聚合子链路的第二端口的接收方向的状态为丢弃,则等待至第二端口的接收方向的状态为转发时,向第一设备返回响应报文。
3.如权利要求1或2所述的方法,其特征在于,所述方法进一步包括:预设一等待时长,
所述第一设备向第二设备发送端口状态查询报文之后进一步包括:第一设备在预设等待时长内未收到第二设备发来的响应报文,则重复向第二设备发送端口状态查询报文。
4.如权利要求3所述的方法,其特征在于,所述第一设备重复向第二设备发送端口状态查询报文之后进一步包括:
第一设备发现重复预设次数发送端口状态查询报文后,仍未收到第二设备发来的响应报文,则自动将第一端口的发送方向的状态设置为:转发。
5.一种聚合子链路恢复处理***,其特征在于,该***包括:
第一设备,发现本设备上聚合子链路的第一端口变为正常状态,则将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向第二设备发送端口状态查询报文;接收第二设备发来的响应报文,将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量;
第二设备,从聚合子链路的第二端口接收第一设备发来的端口状态查询报文,若发现第二端口的接收方向的状态为转发,则向第一设备返回响应报文。
6.一种聚合子链路恢复处理设备,其特征在于,该设备包括:
第一模块,发现本设备上聚合子链路的第一端口变为正常状态,则将第一端口的发送方向和接收方向的状态都设置为:丢弃,将第一端口加入聚合组但不允许第一端口分担聚合组的流量,并向对端设备发送端口状态查询报文;
第二模块,从聚合子链路的第一端口接收对端设备发来的响应报文,将第一端口的发送方向的状态设置为:转发,开始允许第一端口分担聚合组的流量,所述响应报文为:对端设备从聚合子链路的第二端口接收到所述第一模块发来的端口状态查询报文后,发现本对端设备上所述聚合子链路的第二端口的接收方向的状态为转发时返回给所述第二模块的。
7.如权利要求6所述的设备,其特征在于,所述第一模块进一步用于,在向对端设备发送端口状态查询报文的同时,向定时模块发送启动指示;
且,所述设备进一步包括:
定时模块,接收启动指示后,开始计时;在定时时长到达后,向第二模块发送定时到达指示;
且,所述第二模块进一步用于,若在接收到定时到达指示时,未从聚合子链路的第一端口接收到对端设备发来的响应报文,则重复向对端设备发送端口状态查询报文。
8.如权利要求6或7所述的设备,其特征在于,所述设备进一步包括:
第三模块,从第一端口接收对端设备发来的端口状态查询报文,若发现第一端口接收方向的状态为:转发,则向对端设备返回响应报文。
9.如权利要求8所述的设备,其特征在于,所述第三模块包括:
第三子模块,从第一端口接收对端设备发来的端口状态查询报文,若发现第一端口的接收方向的状态为转发,则向第四子模块发送响应指示;若发现第一端口的接收方向的状态为丢弃,则等待至第一端口的接收方向的状态为转发时,向第四子模块发送响应指示;
第四子模块,当接收到第三子模块发来的响应指示时,向对端设备返回响应报文。
10.如权利要求7所述的设备,其特征在于,所述设备进一步包括:
计数模块,对第二模块重复发送端口状态查询报文的次数进行计数,当计数值到达预设次数时,向第二模块发送转发状态自动设置指示;
且,所述第二模块进一步用于,当收到计数模块发来的转发状态自动设置指示时,将聚合子链路的第一端口的发送方向的状态设置为:转发。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100839665A CN101552725B (zh) | 2009-05-13 | 2009-05-13 | 聚合子链路恢复处理方法、***及设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100839665A CN101552725B (zh) | 2009-05-13 | 2009-05-13 | 聚合子链路恢复处理方法、***及设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101552725A CN101552725A (zh) | 2009-10-07 |
CN101552725B true CN101552725B (zh) | 2011-12-21 |
Family
ID=41156727
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2009100839665A Active CN101552725B (zh) | 2009-05-13 | 2009-05-13 | 聚合子链路恢复处理方法、***及设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101552725B (zh) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103560898B (zh) * | 2013-07-30 | 2016-12-28 | 北京华为数字技术有限公司 | 一种端口状态设置方法、端口优先级的选择方法及装置 |
CN103780472B (zh) * | 2014-01-06 | 2017-08-22 | 新华三技术有限公司 | 一种聚合端口组的选中口管理方法及设备 |
CN111585883B (zh) * | 2019-02-18 | 2023-03-24 | 中兴通讯股份有限公司 | 一种链路聚合端口切换方法、网络设备和计算机存储介质 |
CN112583709B (zh) * | 2019-09-27 | 2024-05-28 | 深圳市中兴微电子技术有限公司 | 一种链路聚合的选路方法、***、交换设备及介质 |
CN111614555B (zh) * | 2020-04-20 | 2022-05-03 | 北京百卓网络技术有限公司 | 一种业务通道建立方法、装置及设备 |
CN112751757A (zh) * | 2020-12-29 | 2021-05-04 | 盛科网络(苏州)有限公司 | 堆叠***、交换设备、芯片及链路故障恢复方法 |
CN115567463A (zh) * | 2021-06-30 | 2023-01-03 | 中兴通讯股份有限公司 | 一种端口状态调整方法、装置及计算机可读存储介质 |
CN115996191A (zh) * | 2022-11-21 | 2023-04-21 | 迈普通信技术股份有限公司 | 端口状态控制方法、装置、网络通信设备及存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6553029B1 (en) * | 1999-07-09 | 2003-04-22 | Pmc-Sierra, Inc. | Link aggregation in ethernet frame switches |
CN101018228A (zh) * | 2006-12-22 | 2007-08-15 | 华为技术有限公司 | 一种端口聚合方法及装置 |
CN101060460A (zh) * | 2006-06-09 | 2007-10-24 | 华为技术有限公司 | 防止以太网链路聚合逻辑端口报文丢失的方法及通信设备 |
-
2009
- 2009-05-13 CN CN2009100839665A patent/CN101552725B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6553029B1 (en) * | 1999-07-09 | 2003-04-22 | Pmc-Sierra, Inc. | Link aggregation in ethernet frame switches |
CN101060460A (zh) * | 2006-06-09 | 2007-10-24 | 华为技术有限公司 | 防止以太网链路聚合逻辑端口报文丢失的方法及通信设备 |
CN101018228A (zh) * | 2006-12-22 | 2007-08-15 | 华为技术有限公司 | 一种端口聚合方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN101552725A (zh) | 2009-10-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101552725B (zh) | 聚合子链路恢复处理方法、***及设备 | |
US7978690B2 (en) | Method to operate a crossbar switch | |
Finn | Resynch procedures and a fail-safe network protocol | |
US8233483B2 (en) | Communication apparatus, communication system, absent packet detecting method and absent packet detecting program | |
EP0123507B1 (en) | Data communication system and apparatus | |
US8385374B1 (en) | Multilane communication device | |
US5168497A (en) | Packet communication processing method | |
US20030206527A1 (en) | Transmitting data between multiple computer processors | |
EP1265403A2 (en) | Loop network and method for operating the same | |
CN103152260B (zh) | 报文转发***、方法及装置 | |
JPS63107254A (ja) | 衛星パケット通信方法 | |
WO2011014470A1 (en) | Methods and systems for fail-safe communication | |
CN101542981A (zh) | 具主从结构的通信*** | |
CN104641609A (zh) | 用于在线路卡的接口控制模块之间传送分组的方法和装置 | |
CN101588298A (zh) | 一种堆叠***中流量切换的方法和堆叠*** | |
US7900115B2 (en) | Replacement messages for identifying and preventing errors during the transmission of realtime-critical data | |
US20140211630A1 (en) | Managing packet flow in a switch faric | |
CN104484295A (zh) | 并行计算机***中基于接收方滑动窗口的数据传输方法 | |
KR20080005055A (ko) | 패킷 전송 장치 | |
CN103036728A (zh) | 一种多冗余的以太网数据传输***及传输方法 | |
CN101686169A (zh) | 用于避免多环互连中的死锁的方案及对拥塞控制的额外应用 | |
CN101420351B (zh) | 一种实现弹性分组环上业务保护的装置及方法 | |
KR101726375B1 (ko) | 데이터 이중화 장치 | |
CN100372334C (zh) | 一种实现在光网络中传输InfiniBand数据的设备及方法 | |
JP5761193B2 (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 | ||
CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: Xinhua three Technology 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: Huasan Communication Technology Co., Ltd. |