CN101534234B - 一种相交以太环网保护方法和系统 - Google Patents
一种相交以太环网保护方法和系统 Download PDFInfo
- Publication number
- CN101534234B CN101534234B CN2009100822664A CN200910082266A CN101534234B CN 101534234 B CN101534234 B CN 101534234B CN 2009100822664 A CN2009100822664 A CN 2009100822664A CN 200910082266 A CN200910082266 A CN 200910082266A CN 101534234 B CN101534234 B CN 101534234B
- Authority
- CN
- China
- Prior art keywords
- subring
- port
- link
- host node
- self
- 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
- Small-Scale Networks (AREA)
Abstract
本发明公开了一种相交以太环网保护方法,包括:对于相交环中的子环,子环上的主节点在子环完整时,阻塞自身的副端口,并周期性地从自身的主端口发送健康检测报文;当主环两点故障时,子环上的主节点即使在预设时间内从自身的副端口收不到自己发送健康检测报文,也不会放开自身的副端口。本发明还公开了一种相交以太环网保护系统。本发明的技术方案,能够在主环两点故障时防止子环产生环路。
Description
技术领域
本发明涉及以太环网保护技术领域,尤指一种相交以太环网保护方法和系统。
背景技术
随着以太环网的逐步普及和应用,用户对以太环网的性能和规模的需求也越来越高。为了防止环路上的广播风暴,一般采用生成树协议(STP,Spanning Tree Protocol)对以太环网进行保护。STP在大的网络中定义一棵树,并迫使一定的备份路径处于备份状态,如果生成树中的网络一部分不可达,或者STP路径开销变化了,生成树算法会重新计算生成树拓扑,并且通过启用备份路径来重新建立连接,因此,STP可以通过阻断冗余链路防止数据环路,并可以通过启用备份冗余链路提供高可靠性。
但实际应用中STP链路切换收敛时间受网络拓扑的影响,一般收敛时间为秒级,网络直径较大时收敛时间更长。这样的速度对于现在的局域网(LANs)和城域网(MANs)来说太慢了,不能满足高服务质量业务的需求。
为此,现有技术中提出了一些针对环网出现故障时进行快速保护的新方法。下面简单介绍现有的以太环网保护协议中的一些基本概念和关键技术:
环:一个环物理上对应一个环形连接的以太网拓扑,是一组相互连接成环的以太网交换机的集合;
域:由整数表示的ID来标识,一组配置了相同的域ID和控制虚拟局域网(VLAN),并且相互连通的交换机群体构成一个域;
控制VLAN:协议控制报文在控制VLAN中传播;
保护VLAN:保护VLAN是域中用来传输数据报文的VLAN,每个域 中保护一个或多个数据VLAN,每个域内环网保护协议计算出的拓扑仅对该域的保护VLAN有效;
主节点:主节点是环上的主要决策和控制节点,每个环上必须有一个主节点而且只能有一个;主节点在环上的两端口分别为主端口和副端口,如果产生环路,主节点阻塞副端口,如果环网故障,主节点放开副端口以支持数据转发;主节点通过轮询机制和告警机制快速检测环路的产生和消失;主节点有两种状态,当环网上的所有链路都处于完好(UP)状态时,主节点处于完整状态(Complete State),当环网上有链路处于故障(Down)状态时,主节点处于故障状态(Failed State);
传输节点:环上除主节点以外的其它节点均为传输节点;
告警机制:当传输节点发现自己任何一个属于环的端口变为故障(down)状态时会立刻发送链路故障(Link Down)报文给该环的主节点;主节点收到Link Down报文后立即将状态切换至故障状态,放开副端口,并从主端口发送环网故障刷新(RING-DOWN-Flush-FDB)报文,通知所有节点刷新转发数据库(FDB,Forwarding Date Base)。
轮询机制:主节点周期性地从其主端口发送健康检测(Hello)报文并启动一定时器,该Hello报文依次经过各传输节点在环上传播;如果主节点能够在所述定时器的定时时间(Hello Time)内从副端口收到自己发送的Hello报文,则说明环网完整,保持副端口的阻塞状态;如果主节点在HelloTime时间内没有收到自己发送的Hello报文,则认为环网发生链路故障,放开副端口的阻塞状态,并发送环网故障刷新(RING-DOWN-Flush-FDB)报文,以通知各节点刷新FDB。
端口的预阻塞(Pre-Forwarding)状态:当传输节点在环上的一端口由故障(Down)状态迁移至完好(Up)状态时,该传输节点将该端口设置为预阻塞状态,并启动一预阻塞定时器;处于预阻塞状态的端口阻塞数据VLAN的报文,但转发控制VLAN的协议控制报文;此时,如果环网已经全部恢复,主节点能够从副端口收到自己发送的Hello报文,则主节点将状 态迁移至完整状态,阻塞副端口,并从主端口发送环网恢复刷新(RING-UP-FLUSH-FDB)报文,以通知各节点刷新FDB;传输节点在接收到来自主节点的RING-UP-FLUSH-FDB报文或预阻塞定时器超时时,放开预阻塞的端口。
上述技术环网保护方案完全适用于单环拓扑的情况,但在实际的以太网拓扑中,不同的环之间会出现相交的情况。如果将单环保护协议简单地运用到相交的各个环上,会出现一些问题。
图1是将单环保护协议运用到相交的多个环上时遇到的问题的示意图。如图1所示,节点设备S1、S2、S3、S4、S5和S6构成环R1,环R2包括R1和节点设备S7、S8和S9,环R3包括R1和节点设备S10和S11,即环R1、R2和R3彼此相交。R1中S1为主节点,其主副端口分别为P11和P12,R2中S8为主节点,其主副端口分别为P81和p82,R3中S11为主节点,其主副端口分别为P111和P112。当环R1两点故障(S5和S6之间的链路故障,以及S3和S4之间的链路故障)时,R2的主节点S8和R3的主节点S11将收不到自己发送的健康检测(Hello)报文,当定时器(Hello Time)超时时,S8和S11都会放开自己的副端口。此时R2和R3就会形成一个超环,产生广播风暴。
发明内容
本发明提供了一种相交以太环网保护方法,该方法在主环两点故障时能够防止两个子环产生环路的情况。
本发明还提供了一种相交以太环网保护系统,该系统在主环两点故障时能够防止两个子环产生环路的情况。
为达到上述目的,本发明的技术方案具体是这样实现的:
本发明公开了一种相交以太环网保护方法,该相交以太环网包括主环和与该主环相交的子环,主环包括第一主节点和多个传输节点,各节点之间通过各自的端口相互连接形成主环,第一主节点包括主端口和副端口,子环包 括第二主节点和多个传输节点,子环上的各节点之间通过各自的端口相互连接形成子环,第二主节点包括主端口和副端口,该方法包括:
当主环完整时,第一主节点的副端口处于阻塞状态,当子环完整时,第二主节点的副端口处于阻塞状态;
当主环和子环的相交链路以及主环的除该相交链路外的另一链路发生故障时,第一主节点接收到由检测到故障的传输节点发送的链路故障报文后放开阻塞的副端口或者在预定时间内没有收到自身发送的健康检测报文后放开阻塞的副端口,第二主节点的副端口仍然保持阻塞状态;
当主环和子环的相交链路以及主环的除该相交链路外的另一链路的故障恢复时,第一主节点在预定时间内会接收到自身发送的健康检测报文,第一主节点阻塞自身的副端口。
本发明还公开了一种多环相交以太环网保护系统,该系统包括主环和与该主环相交的子环,其中,主环包括第一主节点和多个传输节点,各节点之间通过各自的端口相互连接形成主环,第一主节点包括主端口和副端口,子环包括第二主节点和多个传输节点,子环上的各节点之间通过各自的端口相互连接形成子环,第二主节点包括主端口和副端口,
第一主节点,用于在主环完整时,将自身的副端口置于阻塞状态;用于在主环和子环的相交链路以及主环的除该相交链路外的另一链路发生故障时,接收到由检测到故障的传输节点发送的链路故障报文后放开阻塞的副端口或者在预定时间内没有收到自身发送的健康检测报文后放开阻塞的副端口;用于在主环和子环的相交链路以及主环的除该相交链路外的另一链路的故障恢复时,接收到自身发送的健康检测报文,阻塞自身的副端口;
第二主节点,用于在子环完整时,将自身的副端口置于阻塞状态;用于在主环和子环的相交链路以及主环的除该相交链路外的另一链路发生故障时,保持自身副端口的阻塞状态。
由上述技术方案可见,本发明这种主环上的主节点在主环完整时,阻塞自身的副端口,并周期性地从自身的主端口发送健康检测报文;如果主环上 的主节点在预设时间内没有从自身的副端口收到健康检测报文,则放开自身的副端口;子环上的主节点在子环完整时,阻塞自身的副端口,并周期性地从自身的主端口发送健康检测报文;但如果子环上的主节点在预设时间内没有从自身的副端口收到健康检测报文,不会放开自身的副端口的技术方案,在主环两点故障时能够防止两个子环产生环路的情况。
附图说明
图1是将单环保护协议运用到相交的多个环上时遇到的问题的示意图;
图2是本发明实施例一种相交以太环网保护方法的流程图;
图3是图1所示以太环网拓扑的第一种状况示意图;
图4是图1所示以太环网拓扑的第二种状况示意图;
图5是图1所示以太环网拓扑的第三种状况示意图;
图6是图1所示以太环网拓扑的第四种状况示意图;
图7是本发明实施例一种相交以太环网保护系统的组成结构示意图。
具体实施方式
首先参照图1,在单环保护协议的上述技术概念的基础上给出的关于相交环的一些技术概念:
主环:当一个域包含多个相交环时,选择其中一个环作为主环,主环上各节点的主从端口需要同时加入主控制VLAN和子控制VLAN;例如,在图1中选择R1作为主环;
子环:一个域中除主环之外的环称为子环。子环上各节点的主从端口只需要加入到子控制VLAN中;例如,在图1中,除了主环R1以外的环R2和R3均为子环;
边缘节点:子环和主环会有两个交点,这两个交点处的交换机称为边缘节点;在图1中,S3和S5为边缘节点;
控制VLAN:每个域中具有两个控制VLAN,分别为主控制VLAN和子 控制VLAN,主环的协议控制报文在主控制VLAN中传播,子环的协议控制报文在子控制VLAN中传播;主环节点上的域端口同时加入主控制VLAN和子控制VLAN,子环上的域端口只加入子控制VLAN;子环的协议控制报文在主环中视为数据报文处理,与数据报文实现同步阻塞和开放。
对应上述的图1,这里将R1配置为主环,将R2和R3配置为子环,当图1所示的相交拓扑的以太环网正常运转时,主环R1的主节点S1的副端口P12处于阻塞状态,数据报文以及子环R2和子环R3的协议控制报文都不能通过P12,只有主环R1自身的协议控制报文能够通过P12;子环R2的主节点S8的副端口P82以及子环R3的主节点S11的副端口P112也都处于阻塞状态。主环R1、子环R2和子环R3的运行方式同单环。但是为了解决前面提到的主环两点故障(例如,S5和S6之间的链路故障,以及S3和S4之间的链路故障)时,子环主节点在Hello报文超时时开放副端口形成环路的问题,本发明给出了如图2所示的解决方案。
图2是本发明实施例一种相交以太环网保护方法的流程图。本方法适用的相交以太环网包括主环和与该主环相交的子环,主环包括第一主节点(即主环主节点)和多个传输节点,各节点之间通过各自的端口相互连接形成主环,第一主节点包括主端口和副端口;子环包括第二主节点(即子环主节点)和多个传输节点,子环上的各节点之间通过各自的环上端口相互连接形成子环,第一主节点包括主端口和副端口,则如图2所示,该方法包括:
步骤201,当主环完整时,第一主节点的副端口处于阻塞状态,当子环完整时,第二主节点的副端口处于阻塞状态。
本步骤中,当主环完整时,即主环上无故障链路时,第一主节阻塞自身的副端口,以防止产生环路,并周期性地从自身的主端口发送健康检测报文;同样,当子环完整时,即子环上无故障链路时,第二主节阻塞自身的副端口,以防止产生环路,并周期性地从自身的主端口发送健康检测报文。
步骤202,当主环和子环的相交链路以及主环的除该相交链路外的另一链路发生故障时,第一主节点接收到由检测到故障的传输节点发送的链路故 障报文后放开阻塞的副端口或者在预定时间内没有收到自身发送的健康检测报文后放开阻塞的副端口,第二主节点的副端口仍然保持阻塞状态。
本步骤中,主环和子环的相交链路以及主环的除该相交链路外的另一链路即为主环上的两个边缘节点之间的两条链路,例如,在图1中,主环和子环的相交链路为S3-S4-S5,主环的除该相交链路外的另一链路为S5-S6-S1-S2-S3。
本步骤中,主环上的各故障链路两端的节点向第一主节点发送链路故障报文,第一主节点收到链路故障报文或者检测到自身发送的健康检测报文超时时,切换到故障状态并放开自身的副端口;而第二主节点,即从环的主节点不检测自身发送的健康检测报文是否超时,状态不变,仍保持从端口的阻塞状态
步骤203,当主环和子环的相交链路以及主环的除该相交链路外的另一链路的故障恢复时,第一主节点在预定时间内会接收到自身发送的健康检测报文,第一主节点阻塞自身的副端口。
本步骤中,第一主节点切换到完整状态,并发送环网恢复刷新报文。
在图2所示的方案中,第二主节点,即子环的主节点取消了健康检测机制中的Hello报文超时时开放副端口的功能,即子环的主节点在周期性从主端口发送Hello报文时,不再使用Hello Time定时器,这样即使在Hello Time时间内没有收到自己发送的Hello报文,主节点也不会因此放开副端口。
取消子环的主节点在Hello报文超时时开放副端口的功能后,就不会出现图1中所示主环R1两点故障时子环R2和R3形成超环的情况,进而避免了广播风暴的产生。
在现有方案中,环上的主节点通过健康检测机制中的Hello报文的超时,以及告警机制中的故障链路两端的节点发送的链路故障(Link Down)报文获知环路出现故障,而在本发明图2所示的方案中取消了子环的主节点的Hello报文超时检测功能,子环的主节点只能通过Link Down报文获知环路出 现故障,那么当网络拥塞等原因Link Down报文丢失时,子环的主节点将无法获知环路出现故障。下面以图1所示的以太环网拓扑为例进行说明。
图3是图1所示以太环网拓扑的第一种状况示意图。参见图3,以主环R1和子环R2为例,根据本发明的方案,子环R2的主节点S8取消了Hello报文超时时放开副端口的功能。当R2上的S5和S9之间的链路发生故障时,S5和S9分别向主节点S8发送Link Down报文,如果由于网络拥塞或其他原因导致S5和S9发送的Link Down报文均丢失,则主节点S8收不到Link Down报文,从而无法感知子环环路的故障,不会放开副端口P82,这样子环R2就会断为两截,不利于数据报文的传输,也浪费了网络链路带宽。
为了解决该问题,本发明给出了如下的解决方案:当子环的链路发生故障时,子环上的故障链路两端的传输节点向子环上的主节点发送Link Down报文;之后,如果该子环上的传输节点仍收到子环上的主节点发送的携带完整(Complete)状态参数的Hello报文,则重新发送Link Down报文;子环的主节点在收到Link Down报文后,会放开自身的副端口,并开始发送携带故障(Failed)状态参数的Hello报文。
例如,在图3中,当子环R2上的S5和S9之间的链路发生故障时,S5和S9分别向主节点S8发送Link Down报文,如果S5和S9发送的Link Down报文均丢失,主节点S8收不到Link Down报文,则主节点S8仍认为环路完整,其周期性发送的Hello报文中的状态参数仍为“完整(Complete)”;S5或S9收到携带“完整(Complete)”状态参数的Hello报文后,可知主节点S8没有收到Link Down报文,因此重新发送Link Down报文;网络拥塞等导致Link Down丢失的实际状况并非一成不变的,当这些状况消失主节点S8接收到LinkDown报文后,获知环路故障,其周期性发送的Hello报文中的状态参数变更为“故障(Failed)”;S5或S9收到携带“故障(Failed)”状态参数的Hello报文后,不再发送Link Down报文。
在图3中,子环R3的主节点S11同样也取消了Hello报文超时时放开副端口的功能。因此,子环R3上的传输节点在发送Link Down报文后,如果仍收 到主节点S11发送的携带“完整(Complete)”状态参数的Hello报文,则重新发送Link Down报文。例如,当S3和S10之间的链路发生故障时,S3和S10分别向主节点S11发送Link Down报文,如果Link Down报文均丢失,主节点S11收不到Link Down报文,则主节点S11仍认为环路完整,其周期性发送的Hello报文中的状态参数仍为“完整(Complete)”;S3或S10收到携带“完整(Complete)”状态参数的Hello报文后,可知主节点S11没有收到Link Down报文,因此重新发送Link Down报文;当主节点S11接收到Link Down报文后,获知环路故障,其周期性发送的Hello报文中的状态参数变更为“故障(Failed)”;S3或S10收到携带“故障(Failed)”状态参数的Hello报文后,不再发送Link Down报文。
本申请的发明人还发现相交以太环网中存在的如下问题,仍以图1所示的以太环网拓扑为例进行说明。
图4是图1所示以太环网拓扑的第二种状况示意图。参见图4,子环主节点的Hello报文用于探测自身所在环上是否存在数据通路,其在主环上按照数据报文的转发方式进行转发,即在主环上将子环的协议控制报文按数据报文进行转发处理。假设S3和S4之间的链路、S5和S9之间的链路以及S5和S6之间的链路发生故障,为描述方便将上述三处故障分别称为故障0、故障1和故障2,此时主环R1的主节点S1和子环R2的主节点S8都将放开副端口,使其参与数据转发;故障1先恢复后,其两边的端口处于预阻塞(Pre-Forwarding)状态,当预阻塞定时器超时时,故障1两边的端口转为转发(Forwarding)状态;然后故障2恢复,其两边的端口处于预阻塞状态,此时由于R1上的故障0还处于故障状态,其主节点S1的副端口还是放开的,而R2的主节点S8发送的Hello报文不能通过故障2两边的处于预阻塞状态的端口;直到故障2两边端口的预阻塞定时器超时时,故障2边的端口转为转发状态,此时R1和R2必然形成一个超环;该超环持续到R2的主节点S8发送的Hello报文通过已恢复的故障2两边的端口后又到达S8,S8发现环路并阻塞副端口后 才被断开。为了避免这种环路的产生,本发明中给出了如下的解决的方案:
当主环上的故障链路恢复时,该故障恢复的链路两端的传输节点将故障恢复的链路两端的端口设置为预阻塞状态时,如果该传输节点收到主环上的主节点发送的环网恢复刷新报文,则放开自身处于预阻塞状态的端口,另外,如果该传输节点在预设时间内没有收到环网恢复刷新报文,也会放开自身处于预阻塞状态的端口;
当子环上的链路故障恢复时,该故障恢复的链路两端的传输节点将故障恢复的链路两端的端口设置为预阻塞状态,如果该子环上的传输节点收到子环主节点发送的环网恢复刷新报文,则放开自身处于预阻塞状态的端口,但如果该子环上的传输节点在预设时间内没有收到环网恢复刷新报文,不会放开自身处于预阻塞状态的端口。
即子环的传输节点取消预阻塞定时器超时时放开预阻塞端口的功能,子环的传输节点在自身环上端口从故障状态恢复处于预阻塞状态时,不再使用预阻塞定时器。这样子环的传输节点的预阻塞状态端口不会自动放开,只有在收到子环主节点发送的环网恢复刷新(RING-UP-FLUSH-FDB)报文后才放开预阻塞的端口。当环路完整,主节点能够从副端口收到自己发送的Hello报文时,主节点阻塞副端口,并从主端口发送环网恢复刷新(RING-UP-FLUSH-FDB)报文,以通知各节点刷新FDB。
参见图4,子环R2上的传输节点取消预阻塞定时超时时放开预阻塞端口的功能后,当故障1恢复时,其两边的端口处于预阻塞状态;然后故障2恢复,其两边的端口进入预阻塞状态,当故障2两边端口的预阻塞定时器超时时,故障2边的端口转为转发状态,此时由于故障1两边的端口仍处于预阻塞状态,因此R1和R2不会形成超环,避免了上述瞬时广播风暴的产生;R2的主节点S8发送的Hello报文通过已恢复的故障2两边的端口后又到达S8,S8发现环路完整,阻塞副端口,并发送RING-UP-FLUSH-FDB报文;S5和S9收到RING-UP-FLUSH-FDB报文后,再放开故障1两边的处于预阻塞状态的端口,使其参与数据转发。
在现有方案中,环上的传输节点的处于预阻塞状态的端口,在接收到主节点发送的RING-UP-FLUSH-FDB报文或预阻塞定时器超时被放开,从而转为转发状态。而在本发明的上述方案中取消了子环传输节点预阻塞定时器超时时放开预阻塞端口的功能后,子环传输节点只能在收到RING-UP-FLUSH-FDB报文后放开预阻塞端口,那么当网络拥塞等原因RING-UP-FLUSH-FDB报文丢失时,子环的传输节点将无法放开预阻塞的端口,端口一直处于预阻塞状态。下面仍以图4为例进行说明。
如图4所示,子环R2上的各传输节点取消了预阻塞定时器超时时放开预阻塞端口的功能。发生图4所示的3处故障后,当故障1恢复时,其两边的端口处于预阻塞状态;然后故障2恢复,其两边的端口进入预阻塞状态,当故障2两边端口的预阻塞定时器超时时,故障2边的端口转为转发状态;R2的主节点S8发送的Hello报文通过已恢复的故障2两边的端口后又到达S8,S8发现环路完整,阻塞副端口,并发送RING-UP-FLUSH-FDB报文;如果由于网络拥塞或其他原因RING-UP-FLUSH-FDB报文丢失,则S5和S9收不到RING-UP-FLUSH-FDB报文,使得故障1两边的端口一直处于预阻塞状态,不能参与数据转发,影响链路利用率。
为了解决该问题,本发明给出了如下的解决方案:当子环上的传输节点的端口处于预阻塞状态时,如果该子环上的传输节点收到子环上主节点发送的携带“完整”状态参数的健康检测(Hello)报文,则也放开自身处于预阻塞状态的端口。
则在图4中,主节点S8是在发现环路完整,并阻塞副端口后,发送RING-UP-FLUSH-FDB报文的;即使RING-UP-FLUSH-FDB报文丢失,此时由于环路完整,主节点S8周期性地发送的Hello报文中的状态参数为“Complete”,因此S5和S9在收到主节点S8发送的携带“Complete”状态参数的Hello报文时(可知主节点S8处于“Complete”状态,其副端口必定是阻塞的),放开自身处于预阻塞状态的端口,即故障1两边的端口从预阻塞状态 转为转发状态。
上述子环上的传输节点,在收到子环主节点发送的携带“完整(Complete)”状态参数的Hello报文时,放开自身处于预阻塞状态的端口的方案,在有些情况下会失效。这是因为子环上的主节点只有在环路完整时,其发送的Hello报文中的状态参数才为“Complete”。下面仍以图1所示以太环网拓扑为例进行说明。
图5是图1所示以太环网拓扑的第三种状况示意图。对于子环R2,其环上链路有两处故障,分别为S5与S9之间的故障1′,和S3与S7之间的故障2′。当故障2′恢复时,其两边的端口处于预阻塞状态;由于故障1′一直未恢复,因此R2的主节点S8处于“Failed”状态,其周期性发送的Hello报文中的状态参数也为“Failed”;此时,故障2′两边的端口会一直处于预阻塞状态不能放开。
为了解决这种情况下的问题,本发明给出了如下的解决方案:子环上的传输节点在自身的处于子环上的一个端口故障时,从自身的处于子环上的另一个端口定时发送故障通知报文,并在自身的故障端口恢复时停止发送故障通知报文;子环上的传输节点在收到故障通知报文时,放开自身处于预阻塞状态的端口;子环上的主节点在收到故障通知报文时,放开自身的副端口(环上有其他断点,因此本处的预阻塞端口可以放开)。
则在图5中,一直未恢复的故障1′两边的节点S5和S9定时发送故障通知报文,则故障2′两边的节点S3和S7分别收到来自S5和S9的故障通知报文后,将故障2′两边的处于预阻塞状态的端口放开,使其参与数据转发。
故障通知报文可以通知环上的其他节点环上有故障点。故障通知报文具体可以是用户新定义的一种协议控制报文也可以是现有技术中的链路故障(Link Down)报文。
由于子环上的传输节点在相邻链路故障恢复时,停止发送故障通知报 文,因此在本发明的一个实施例中,在子环上的主节点上设置一定时器,子环上的主节点在收到故障通知报文后,放开副端口的同时启动定时器,并且之后每收到一个故障通知报文便将该定时器复位,如果在一定时间内没有收到故障通知报文,定时器超时,则阻塞副端口。该方法可以在一些特定的场景下,避免使用不同厂家的设备组网时的环路产生,下面以图6为例进行说明。
图6是图1所示以太环网拓扑的第四种状况示意图。如图6所示,以主环R1和子环R2为例,节点设备S1、S2、S3、S4、S5和S6是厂商A的设备,而节点设备S7、S8和S9是厂商B的设备。当S3和S7之间的链路故障时,S3和S7定时向两边发送故障通知报文,告知R2上的其他传输节点放开处于预阻塞状态的端口以及告知主节点S8放开副端口。当S3和S7之间的链路恢复时,S3和S7停止发送故障通知报文。但是这种情况下,由于不同厂商的设备不兼容,导致R2的主节点S8发送的Hello报文不能通过主环R1,因此S8不能从副端口收到自己发送的Hello报文,而认为环路不完整,一直将副端口置于转发状态。此时会形成由S3、S4、S5、S9、S8和S7组成的环路,产生广播风暴。而本发明中的上述在子环的主节点上设置故障通知报文定时器的方案可以解决该问题。即在S8上设置故障通知报文定时器,S8在第一次收到故障通知报文放开副端口时启动该定时器,并在之后每收到一个故障通知报文将该定时器复位一次,当在一定时间内没有收到故障通知报文,该定时器超时,S8阻塞自身的副端口。
图7是本发明实施例一种相交以太环网保护系统的组成结构示意图。当然两环相交的情况有很多种,比如每个环上的节点数目,主节点的位置,两环相交的位置等,但这些因素并不影响本发明的方案,这里以图7所示意的系统进行说明,该系统包括:主环R1和与该主环R1相交的子环R2,其中,主环包括第一主节点和多个传输节点,各节点之间通过各自的端口相互连接形成主环,第一主节点包括主端口和副端口,子环包括第二主节点和多个传 输节点,子环上的各节点之间通过各自的端口相互连接形成子环,第二主节点包括主端口和副端口。
在图7中,第一主节点,用于在主环完整时,将自身的副端口置于阻塞状态;用于在主环和子环的相交链路以及主环的除该相交链路外的另一链路发生故障时,接收到由检测到故障的传输节点发送的链路故障报文后放开阻塞的副端口或者在预定时间内没有收到自身发送的健康检测报文后放开阻塞的副端口;用于在主环和子环的相交链路以及主环的除该相交链路外的另一链路的故障恢复时,接收到自身发送的健康检测报文,阻塞自身的副端口;
第二主节点,用于在子环完整时,将自身的副端口置于阻塞状态;用于在主环和子环的相交链路以及主环的除该相交链路外的另一链路发生故障时,保持自身副端口的阻塞状态。
在图7中,子环上的传输节点,用于在与自身相邻的子环链路发生故障时,向第二主节点发送链路故障报文,之后如果仍收到第二主节点发送的携带完整状态参数的健康检测报文,则重新发送链路故障报文;
第二主节点,用于在收到链路故障报文后,并放开自身的副端口。
在图7中,子环上的传输节点,用于在与自身相邻的子环上的故障链路恢复时,将故障恢复的链路两端的端口设置为预阻塞状态,并在收到第二主节点发送的环网恢复刷新报文后,放开自身处于预阻塞状态的端口,如果在预设时间内没有收到第二主节点发送的环网恢复刷新报文,则不会放开自身处于预阻塞状态的端口;
第二主节点,用于在能够从自身的副端口收到自身发送的健康检测报文时,阻塞自身的副端口。
在图7中,子环上的传输节点,用于在与自身相邻的子环上的故障链路恢复时,将故障恢复的链路两端的端口设置为预阻塞状态后,在收到第二主节点发送的携带完整状态参数的健康检测报文时,也放开自身处于预阻塞状态的端口;或者,在收到子环上的其他节点发送的链路故障报文时,也放开自身处于预阻塞状态的端口。
在图7中,子环上的传输节点,用于在与自身相邻的子环上的链路发生故障时,定时向第二主节点发送链路故障报文,在所述故障链路恢复时停止发送链路故障报文;
第二主节点,用于在收到链路故障报文时,放开自身副端口的同时启动一定时器,之后每收到一个链路故障报文将该定时器复位,如果在一定时间内没有收到链路故障报文而导致定时器超时时,阻塞自身的副端口。
综上所述,本发明这种主环上的主节点在主环完整时,阻塞自身的副端口,并周期性地从自身的主端口发送健康检测报文;如果主环上的主节点在预设时间内没有从自身的副端口收到健康检测报文,则放开自身的副端口;子环上的主节点在子环完整时,阻塞自身的副端口,并周期性地从自身的主端口发送健康检测报文;但如果子环上的主节点在预设时间内没有从自身的副端口收到健康检测报文,不会放开自身的副端口的技术方案,在主环两点故障时能够防止两个子环产生环路的情况。并且本发明实施例中手续所公开的各种技术方案逐步完善了多环相交以太环网的保护方案。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围,凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种相交以太环网保护方法,其特征在于,该相交以太环网包括主环和与该主环相交的子环,主环包括第一主节点和多个传输节点,各节点之间通过各自的端口相互连接形成主环,第一主节点包括主端口和副端口,子环包括第二主节点和多个传输节点,子环上的各节点之间通过各自的端口相互连接形成子环,第二主节点包括主端口和副端口,该方法包括:
当主环完整时,第一主节点的副端口处于阻塞状态,当子环完整时,第二主节点的副端口处于阻塞状态;
当主环和子环的相交链路以及主环的除该相交链路外的另一链路发生故障时,第一主节点接收到由检测到故障的传输节点发送的链路故障报文后放开阻塞的副端口或者在预定时间内没有收到自身发送的健康检测报文后放开阻塞的副端口,第二主节点的副端口仍然保持阻塞状态;
当主环和子环的相交链路以及主环的除该相交链路外的另一链路的故障恢复时,第一主节点在预定时间内会接收到自身发送的健康检测报文,第一主节点阻塞自身的副端口。
2.如权利要求1所述的方法,其特征在于,该方法进一步包括:
当子环的链路发生故障时,子环上的故障链路两端的传输节点向第二主节点发送链路故障报文,之后如果仍收到第二主节点发送的携带完整状态参数的健康检测报文,则重新发送链路故障报文;第二主节点收到链路故障报文后,放开自身的副端口。
3.如权利要求1所述的方法,其特征在于,该方法进一步包括:
当子环上的故障链路恢复时,该故障恢复的链路两端的传输节点将故障恢复的链路两端的端口设置为预阻塞状态,并在收到第二主节点发送的环网恢复刷新报文后,放开自身处于预阻塞状态的端口,如果在预设时间内没有收到第二主节点发送的环网恢复刷新报文,则不会放开自身处于预阻塞状态的端口;所述第二主节点在能够从自身的副端口收到自身发送的健康检测报文时,阻塞自身的副端口。
4.如权利要求3所述的方法,其特征在于,该方法进一步包括:
子环上的故障恢复的链路两端的节点将故障恢复的链路两端的端口设置为预阻塞状态后,在收到第二主节点发送的携带完整状态参数的健康检测报文时,也放开自身处于预阻塞状态的端口;
或者,子环上的故障恢复的链路两端的节点将故障恢复的链路两端的端口设置为预阻塞状态后,在收到子环上的其他节点发送的链路故障报文时,也放开自身处于预阻塞状态的端口。
5.如权利要求1所述的方法,其特征在于,该方法进一步包括:
当子环发生故障时,子环上的故障链路两端的传输节点定时向第二主节点发送链路故障报文,在所述故障链路恢复时停止发送链路故障报文;第二主节点在收到链路故障报文时,放开自身副端口的同时启动一定时器,之后每收到一个链路故障报文将该定时器复位,如果在一定时间内没有收到链路故障报文而导致定时器超时时,阻塞自身的副端口。
6.一种相交以太环网保护系统,该系统包括主环和与该主环相交的子环,其中,主环包括第一主节点和多个传输节点,各节点之间通过各自的端口相互连接形成主环,第一主节点包括主端口和副端口,子环包括第二主节点和多个传输节点,子环上的各节点之间通过各自的端口相互连接形成子环,第二主节点包括主端口和副端口,其特征在于,
第一主节点,用于在主环完整时,将自身的副端口置于阻塞状态;用于在主环和子环的相交链路以及主环的除该相交链路外的另一链路发生故障时,接收到由检测到故障的传输节点发送的链路故障报文后放开阻塞的副端口或者在预定时间内没有收到自身发送的健康检测报文后放开阻塞的副端口;用于在主环和子环的相交链路以及主环的除该相交链路外的另一链路的故障恢复时,接收到自身发送的健康检测报文,阻塞自身的副端口;
第二主节点,用于在子环完整时,将自身的副端口置于阻塞状态;用于在主环和子环的相交链路以及主环的除该相交链路外的另一链路发生故障时,保持自身副端口的阻塞状态。
7.如权利要求6所述的系统,其特征在于,
子环上的传输节点,用于在与自身相邻的子环链路发生故障时,向第二主节点发送链路故障报文,之后如果仍收到第二主节点发送的携带完整状态参数的健康检测报文,则重新发送链路故障报文;
第二主节点,用于在收到链路故障报文后,放开自身的副端口。
8.如权利要求6所述的系统,其特征在于,
子环上的传输节点,用于在与自身相邻的子环上的故障链路恢复时,将故障恢复的链路两端的端口设置为预阻塞状态,并在收到第二主节点发送的环网恢复刷新报文后,放开自身处于预阻塞状态的端口,如果在预设时间内没有收到第二主节点发送的环网恢复刷新报文,则不会放开自身处于预阻塞状态的端口;
第二主节点,用于在能够从自身的副端口收到自身发送的健康检测报文时,阻塞自身的副端口。
9.如权利要求8所述的系统,其特征在于,
子环上的传输节点,用于在与自身相邻的子环上的故障链路恢复时,将故障恢复的链路两端的端口设置为预阻塞状态后,在收到第二主节点发送的携带完整状态参数的健康检测报文时,也放开自身处于预阻塞状态的端口;或者,在收到子环上的其他节点发送的链路故障报文时,也放开自身处于预阻塞状态的端口。
10.如权利要求6所述的系统,其特征在于,
子环上的传输节点,用于在与自身相邻的子环上的链路发生故障时,定时向第二主节点发送链路故障报文,在所述故障链路恢复时停止发送链路故障报文;
第二主节点,用于在收到链路故障报文时,放开自身副端口的同时启动一定时器,之后每收到一个链路故障报文将该定时器复位,如果在一定时间内没有收到链路故障报文而导致定时器超时时,阻塞自身的副端口。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100822664A CN101534234B (zh) | 2009-04-20 | 2009-04-20 | 一种相交以太环网保护方法和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100822664A CN101534234B (zh) | 2009-04-20 | 2009-04-20 | 一种相交以太环网保护方法和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101534234A CN101534234A (zh) | 2009-09-16 |
CN101534234B true CN101534234B (zh) | 2011-05-11 |
Family
ID=41104634
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2009100822664A Active CN101534234B (zh) | 2009-04-20 | 2009-04-20 | 一种相交以太环网保护方法和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101534234B (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101789903B (zh) * | 2009-12-30 | 2012-05-23 | 华为技术有限公司 | 一种半环网络的保护方法、设备及系统 |
CN101873244B (zh) * | 2010-06-09 | 2012-10-10 | 神州数码网络(北京)有限公司 | 一种多环路自动保护的方法 |
CN102281166B (zh) * | 2010-06-10 | 2014-03-12 | 大唐移动通信设备有限公司 | 一种以太链路中传输控制方法及装置 |
CN101924697B (zh) * | 2010-06-30 | 2012-07-11 | 北京科技大学 | 一种基于链路回溯恢复策略的双向启动恢复方法 |
CN102104521B (zh) * | 2011-03-04 | 2013-06-19 | 福建星网锐捷网络有限公司 | 以太环网链路故障恢复方法、以太环网及节点设备 |
CN109450764B (zh) * | 2018-10-31 | 2021-04-16 | 瑞斯康达科技发展股份有限公司 | 一种环网保护方法、装置及环形网络 |
-
2009
- 2009-04-20 CN CN2009100822664A patent/CN101534234B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN101534234A (zh) | 2009-09-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100521638C (zh) | 相交以太环网及其自动保护方法、以及环网节点设备 | |
CN100409634C (zh) | 快速环网保护方法及系统 | |
EP2245472B1 (en) | System and method for network recovery from multiple link failures | |
CN100450036C (zh) | 一种rrpp与局部stp组网故障恢复时防止环路的方法和装置 | |
CN101610193B (zh) | 以太环网自动发现及生成环的方法 | |
CN100493006C (zh) | 一种环路故障检测方法、子环主节点以及子环 | |
US8179788B2 (en) | Protection switching method and apparatus for use in ring network | |
CN101534234B (zh) | 一种相交以太环网保护方法和系统 | |
CN100454880C (zh) | 一种实现环网保护的方法及系统 | |
CN101227371B (zh) | 同级交换机设备间的备份切换方法和装置 | |
WO2008089614A1 (fr) | Procédé, système et dispositif de protection d'une liaison en anneau | |
CN101873244B (zh) | 一种多环路自动保护的方法 | |
CN101141381B (zh) | 网络节点及其所在环网减少媒介接入控制地址学习的方法 | |
CN101841450B (zh) | 多个环形拓扑构建相交环实现稳定通信的方法及系统 | |
WO2010031295A1 (zh) | 一种以太网故障恢复的控制方法 | |
AU2009295116A1 (en) | Control method for protecting failure recovery of Ethernet ring and Ethernet ring nodes | |
CN101989930B (zh) | 实现以太网双环的方法及其交换设备 | |
JP5491623B2 (ja) | アドレスのリフレッシュ方法及びシステム | |
CN110635940B (zh) | 一种eaps以太环网的主备倒换方法 | |
CN101645812A (zh) | 一种以太网相交环保护倒换方法 | |
CN101626335A (zh) | 一种双归连接网络的数据保护方法 | |
CN100550812C (zh) | 提高快速环网可靠性的方法、系统和节点设备 | |
CN101621443B (zh) | 一种以太环网保护系统的故障恢复方法 | |
CN101848128B (zh) | 在多个环形拓扑间实现稳定通信的方法、系统及拓扑结构 | |
CN102025584A (zh) | 基于g.8032的环网保护方法及其系统 |
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. |