CN108833247B - 链路故障恢复后的再切换方法及装置 - Google Patents

Abstract

本申请提供一种链路故障恢复后的再切换方法及装置。所述方法包括：第一节点将故障恢复后的第一端口的状态设置为完全阻塞状态；所述第一节点启动预先获取的定时器，当所述定时器时长超时时，更新所述第一端口的状态为部分阻塞状态；当所述第一节点接收到所述主节点发送的第一协议报文时，通过所述第一端口向第二节点发送所述第一协议报文，以使所述第二节点将所述第一协议报文通过RRPP组网传输至所述主节点；所述第一节点接收所述主节点发送的前向数据完成报文；根据所述前向数据完成报文，所述第一节点更新所述第一端口的状态为放开状态，以通过所述第一端口转发当前流量。如此，可提升RRPP组网链路可靠性。

Description

链路故障恢复后的再切换方法及装置

技术领域

本申请涉及通信链路切换技术领域，具体而言，涉及一种链路故障恢复后的再切换方法及装置。

背景技术

快速环网保护协议(英文：Rapid Ring Protection Protocol，简称：RRPP)是一个专门应用于以太网环网的链路层协议，提供主备环网链路切换机制，在RRPP组网链路发生故障时，将主链路切换至备链路，在RRPP组网链路故障恢复后，将备链路切换回主链路。

图1为现有RRPP组网链路正常运行的网络拓扑结构示意图，图2为现有RRPP组网链路发生故障时的网络拓扑结构示意图，图3为现有RRPP组网链路故障恢复后再进行切换的网络拓扑结构示意图。

如图1至图3所示，以RRPP组网包括一个主节点(A)以及三个传输节点(B、C、D)为例，主节点用于检测RRPP组网链路的完整状态，并在RRPP组网链路发生故障时执行链路切换。其中，主节点A的主端口(Pri端口)以预先设置的Hello Time周期发送协议报文。

如果主节点A确定发送与接收Hello报文的时间差小于超时时间阈值(FailTime)，则主节点A确定该RRPP组网链路处于完整状态。同时，主节点A将自身的备端口(Sec端口)的状态设置为部分阻塞状态(图中以黑实心圆表示)，以使Sec端口阻塞数据报文的传输而不阻塞协议报文的传输。

当传输节点B、C之间的链路发生故障时，传输节点B、C从自身的非故障端口分别向主节点A发送链路挂起(LinkDown)报文。主节点A接收到任一LinkDown报文后，确认RRPP组网链路处于故障状态。主节点A将部分阻塞的Sec端口的状态设置为放开状态，使之成为流量的转发路径端口，实现RRPP组网链路切换。

在链路故障恢复后，为避免形成临时环路，传输节点B、C将已恢复的故障端口的状态设置为部分阻塞状态。主节点A继续发送Hello报文，并在收到Hello报文后，将Sec端口的状态重新设置为部分阻塞状态，并发送前向数据(英文：Forwarding DataBase，简称：FDB，)完成(Complete-FDB)报文通知传输节点B以及传输节点C，以使该两节点分别将自身部分阻塞的端口的状态设置为放开状态，从而实现流量的转发路径的再次切换。

但该RRPP组网链路故障恢复后的再切换方法中，如果传输节点B与传输节点C之间的链路频繁在故障(Down)与恢复(Up)之间抖动(切换)，会导致流量的转发路径的频繁切换。由于每次切换都不可避免引起丢包，使得RRPP组网链路可靠性较低，影响正常业务数据传输。

发明内容

有鉴于此，本申请实施例提供了一种链路故障恢复后的再切换方法及装置，解决了/实现了RRPP组网链路可靠性较低的技术问题。

在第一方面，本申请实施例提供一种链路故障恢复后的再切换方法，应用于处于快速环网保护协议RRPP组网中的第一节点，所述RRPP组网还包括主节点，所述第一节点包括故障恢复后的第一端口，所述方法包括：

所述第一节点将所述第一端口的状态设置为完全阻塞状态，所述完全阻塞状态用于表征所述第一端口阻塞所述RRPP组网中协议报文和数据报文的传输；

所述第一节点启动预先获取的定时器；

当所述定时器时长超时时，更新所述第一端口的状态为部分阻塞状态，所述部分阻塞状态用于表征所述第一端口传输所述协议报文并阻塞所述数据报文的传输；

当所述第一节点接收到所述主节点发送的第一协议报文时，通过所述第一端口向第二节点发送所述第一协议报文，以使所述第二节点将所述第一协议报文通过所述RRPP组网传输至所述主节点；

所述第一节点接收所述主节点发送的前向数据完成报文，所述前向数据完成报文为所述主节点根据所述第一协议报文将所述主节点中用于转发当前流量的端口状态更新为部分阻塞状态后发送；

根据所述前向数据完成报文，所述第一节点更新所述第一端口的状态为放开状态，以通过所述第一端口转发当前流量。

结合第一方面，在第一种可能的实现方式中，所述第一节点将故障恢复后的第一端口的状态设置为完全阻塞状态之前，所述方法还包括：

所述第一节点接收所述主节点发送的第二协议报文，所述第二协议报文包括的预留字段携带所述定时器时长；

存储所述定时器时长。

结合第一方面，在第二种可能的实现方式中，所述第一节点启动预先获取的定时器之后，所述方法还包括：

当所述定时器时长未超时，且所述第一节点与所述第二节点之间的链路故障时，所述第一节点维持所述第一端口的状态为完全阻塞状态；

或者，

当所述定时器时长未超时，且所述第一端口再次故障时，所述第一节点维持所述第一端口的状态为完全阻塞状态。

结合第一方面，在第三种可能的实现方式中，所述方法还包括：

当所述定时器时长未超时，且用于转发当前流量的路径故障时，所述第一节点将所述第一节点中处于完全阻塞的端口的状态更新为放开状态。

结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，所述用于转发当前流量的路径故障，具体包括：

构成所述用于转发当前流量的路径的第三节点不可达，所述第三节点为所述第一节点的邻居节点；或者，

构成所述用于转发当前流量的路径的所述第一节点包括的第二端口故障；

所述第一节点将所述第一节点中处于完全阻塞的端口的状态更新为放开状态之后，所述方法还包括：

所述第一节点通过已更新为放开状态的端口在所述RRPP组网内发送故障通知报文，用于使接收到所述故障通知报文的节点将自身处于完全阻塞的端口的状态更新为放开状态。

结合第一方面的第四种可能的实现方式，在第五种可能的实现方式中，所述故障通知报文包括目的MAC地址和虚拟局域网标识；

所述目的MAC地址与所述RRPP组网中任一节点的MAC地址不同，所述目的MAC地址用于接收到所述故障通知报文的任一节点将所述故障通知报文再次传输；

所述虚拟局域网标识表征所述RRPP组网所属的控制虚拟局域网，所述虚拟局域网标识用于接收到故障通知报文的任一节点在所述RRPP组网所属的控制虚拟局域网内传输所述故障通知报文。

在第二方面，本申请实施例提供一种链路故障恢复后的再切换装置，应用于快速环网保护协议RRPP组网中的第一节点，所述RRPP组网还包括主节点，所述第一节点包括故障恢复后的第一端口，所述装置包括：

阻塞状态设置模块，用于将所述第一端口的状态设置为完全阻塞状态，所述完全阻塞状态用于表征所述第一端口阻塞所述RRPP组网中协议报文和数据报文的传输；

启动单元，用于启动预先获取的定时器；

阻塞状态第一更新模块，用于当所述定时器时长超时时，更新所述第一端口的状态为部分阻塞状态，所述部分阻塞状态用于表征所述第一端口传输所述协议报文并阻塞所述数据报文的传输；

协议报文传输模块，用于当接收到所述主节点发送的第一协议报文时，通过所述第一端口向第二节点发送所述第一协议报文，以使所述第二节点将所述第一协议报文通过所述RRPP组传输至所述主节点；

状态更新通知接收模块，用于接收所述主节点发送的前向数据完成报文，所述前向数据完成报文为所述主节点根据所述第一协议报文将所述主节点中用于转发当前流量的端口状态更新为部分阻塞状态后发送；

阻塞状态第二更新模块，用于根据所述前向数据完成报文，更新所述第一端口的状态为放开状态，以通过所述第一端口转发当前流量。

结合第二方面，在第一种可能的实现方式中，所述将故障恢复后的第一端口的状态设置为完全阻塞状态之前，所述阻塞状态设置模块还用于：

接收所述主节点发送的第二协议报文，所述第二协议报文包括的预留字段携带所述定时器时长；

存储所述定时器时长。

结合第二方面，在第二种可能的实现方式中，所述启动预先获取的定时器之后，所述阻塞状态第一更新模块还用于：

当所述定时器时长未超时，且所述第一节点与所述第二节点之间的链路故障时，维持所述第一端口的状态为完全阻塞状态。；

或者，

当所述定时器时长未超时，且所述第一端口再次故障时，维持所述第一端口的状态为完全阻塞状态。

结合第二方面，在第三种可能的实现方式中，所述阻塞状态第一更新模块还用于：

当所述定时器时长未超时，且用于转发当前流量的路径故障时，将所述第一节点中处于完全阻塞的端口的状态更新为放开状态。

结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，所述用于转发当前流量的路径故障，具体包括：

构成所述用于转发当前流量的路径的第三节点不可达，所述第三节点为所述第一节点的邻居节点；或者，

构成所述用于转发当前流量的路径的所述第一节点包括的第二端口故障；

所述装置还包括：

通知发送单元，用于通过已更新为放开状态的端口在所述RRPP组网内发送故障通知报文，用于使接收到所述故障通知报文的节点将自身处于完全阻塞的端口的状态更新为放开状态。

结合第二方面的第四种可能的实现方式，在第五种可能的实现方式中，所述故障通知报文包括目的MAC地址和虚拟局域网标识；

所述目的MAC地址与所述RRPP组网中任一节点的MAC地址不同，所述目的MAC地址用于接收到所述故障通知报文的任一节点将所述故障通知报文再次传输；

所述虚拟局域网标识表征所述RRPP组网所属的控制虚拟局域网，所述虚拟局域网标识用于接收到故障通知报文的任一节点在所述RRPP组网所属的控制虚拟局域网内传输所述故障通知报文。

在第三方面，本申请实施例提供一种计算机设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述的方法的步骤。

在第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述的方法的步骤。

相对于现有技术而言，本申请具有以下有益效果：

本申请提供的链路故障恢复后的再切换方法及装置，通过设置对已恢复的故障端口进行完全阻塞并启动定时器，使得在设置的定时器时长内，无论该RRPP组网链路发生多少次故障以及恢复抖动的情形，主节点检测到所述RRPP组网链路故障均还未恢复，从而维持当前的流量的转发路径，不进行流量的转发路径切换，有效减少RRPP组网链路的切换，避免过多切换导致的丢包，从而提升RRPP组网链路的可靠性，降低对正常业务数据传输的影响，保障正常业务数据传输，并可有效缩短用户流量中断的时间。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为现有RRPP组网链路正常运行的网络拓扑结构示意图；

图2为现有RRPP组网链路发生故障时的网络拓扑结构示意图；

图3为现有RRPP组网链路故障恢复后再进行切换的网络拓扑结构示意图；

图4为本申请实施例提供的链路故障恢复后的再切换方法的流程示意图；

图5为本申请实施例提供的设置端口的状态为完全阻塞状态的网络拓扑结构示意图；

图6为本申请实施例提供的配置定时器时长的网络拓扑结构示意图；

图7为本申请实施例提供的在时长内当前流量的转发路径发生故障的网络拓扑结构示意图；

图8为本申请实施例提供的链路故障恢复后的再切换装置的结构示意图；

图9为本申请实施例提供的计算机设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本申请的描述中，还需要说明的是，除非另有明确的规定和限定，术语“设置”、“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。

实施例一

图4为本申请实施例提供的链路故障恢复后的再切换方法的流程示意图。所述方法应用于RRPP组网中的第一节点，所述RRPP组网还包括主节点，所述第一节点包括故障恢复后的第一端口，如图4所示，该流程包括：

步骤401，所述第一节点将所述第一端口的状态设置为完全阻塞状态，所述完全阻塞状态用于表征所述第一端口阻塞所述RRPP组网中协议报文和数据报文的传输；

本申请实施例中，在RRPP组网的各节点正常运行时，通过RRPP组网的主路径转发数据流量，而在主路径发生故障(例如，构成主路径的第一节点的第一端口故障，导致主路径故障，无法继续转发数据流量)后，通过RRPP组网的备路径转发数据流量。

可以理解的是，本发明实施例中，当前通过备路径转发数据流量。

当主路径故障恢复(例如，第一端口恢复正常，是的朱枯竭恢复正常)后，第一节点将故障恢复后的第一端口的状态设置为完全阻塞状态，使该第一端口既阻塞数据报文的传输又阻塞协议报文的传输，从而使得主节点发送的Hello报文不能通过该第一端口在RRPP组网内进行传输。

步骤402，所述第一节点启动预先获取的定时器。

本申请实施例中，第一节点将故障恢复后的第一端口的状态设置为完全阻塞状态后，启动定时器。

可以理解的是，上述定时器还可为在先设置在第一节点中，或者，由主节点将定时器时长下发至第一节点中。

步骤403，当所述定时器时长超时时，更新所述第一端口的状态为部分阻塞状态，所述部分阻塞状态用于表征所述第一端口传输所述协议报文并阻塞所述数据报文的传输；

本申请实施例中，第一节点启动定时器后，在定时器时长内维持第一端口的状态为完全阻塞状态。无论该RRPP组网链路发生多少次故障(DOWN)以及恢复(UP)抖动的情形，由于主节点发送的Hello报文不能通过第一端口在RRPP组网内进行传输，因此，当前流量的转发路径维持不变，也即是当前流量的转发路径仍为备路径，直到定时器时长超时，第一节点更新第一端口的状态为部分阻塞状态。

步骤404，当所述第一节点接收到所述主节点发送的第一协议报文时，通过所述第一端口向第二节点发送所述第一协议报文，以使所述第二节点将所述第一协议报文通过所述RRPP组网传输至所述主节点；

本申请实施例中，主节点定时发送第一协议报文，由于第一节点在步骤403中将第一端口的状态更新为部分阻塞状态，使得第一端口可以接收第一协议报文，并能将第一协议报文传输至下一个节点(例如，第一节点的邻居节点为第二节点)。

步骤405，所述第一节点接收所述主节点发送的前向数据完成报文，所述前向数据完成报文为所述主节点根据所述第一协议报文将所述主节点中用于转发当前流量的端口状态更新为部分阻塞状态后发送；

本申请实施例中，主节点在接收到自身发送的第一协议报文后，确认RRPP组网中的各链路均为正常状态。主节点将该主节点中用于转发当前流量的端口的状态更新为部分阻塞状态后，向第一节点发送前向数据完成报文。

步骤406，根据所述前向数据完成报文，所述第一节点更新所述第一端口的状态为放开状态，以通过所述第一端口转发当前流量。

本申请实施例中，第一节点接收到前向数据完成报文后，更新第一端口的状态为放开状态。这样，数据报文和协议报文都可以通过第一端口传输，当前流量再次从备路径切换至主路径，从而完成流量的转发路径切换。

本申请实施例中，在RRPP组网链路故障的第一节点恢复时，第一节点设置故障恢复后的第一端口的状态为完全阻塞状态(阻塞数据报文和协议报文的传输)，使得在设置的定时器时长内，无论该RRPP组网链路发生多少次故障(DOWN)以及恢复(UP)抖动的情形，主节点通过发送周期性的Hello报文，均检测到RRPP组网链路的状态为故障状态，从而维持当前的流量的转发路径，不发生RRPP组网链路切换，从而能够在RRPP组网链路反复DOWN-UP过程中，有效减少RRPP组网链路的切换，避免RRPP组网链路抖动引起的过多切换导致的丢包，降低对正常业务数据传输的影响，能够提升RRPP组网链路的可靠性，保障正常业务数据传输，并可有效缩短用户流量中断的时间。

实施例二

本申请实施例中，在定时器启动后，第一节点与第二节点之间的链路也可能再次出现故障，此时，第一节点维持第一端口的状态为完全阻塞状态。或者，在定时器启动后，第一节点的第一端口再次出现故障，此时，第一节点维持第一端口的状态为完全阻塞状态。

当主路径再次出现故障时，第一节点通过将第一端口的状态维持在完全阻塞状态，可使当前流量仍通过备路径转发，避免主备路径之间的多次切换导致丢包的问题。

具体地，当所述定时器时长未超时，且所述第一节点与所述第二节点之间的RRPP组网链路故障时，所述第一节点维持所述第一端口的状态为完全阻塞状态；

或者，

当所述定时器时长未超时，且所述第一端口再次故障时，所述第一节点维持所述第一端口的状态为完全阻塞状态。

实施例三

本申请实施例中，所述RRPPRRPP组网包括的主节点数为一个，包括的传输节点数至少为三个。本申请实施例中，假设发生RRPP组网链路故障的节点包括：第一节点。RRPP组网链路故障发生前，流量的转发路径为主路径，方向为从所述第一节点传输至第二节点。主路径故障发生后，流量的转发路径为备路径。其中，对于主路径，数据流入对应的传输节点的端口为主端口，数据流出对应的传输节点的端口为备端口，主节点发送数据的端口为主端口，接收数据的端口为备端口。

对于发生在第一节点的RRPP组网链路故障，在故障恢复后，第一节点将自身的备用端口的状态设置为完全阻塞状态。本申请实施例中，若发生RRPP组网链路故障的节点包括主节点，则主节点在故障恢复后，将自身故障恢复的端口(主端口)的状态设置为完全阻塞状态。

当然，实际应用中，也可同时出现多个节点故障，即发生RRPP组网链路故障的节点包括多个节点，故障节点的处理过程与发生RRPP组网链路故障的节点为一个节点的处理过程相同。例如，假设发生RRPP组网链路故障的节点包括：第一节点和第二节点，则在故障恢复后，第一节点将自身的备用端口的状态设置为完全阻塞状态，以及，第二节点将自身的主端口的状态设置为完全阻塞状态。

下面通过具体的组网示例对本申请实施例提供的链路故障恢复后的再切换方法进行详细说明。图5为本申请实施例提供的设置端口的状态为完全阻塞状态的网络拓扑结构示意图。

如图5所示，在第一传输节点(传输节点B)与第二传输节点(传输节点C)发生RRPP组网链路故障前，主节点A至传输节点C的流量的转发路径为：主节点A->传输节点B->传输节点C。在RRPP组网链路故障时，主节点A将主节点A至传输节点C的流量的转发路径切换为：主节点A->传输节点D->传输节点C。

在传输节点B与传输节点C之间的RRPP组网链路故障恢复后，传输节点B将自身的备用端口(Sec端口)的状态设置为完全阻塞状态，使得该Sec端口阻塞数据报文以及RRPP协议报文的传输。传输节点C将自身的主端口(Pri端口)的状态设置为完全阻塞状态，使得该Pri端口阻塞数据报文以及RRPP协议报文的传输(图中以黑空心圆表示)。

同时，传输节点B与传输节点C分别启动定时器，由于传输节点B的Sec端口以及传输节点C的Pri端口的状态均为完全阻塞状态，使得主节点A接收不到自己发送的RRPP协议报文，不能发起流量的转发路径切换，因而，维持主节点A到传输节点C的流量的转发路径为：主节点A->传输节点D->传输节点C。

本申请实施例中，在定时器设置的时长超时之前，如果传输节点B与传输节点C之间的链路再次发生故障，由于传输节点B的Sec端口以及传输节点C的Pri端口仍然阻塞RRPP协议报文的传输，主节点A还是接收不到自己发送的RRPP协议报文。当前流量的转发路径维持不变，即：主节点A->传输节点D->传输节点C。

在定时器设置的时长超时后，传输节点B更新完全阻塞的Sec端口的状态为部分阻塞状态(阻塞数据报文但不阻塞协议报文的传输)。传输节点C更新完全阻塞的Pri端口的状态为部分阻塞状态。此时，主节点A可以接收到自己发送的RRPP协议报文。主节点A确认RRPP组网链路恢复正常，从而主节点A阻塞主节点A当前流量的转发路径端口，即Sec端口以避免环路。主节点A发送前向数据完成报文，此时，主节点A到传输节点C的流量的转发路径切换为：主节点A->传输节点B->传输节点C。

本申请实施例中，作为一可选实施例，该方法还包括：

在RRPP组网链路故障发生时，发生所述RRPP组网链路故障的节点向所述主节点发送链路挂起报文，以使所述主节点接收到任一所述链路挂起报文后，将自身处于部分阻塞的端口的状态更新为放开状态，以切换流量的转发路径。

本申请实施例中，若主节点对应的RRPP组网链路发生故障，例如，主节点A和传输节点B之间RRPP组网链路发生故障。因而，发生所述RRPP组网链路故障的节点包括主节点A和传输节点B。但只有传输节点B发送的链路挂起报文能够达到主节点A，主节点A发送的链路挂起报文不能够达到主节点A。

本申请实施例中，作为另一可选实施例，主节点A也可以是按照Hello Time周期发送协议报文。若在预先设置的超时时间阈值内未接收到发送的协议报文，将自身处于部分阻塞的端口的状态更新为放开状态。

实施例四

本申请实施例中，传输节点预先学习到的定时器时长可以是主节点统一配置的，这样，可以避免由各节点单独配置定时器时长而导致的时序问题，因而，作为一可选实施例，该方法还包括：

所述第一节点接收所述主节点发送的第二协议报文，所述第二协议报文包括的预留字段携带所述定时器时长；

存储所述定时器时长。

本申请实施例中，在主节点配置定时器时长。作为一可选实施例，可以利用第二协议报文。例如，Hello报文的预留字段设置定时器时长，从而通过对RRPP报文协议的扩展，实现定时器时长的配置。主节点向RRPP组网链路内的各传输节点发送第二协议报文，各传输节点通过解析接收的第二协议报文中的预留字段，得到定时器时长。

下面通过具体的组网示例对本申请实施例提供的链路故障恢复后的再切换方法进行详细说明。图6为本申请实施例提供的配置定时器时长的网络拓扑结构示意图。如图6所示，主节点A配置定时器时长，并将配置的定时器时长填充在Hello报文的预留字段中。作为一可选实施例，配置的定时器时长可以依据实际需要进行设置。例如，若经过统计发现RRPP组网链路抖动(故障与恢复的切换)的频率较高，可以设置较短的定时器时长。若经过统计发现RRPP组网链路抖动的频率较低，可以设置较长的定时器时长。

本申请实施例中，作为一可选实施例，如果各传输节点获得的定时器时长不为0，表明RRPP组网链路启用延时模式。如果获得的定时器时长为0，表明RRPP组网链路未启用延时模式。

本申请实施例中，通过在主节点配置定时器时长，并将配置的定时器时长携带在RRPP协议报文。例如，Hello报文中，传输至RRPP组网链路的各传输节点。RRPP组网链路的各传输节点通过学习，获取配置的定时器时长。这样，定时器时长配置操作简单，还能避免由各节点单独配置定时器时长而导致的时序问题。

实施例五

本申请实施例中，在发生RRPP组网链路故障的节点将对应的端口的状态设置为完全阻塞状态后，RRPP组网链路通过备份RRPP组网链路(当前流量的转发路径)进行数据报文传输。若在定时器时长内，如果备份RRPP组网链路也发生故障，将导致数据报文传输的中断。因而，为了有效避免这一情形，作为一可选实施例，该方法还包括：

当所述定时器时长未超时，且用于转发当前流量的路径故障时，所述第一节点将所述第一节点中处于完全阻塞的端口的状态更新为放开状态。

本申请实施例中，所述用于转发当前流量的路径故障，具体包括：

构成所述用于转发当前流量的路径的第三节点不可达，所述第三节点为所述第一节点的邻居节点；或者，

构成所述用于转发当前流量的路径的所述第一节点包括的第二端口故障；

所述第一节点将所述第一节点中处于完全阻塞的端口的状态更新为放开状态之后，所述方法还包括：

所述第一节点通过已更新为放开状态的端口在所述RRPP组网内发送故障通知报文，用于使接收到所述故障通知报文的节点将自身处于完全阻塞的端口的状态更新为放开状态。

本申请实施例中，在定时器时长内，若用于转发当前流量的转发路径发生故障。例如，构成用于转发当前流量的路径的第三节点不可达，其中，第三节点为第一节点的邻居节点。或者，构成用于转发当前流量的路径的第一节点包括的第二端口故障。第一节点将第一节点中处于完全阻塞的端口的状态更新为放开状态。第一节点在将第一节点中处于完全阻塞的端口的状态更新为放开状态后，通过已更新为放开状态的端口在RRPP组网内发送故障通知(Fault Notify)报文，用于使接收到该故障通知报文的节点将自身处于完全阻塞的端口的状态更新为放开状态。

本申请实施例中，作为一可选实施例，如果第一节点从当前流量的转发路径接收不到信息或发不出信息。例如，接收不到主节点发送的数据报文，或者，接收不到相邻节点发送的心跳报文；或者，发送的数据报文或心跳报文超时没有响应，可以确定当前流量的转发路径发生故障，从而将自身处于完全阻塞的端口的状态更新为放开状态，以便切换转发路径。

下面通过具体的组网示例对本申请实施例提供的链路故障恢复后的再切换方法进行详细说明。图7为本申请实施例提供的在时长内当前流量的转发路径发生故障的网络拓扑结构示意图。如图7所示，本申请实施例中，如果在定时器设置的时长超时之前，当前流量的转发路径(主节点A->传输节点D->传输节点C)中的传输节点C与传输节点D之间的链路发生了故障。例如，以传输节点C的Sec端口发生故障为例。

传输节点C会将自身处于完全阻塞的Pri端口的状态更新为放开状态，而传输节点D的端口的状态为放开，因而，传输节点D无需更新自身端口的状态。同时，传输节点C与传输节点D分别发送Fault Notify报文。由于传输节点B的Sec端口的状态处于完全阻塞状态，阻塞了协议报文的传输。传输节点C发送的Fault Notify报文被传输节点B阻塞，无法在RRPP组网内发送Fault Notify报文。FaultNotify报文通过传输节点D在RRPP组网内发送，FaultNotify报文经过主节点A传输到传输节点B。

传输节点B收到Fault Notify报文后，判断当前处于定时器时长内，将自身处于完全阻塞的所有端口的状态设置为放开状态，即放开阻塞数据报文和协议报文传输的Sec端口。此时，主节点A到传输节点C的RRPP组网链路转发路径切换到主节点A->传输节点B->传输节点C，能够保证丢包在50ms以内。

再例如，以传输节点D的Sec端口发生故障为例。

传输节点D的Sec端口发生故障后，主节点A检测到传输节点D不可达时，主节点A以及传输节点D检查自身是否有处于完全阻塞的端口，在该申请实施例中，主节点A以及传输节点D均没有处于完全阻塞的端口，因而，主节点A和传输节点D均无需更新自身端口的状态。同时，主节点A和传输节点D分别发送Fault Notify报文。

传输节点D通过Pri端口发送的Fault Notify报文可以到达传输节点C。传输节点C收到Fault Notify报文后，判断当前处于定时器时长内，将自身处于完全阻塞的所有端口的状态设置为放开状态，即放开阻塞数据报文和协议报文传输的Sec端口。

主节点A通过Pri端口发送的Fault Notify报文可以到达传输节点B。传输节点B收到Fault Notify报文后，判断当前处于定时器时长内，将自身处于完全阻塞的所有端口的状态设置为放开状态，即放开阻塞数据报文和协议报文传输的Sec端口。

此时，主节点A到传输节点D的RRPP组网链路转发路径切换到主节点A->传输节点B->传输节点C->传输节点D。

本申请实施例中，作为另一可选实施例，在所述更新处于部分阻塞的端口状态为开放以切换流量的转发路径之后，该方法还包括：

对所述定时器清零，在所述定时器清零后，关闭所述定时器。

本申请实施例中，作为再一可选实施例，若在关闭定时器后，当前流量的转发路径发生故障。发生故障的当前流量的转发路径对应的传输节点分别从自身的非故障端口向主节点A发送LinkDown报文。主节点A接收到任一LinkDown报文或确认发送Hello报文与接收Hello报文的时间差大于或等于预先设置的超时时间阈值，将自身处于部分阻塞的Sec端口的状态更新为放开状态，使之成为流量的转发路径端口，实现流量的转发路径切换，以避免流量不通。

本申请实施例中，作为一可选实施例，Fault Notify报文包括目的MAC地址和虚拟局域网标识；

所述目的MAC地址与所述RRPP组网中任一节点的MAC地址不同，所述目的MAC地址用于接收到所述故障通知报文的任一节点将所述故障通知报文再次传输；

所述虚拟局域网标识表征所述RRPP组网所属的控制虚拟局域网，所述虚拟局域网标识用于接收到故障通知报文的任一节点在所述RRPP组网所属的控制虚拟局域网内传输所述故障通知报文。

本申请实施例中，作为一可选实施例，目的MAC地址为与RRPP组网链路中任一节点的MAC地址不同的MAC地址。例如，00-0F-E2-07-82-27，以进行RRPP组网链路隔离，即进行RRPP组网的域间隔离。携带的虚拟局域网为该RRPP组网链路的控制VLAN。

本申请实施例中，作为另一可选实施例，在第一节点更新所述第一端口的状态为放开状态之后，该方法还包括：

依据所述更新的第一端口的状态，更新RRPP组网链路各节点流量的转发路径表中的目的MAC地址、地址解析协议表项以及邻居发现(英文：Neighbor Discovery，简称：ND)协议表项。

本申请实施例中，在更新端口的状态从而形成新的流量的转发路径后，需要对各节点中的流量的转发路径表进行相应更新，以能够完成流量的转发路径切换后的业务数据传输。

本申请实施例中，若发生所述RRPP组网链路故障的节点包括主节点，则主节点通过是否接收到自身发送的协议报文，确定是否将自身的当前流量的转发路径端口的状态更新为部分阻塞状态。主节点在将端口的状态更新为部分阻塞状态后，发送前向数据完成报文。主节点在接收到自身发送的前向数据完成报文后，更新处于部分阻塞的端口的状态为放开状态，以切换当前流量的转发路径。

实施例六

图8为本申请实施例提供的链路故障恢复后的再切换装置的结构示意图。所述装置应用于快速环网保护协议RRPP组网中的第一节点，所述RRPP组网还包括主节点，所述第一节点包括故障恢复后的第一端口，所述装置包括：

阻塞状态设置模块81，用于将所述第一端口的状态设置为完全阻塞状态，所述完全阻塞状态用于表征所述第一端口阻塞所述RRPP组网中协议报文和数据报文的传输；

启动单元82，用于启动预先获取的定时器；

阻塞状态第一更新模块83，用于当所述定时器时长超时时，更新所述第一端口的状态为部分阻塞状态，所述部分阻塞状态用于表征所述第一端口传输所述协议报文并阻塞所述数据报文的传输；

协议报文传输模块84，用于当接收到所述主节点发送的第一协议报文时，通过所述第一端口向第二节点发送所述第一协议报文，以使所述第二节点将所述第一协议报文通过所述RRPP组网链路传输至所述主节点；

状态更新通知接收模块85，用于接收所述主节点发送的前向数据完成报文，所述前向数据完成报文为所述主节点根据所述第一协议报文将所述主节点中用于转发当前流量的端口状态更新为部分阻塞状态后发送；

阻塞状态第二更新模块86，用于根据所述前向数据完成报文，所述第一节点更新所述第一端口的状态为放开状态，以通过所述第一端口转发当前流量。

本申请实施例中，作为一可选实施例，所述第一节点将故障恢复后的第一端口的状态设置为完全阻塞状态之前，阻塞状态设置模块81还用于：

接收所述主节点发送的第二协议报文，所述第二协议报文包括的预留字段携带所述定时器时长；

存储所述定时器时长。

本申请实施例中，作为另一可选实施例，所述第一节点启动预先获取的定时器之后，阻塞状态第一更新模块83还用于：

当所述定时器时长未超时，且所述第一节点与所述第二节点之间的链路故障时，所述第一节点维持所述第一端口的状态为完全阻塞状态；

或者，

当所述定时器时长未超时，且所述第一端口再次故障时，维持所述第一端口的状态为完全阻塞状态。

本申请实施例中，作为再一可选实施例，阻塞状态第一更新模块83还用于：

当所述定时器时长未超时，且用于转发当前流量的路径故障时，将所述第一节点中处于完全阻塞的端口的状态更新为放开状态。

本申请实施例中，作为一可选实施例，所述用于转发当前流量的路径故障，具体包括：

构成所述用于转发当前流量的路径的第三节点不可达，所述第三节点为所述第一节点的邻居节点；或者，

构成所述用于转发当前流量的路径的所述第一节点包括的第二端口故障；

所述装置还包括：

通知发送单元(图中未示出)，用于通过已更新为放开状态的端口在所述RRPP组网内发送故障通知报文，用于使接收到所述故障通知报文的节点将自身处于完全阻塞的端口的状态更新为放开状态。

本申请实施例中，作为一可选实施例，所述故障通知报文包括目的MAC地址和虚拟局域网标识；

所述目的MAC地址与所述RRPP组网中任一节点的MAC地址不同，所述目的MAC地址用于接收到所述故障通知报文的任一节点将所述故障通知报文再次传输；

所述虚拟局域网标识表征所述RRPP组网所属的控制虚拟局域网，所述虚拟局域网标识用于接收到故障通知报文的任一节点在所述RRPP组网内所属的控制虚拟局域网传输所述故障通知报文。

图9为本申请实施例提供的计算机设备的结构示意图。如图9所示，本申请一实施例提供的一种计算机设备，用于执行图1至图7中的链路故障恢复后的再切换方法，该设备包括存储器1000、处理器2000及存储在该存储器1000上并可在该处理器2000上运行的计算机程序，其中，上述处理器2000执行上述计算机程序时实现上述链路故障恢复后的再切换方法的步骤。

具体地，上述存储器1000和处理器2000能够为通用的存储器和处理器，这里不做具体限定，当处理器2000运行存储器2000存储的计算机程序时，能够执行上述链路故障恢复后的再切换方法，从而解决现有技术RRPP组网链路可靠性较低的问题，本申请通过设置对已恢复的故障端口进行完全阻塞并启动定时器，使得在设置的定时器时长内，无论该RRPP组网链路发生多少次故障以及恢复抖动的情形，主节点检测到所述RRPP组网链路故障均还未恢复，从而维持当前的流量的转发路径，不进行流量的转发路径切换，有效减少RRPP组网链路的切换，避免过多切换导致的丢包，从而提升RRPP组网链路的可靠性，降低对正常业务数据传输的影响，保障正常业务数据传输，并可有效缩短用户流量中断的时间。

对应于图1至图7中的链路故障恢复后的再切换方法，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述链路故障恢复后的再切换方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述链路故障恢复后的再切换方法，解决现有技术RRPP组网链路可靠性较低的问题，本申请通过设置对已恢复的故障端口进行完全阻塞并启动定时器，使得在设置的定时器时长内，无论该RRPP组网链路发生多少次故障以及恢复抖动的情形，主节点检测到所述RRPP组网链路故障均还未恢复，从而维持当前的流量的转发路径，不进行流量的转发路径切换，有效减少RRPP组网链路的切换，避免过多切换导致的丢包，从而提升RRPP组网链路的可靠性，降低对正常业务数据传输的影响，保障正常业务数据传输，并可有效缩短用户流量中断的时间

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种链路故障恢复后的再切换方法，其特征在于，所述方法应用于处于快速环网保护协议RRPP组网中的第一节点，所述RRPP组网还包括主节点，所述第一节点包括故障恢复后的第一端口，所述方法包括：

所述第一节点将所述第一端口的状态设置为完全阻塞状态，所述完全阻塞状态用于表征所述第一端口阻塞所述RRPP组网中协议报文和数据报文的传输；

所述第一节点启动预先获取的定时器；

当所述定时器时长超时时，更新所述第一端口的状态为部分阻塞状态，所述部分阻塞状态用于表征所述第一端口传输所述协议报文并阻塞所述数据报文的传输；

当所述第一节点接收到所述主节点发送的第一协议报文时，通过所述第一端口向第二节点发送所述第一协议报文，以使所述第二节点将所述第一协议报文通过所述RRPP组网传输至所述主节点；

所述第一节点接收所述主节点发送的前向数据完成报文，所述前向数据完成报文为所述主节点根据所述第一协议报文将所述主节点中用于转发当前流量的端口状态更新为部分阻塞状态后发送；

根据所述前向数据完成报文，所述第一节点更新所述第一端口的状态为放开状态，以通过所述第一端口转发当前流量；

所述第一节点启动预先获取的定时器之后，所述方法还包括：

当所述定时器时长未超时，且所述第一节点与所述第二节点之间的RRPP组网链路故障时，所述第一节点维持所述第一端口的状态为完全阻塞状态；

或者，

当所述定时器时长未超时，且所述第一端口再次故障时，所述第一节点维持所述第一端口的状态为完全阻塞状态。

2.根据权利要求1所述的方法，其特征在于，所述第一节点将故障恢复后的第一端口的状态设置为完全阻塞状态之前，所述方法还包括：

所述第一节点接收所述主节点发送的第二协议报文，所述第二协议报文包括的预留字段携带所述定时器时长；

存储所述定时器时长。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当所述定时器时长未超时，且用于转发当前流量的路径故障时，所述第一节点将所述第一节点中处于完全阻塞的端口的状态更新为放开状态。

4.根据权利要求3所述的方法，其特征在于，所述用于转发当前流量的路径故障，具体包括：

构成所述用于转发当前流量的路径的第三节点不可达，所述第三节点为所述第一节点的邻居节点；或者，

构成所述用于转发当前流量的路径的所述第一节点包括的第二端口故障；

所述第一节点将所述第一节点中处于完全阻塞的端口的状态更新为放开状态之后，所述方法还包括：

所述第一节点通过已更新为放开状态的端口在所述RRPP组网内发送故障通知报文，用于使接收到所述故障通知报文的节点将自身处于完全阻塞的端口的状态更新为放开状态。

5.根据权利要求4所述的方法，其特征在于，所述故障通知报文包括目的MAC地址和虚拟局域网标识；

所述目的MAC地址与所述RRPP组网中任一节点的MAC地址不同，所述目的MAC地址用于接收到所述故障通知报文的任一节点将所述故障通知报文再次传输；

所述虚拟局域网标识表征所述RRPP组网所属的控制虚拟局域网，所述虚拟局域网标识用于接收到故障通知报文的任一节点在所述RRPP组网所属的控制虚拟局域网内传输所述故障通知报文。

6.一种链路故障恢复后的再切换装置，其特征在于，所述装置应用于快速环网保护协议RRPP组网中的第一节点，所述RRPP组网还包括主节点，所述第一节点包括故障恢复后的第一端口，所述装置包括：

阻塞状态设置模块，用于将所述第一端口的状态设置为完全阻塞状态，所述完全阻塞状态用于表征所述第一端口阻塞所述RRPP组网中协议报文和数据报文的传输；

启动单元，用于启动预先获取的定时器；

阻塞状态第一更新模块，用于当所述定时器时长超时时，更新所述第一端口的状态为部分阻塞状态，所述部分阻塞状态用于表征所述第一端口传输所述协议报文并阻塞所述数据报文的传输；

协议报文传输模块，用于当接收到所述主节点发送的第一协议报文时，通过所述第一端口向第二节点发送所述第一协议报文，以使所述第二节点将所述第一协议报文通过所述RRPP组网传输至所述主节点；

状态更新通知接收模块，用于接收所述主节点发送的前向数据完成报文，所述前向数据完成报文为所述主节点根据所述第一协议报文将所述主节点中用于转发当前流量的端口状态更新为部分阻塞状态后发送；

阻塞状态第二更新模块，用于根据所述前向数据完成报文，更新所述第一端口的状态为放开状态，以通过所述第一端口转发当前流量；

所述启动预先获取的定时器之后，所述阻塞状态第一更新模块还用于：

当所述定时器时长未超时，且所述第一节点与所述第二节点之间的链路故障时，维持所述第一端口的状态为完全阻塞状态；

或者，

当所述定时器时长未超时，且所述第一端口再次故障时，维持所述第一端口的状态为完全阻塞状态。

7.根据权利要求6所述的装置，其特征在于，所述将故障恢复后的第一端口的状态设置为完全阻塞状态之前，所述阻塞状态设置模块还用于：

接收所述主节点发送的第二协议报文，所述第二协议报文包括的预留字段携带所述定时器时长；

存储所述定时器时长。

8.根据权利要求6所述的装置，其特征在于，所述阻塞状态第一更新模块还用于：

当所述定时器时长未超时，且用于转发当前流量的路径故障时，将所述第一节点中处于完全阻塞的端口的状态更新为放开状态。

9.根据权利要求8所述的装置，其特征在于，所述用于转发当前流量的路径故障，具体包括：

构成所述用于转发当前流量的路径的第三节点不可达，所述第三节点为所述第一节点的邻居节点；或者，

构成所述用于转发当前流量的路径的所述第一节点包括的第二端口故障；

所述装置还包括：

通知发送单元，用于通过已更新为放开状态的端口在所述RRPP组网内发送故障通知报文，用于使接收到所述故障通知报文的节点将自身处于完全阻塞的端口的状态更新为放开状态。

10.根据权利要求9所述的装置，其特征在于，所述故障通知报文包括目的MAC地址和虚拟局域网标识；

所述目的MAC地址与所述RRPP组网中任一节点的MAC地址不同，所述目的MAC地址用于接收到所述故障通知报文的任一节点将所述故障通知报文再次传输；

所述虚拟局域网标识表征所述RRPP组网所属的控制虚拟局域网，所述虚拟局域网标识用于接收到故障通知报文的任一节点在所述RRPP组网所属的控制虚拟局域网内传输所述故障通知报文。

Images