CN102347905A - 一种网络设备及其转发信息更新方法 - Google Patents

Abstract

本发明公开了一种网络设备及其转发信息更新方法，本申请应用于连接于堆叠系统的上行设备，该上行设备可以根据堆叠系统的成员设备的下行链路故障，对本地保存的转发表项进行更新，从而，优化现有聚合网络中的报文转发路径选择方案，在下行链路出现故障时，使得流量在堆叠系统的成员设备中能够更好的进行负载分担，减少聚合链路的转发负担，并避免了成员设备的链路拥塞，提高链路的可靠性。

Description

一种网络设备及其转发信息更新方法

技术领域

本发明涉及通信技术领域，特别涉及一种网络设备及其转发信息更新方法。

背景技术

IRF(Intelligent Resilient Framework，智能弹性架构)是一种堆叠技术。其核心思想是将多台设备通过IRF端口连接在一起，进行必要的配置后，虚拟化成一台“分布式设备”。使用这种虚拟化技术可以集合多台设备的硬件资源和软件处理能力，实现多台设备的协同工作、统一管理和不间断维护。如图1所示，为现有技术中的一种典型的IRF组网结构示意图。

在一个典型的IRF组网中，包括两类设备，IRF成员设备和独立运行设备。其中：

独立运行设备只能单机运行，不能与别的设备形成IRF，如图1中的Device(设备)。

IRF成员设备则可以与其它设备互连形成IRF，如图1中的Master(主设备)和Slave(从设备)。各IRF成员设备可以统一进行管理。

IRF主要具有以下优点：

1、简化管理。

IRF形成之后，用户通过任意成员设备的任意端口都可以登录IRF系统，对IRF内所有成员设备进行统一管理。

2、高可靠性。

IRF的高可靠性体现在多个方面，例如：IRF由多台成员设备组成，Master设备负责IRF的运行、管理和维护，Slave设备在作为备份的同时也可以处理业务。一旦Master设备故障，系统会迅速自动选举新的Master，以保证业务不中断，从而实现了设备的1∶N备份；此外，成员设备之间的IRF链路支持聚合功能，IRF和上、下层设备之间的物理链路也支持聚合功能，多条链路之间可以互为备份也可以进行负载分担，从而进一步提高了IRF的可靠性。

3、强大的网络扩展能力。

通过增加成员设备，可以轻松自如的扩展IRF的端口数、带宽。因为各成员设备都有CPU(Central Processing Unit，中央处理器)，能够独立处理协议报文、进行报文转发，所以IRF还能够轻松自如的扩展处理能力。

如图2所示，为现有技术中的一种IRF链路的应用场景的示意图，其中，IRF1、IRF2、IRF3和IRF4四台设备组成一个IRF系统，该IRF的各成员设备分别和网络上其他设备相连，实现IRF系统间的备份和带宽扩展。设备A和B为两台独立运行设备，分别有接口和IRF成员设备相连。这4个接口一般以聚合的形式存在，从而实现了设备A到设备B流量在IRF成员设备间的负载分担。

当某台IRF成员设备异常，无法正常转发报文时，可以通过断开该IRF成员设备和设备A间的链路，将经由该IRF成员设备的流量均匀的分担到其他IRF成员设备。

如图3A所示，为现有技术中的一种IRF链路故障的示意图，当设备A和IRF成员设备(IRF1)之间的链路断开时，流量也可以经由其他链路转发到IRF系统，进一步的，如图3B所示，为现有技术中的另一种IRF链路故障的示意图，当IRF成员设备(IRF1)和设备A，以及设备B之间的链路均断开时，流量也可以经由其他链路转发到IRF系统，

而在另一种场景下，如图4所示，为现有技术中的另一种IRF链路故障的示意图，当设备B和IRF某成员设备(IRF1)间的链路断开时，该成员设备(IRF1)收到流量后，也可以将流量经由IRF链路到其他IRF系统(IRF2)转发。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

上行设备通过IRF系统向其他目的设备转发报文，但是IRF成员设备连接的下行链路断开时，会导致IRF系统的部分IRF堆叠链路以及部分其他IRF成员设备连接的下行链路发生拥塞。

发明内容

本发明提供一种网络设备及其转发信息更新方法，使得堆叠系统的上行设备根据堆叠系统中成员设备通知的故障下行链路更新转发信息，将通过故障下行链路转发的流量切换到其他路径，减少可能发生的拥塞和丢包问题。

为达到上述目的，本发明一方面提供了一种网络设备的转发信息更新方法，该网络设备为连接于堆叠系统的上行设备，所述方法至少包括以下步骤：

上行设备接收来自堆叠系统中成员设备的故障通知消息，其中，所述故障通知消息中携带成员设备查询到的以故障下行链路作为转发路径的目的设备的地址信息；

所述上行设备在本地存储的转发表中，查询故障通知消息中地址信息对应的转发表项；

所述上行设备确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口包含故障通知消息到达端口及其他端口，则在该转发表项的出接口关联的端口中，删除故障通知消息到达端口。

优选的，所述方法还包括：

所述上行设备确定未查找到故障通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理。

优选的，所述方法还包括：

所述上行设备确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口仅包含故障通知消息到达端口，则不修改该转发表项的出接口；或，

所述上行设备确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口不包含故障通知消息到达端口，则不修改该转发表项的出接口。

优选的，所述方法还包括：

所述上行设备接收来自堆叠系统中成员设备发送的恢复通知消息，其中，所述恢复通知消息中携带成员设备查询到的以故障恢复的下行链路作为转发路径的目的设备的地址信息；

所述上行设备在本地存储的转发表中，查询恢复通知消息中地址信息对应的转发表项；

所述上行设备确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口包含与恢复通知消息到达端口同属于一个聚合端口的其他端口，则在该转发表项的出接口关联的端口中添加恢复通知消息到达端口。

优选的，所述方法还包括：

所述上行设备确定未查找到恢复通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理。

优选的，所述方法还包括：

所述上行设备确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口仅包含故障通知消息到达端口，则不修改该转发表项的出接口；或者

所述上行设备确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口与故障通知消息到达端口不属于同一个聚合端口，则不修改该转发表项的出接口。

另一方面，本发明还提供了一种网络设备，作为上行设备与堆叠系统相连接，其特征在于，至少包括：

接收模块，用于接收来自堆叠系统中成员设备的故障通知消息，其中，所述故障通知消息中携带成员设备查询到的以故障下行链路作为转发路径的目的设备的地址信息；

查询模块，用于在本地存储的转发表中，查询所述故障通知消息中地址信息对应的转发表项；

处理模块，用于确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口包含故障通知消息到达端口及其他端口，则在该转发表项的出接口关联的端口中，删除故障通知消息到达端口。

优选的，

所述处理模块，还用于确定未查找到故障通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理；或，

确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口仅包含故障通知消息到达端口，则不修改该转发表项的出接口；或，

确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口不包含故障通知消息到达端口，则不修改该转发表项的出接口。

优选的，

所述接收模块，还用于接收来自堆叠系统中成员设备发送的恢复通知消息，其中，所述恢复通知消息中携带成员设备查询到的以故障恢复的下行链路作为转发路径的目的设备的地址信息；

所述查询模块，还用于在本地存储的转发表中，查询恢复通知消息中地址信息对应的转发表项；

所述处理模块，还用于确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口包含与恢复通知消息到达端口同属于一个聚合端口的其他端口，则在该转发表项的出接口关联的端口中添加恢复通知消息到达端口。

优选的，

所述处理模块，还用于确定未查找到恢复通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理；或，

确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口仅包含故障通知消息到达端口，则不修改该转发表项的出接口；或，

确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口与故障通知消息到达端口不属于同一个聚合端口，则不修改该转发表项的出接口。

与现有技术相比，本发明具有以下优点：

通过应用本发明的技术方案，堆叠系统的上行设备可以在堆叠系统的成员设备检测到下行链路故障时，接收到故障通知消息，该故障通知消息中携带成员设备查询到的以故障下行链路作为转发路径的目的设备的地址信息，并据此对本地保存的转发表项进行更新，从而，优化现有聚合网络中的报文转发路径选择方案，在下行链路出现故障时，使得流量在堆叠系统的成员设备中能够更好的进行负载分担，减少成员设备的链路拥塞，提高链路的可靠性。

附图说明

图1为现有技术中的一种典型的IRF组网结构示意图；

图2为现有技术中的一种IRF链路的应用场景的示意图；

图3A和图3B分别为现有技术中的一种IRF链路故障的示意图；

图4为现有技术中的另一种IRF链路故障的示意图；

图5为本发明所提出的一种转发信息更新方法的流程示意图；

图6为本发明所提出的一种网络设备的结构示意图。

具体实施方式

图4所示，设备A和设备B之间经由IRF系统转发，设备A和设备B分别和每个IRF成员设备建立连接，各条链路组成聚合。所有经由设备A到达设备B的数据均可以在IRF成员设备上实现负载分担和链路备份。但是当IRF成员设备IRF1和设备B之间的链路断开时，设备A转发到IRF的数据会经由IRF1和IRF2之间的IRF链路转发到IRF2，并在IRF2上转发到设备B。这样保证了流量的转发。

但是，IRF2和设备B间的链路会同时存在经由IRF1转发的流量和经由IRF2转发的流量；当两条数据流量之和大于IRF2与设备B之间的链路带宽时，在IRF2上就会存在拥塞丢包。同时，流量经由IRF1和IRF2之间的IRF链路，会消耗该链路带宽，增加IRF链路的转发负担。并且，因为IRF系统无法通知到设备A自己同设备B之间的链路状态变化，IRF2上的拥塞丢包状态会一直持续下去。

基于上述分析，本发明提出了一种路由更新方法，使上行设备能够堆叠系统的成员设备的下行链路的状态对转发表项进行相应的修改，降低堆叠系统内各堆叠成员设备之间的堆叠链路上出现拥塞和丢包的可能性以及堆叠系统内各堆叠成员设备连接的下行链路上出现拥塞和丢包的可能性。

如图5所示，为本发明提出的一种路由更新方法的流程示意图，该方法具体包括以下步骤：

步骤S501、上行设备接收来自堆叠系统中成员设备的故障通知消息，其中，所述故障通知消息中携带成员设备查询到的以故障下行链路作为转发路径的目的设备的地址信息。

在具体的实施场景中，上述的地址信息是由堆叠系统的成员设备确定，并携带在故障通知消息中发送给上行设备的，具体的，上述目的地址信息在堆叠系统的成员设备上的处理过程为：

首先，堆叠系统的成员设备检测自身的各链路的状态，具体的检测策略可以是实时检测，可以是周期检测，也可以是基于一定条件或事件的触发式检测，而具体的检测方式可以是通过收发测试报文的方式进行检测，也可以使接收单向的保护报文的方式进行检测，当然，在实际的应用场景中，可以根据需要选择相应的检测策略和检测方式，凡是能够达到相应的检测效果的检测策略和检测方式均可以应用于本发明所提出的技术方案，这样的变化并不影响本发明的保护范围。

当成员设备检测到出现故障的下行链路时，成员设备向自身所连接的上行设备发送故障通知消息，其中，该故障通知消息中携带该成员设备中所存储的出接口为当前故障的下行链路的所有转发路径所对应的目的设备的地址信息。

在不同的网络环境下，上述地址信息的形式不同。譬如，在三层网络中，IRF成员设备检测到本地某条下行链路断开时，在本成员设备的路由表中查找以连接该下行链路的端口作为出接口的路由表项中的IP地址，将查找到的IP地址封装为链路状态通知报文通知到本成员设备直连的所有上行设备。在二层网络中，IRF成员设备检测到本地某条下行链路断开时，在本成员设备的MAC表中，查找以连接该下行链路的端口作为出接口的MAC表项中的MAC地址或MAC地址以及VLAN ID。。

步骤S502、所述上行设备在本地存储的转发表中，查询故障通知消息中地址信息对应的转发表项。

如果查询到，则执行步骤S503；

如果没有查询到，则执行步骤S506。

通过步骤上行设备能够识别断开的链路与本设备上记录的转发路径是否相关，以便进行相应的处理。

步骤S503、上行设备确定该转发表项的出接口关联的端口与故障通知消息到达端口的关系。

如果该转发表项的出接口关联的端口包含故障通知消息到达端口及其他端口，则执行步骤S504；如果该转发表项的出接口关联的端口仅包含故障通知消息到达端口，或该转发表项的出接口关联的端口不包含故障通知消息到达端口，则执行步骤S505。通过本步骤，上行设备判断是否可以通过堆叠系统的其他成员设备向上述的目的端进行流量传输。

本领域人员可根据本实施例的上述说明，在不同的网络环境下，以不同的方式实现上述步骤的处理。譬如，在三层网络中，上行设备根据路由表确定可以通过两个以上的等价路由到达目的设备，则将故障通知报文到达的端口对应的出接口从等价路由对应的多个接口中删除；或者，上行设备根据路由表确定可以只有一条路由到达目的设备，该路由的出接口所指向的聚合端口中包含故障通知报文到达的端口及其他物理端口，则将故障通知报文到达的端口从聚合端口中删除(若不包含则不对该路由表项进行更新)；或者，上行设备根据路由表确定可以只有一条路由到达目的设备，且该路由对应的出接口指向仅包含故障通知报文到达端口的聚合端口，则对路由表项不做修改；或者，上行设备根据路由表确定可以只有一条路由到达目的设备，且该路由对应的出接口指向故障通知报文到达端，则对路由表项不做修改。

在二层网络中，上行设备根据MAC表确定到达目的设备的转发路径对应出接口指向聚合端口，且该聚合端口包含故障通知报文到达的端口及其他物理端口，则将故障通知报文到达的端口从聚合端口中删除(如不包含则不对MAC表项进行更新)；或者，上行设备根据MAC表确定到达目的设备的转发路径对应出接口指向聚合端口，且该聚合端口仅包含故障通知报文到达端口，则对MAC表项不做修改；或者，上行设备根据MAC表确定到达目的设备的转发路径对应的出接口指向故障通知报文到达的端口，则对MAC表项不做更新。

步骤S504、上行设备在该转发表项的出接口关联的端口中，删除故障通知消息到达端口。

通过本步骤的处理，在后续的流量转发过程中，上行设备将不会再通过被删除的端口进行流量转发，避免由于下行链路中断而引起流量在堆叠系统内部进行二次转发，以及由此所带来的负载分担分配不均，甚至链路拥塞和丢包。步骤S505、上行设备不修改该转发表项的出接口。

此步骤的有益效果在于，保持上行设备通过堆叠系统向目的设备转发的路径可达，避免重新学习到达目的设备的路径。

步骤S506、上行设备对本地存储的转发表不做处理。

进一步的，如果通过上述步骤实现了对于故障通知消息中地址信息对应的转发表项的出接口关联的端口中的端口的删除，那么，在后续的处理过程中，如果该链路的故障恢复，那么，本发明的技术方案同样提出的相应的故障恢复流程，可以将相应的端口添加到相应的转发表项的出接口所关联的端口中，具体说明如下：

首先，上行设备接收来自堆叠系统中成员设备发送的恢复通知消息，其中，所述恢复通知消息中携带成员设备查询到的以故障恢复的下行链路作为转发路径的目的设备的地址信息。

与前述的步骤S501相类似，这里的地址信息是成员设备在检测到链路故障恢复后所生成，并通过相应的恢复通知消息携带给上行设备的，具体的信息生成方案与前述的地址信息的生成方式相类似，在此不再重复说明。

然后，上行设备在本地存储的转发表中，查询恢复通知消息中地址信息对应的转发表项。

如果上行设备确定未查找到恢复通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理。

而如果上行设备确定查找到恢复通知消息中地址信息对应的转发表项，则上行设备进一步确定该转发表项的出接口关联的端口与恢复通知消息到达端口的关系。

如果该转发表项的出接口关联的端口包含与恢复通知消息到达端口同属于一个聚合端口的其他端口，则在该转发表项的出接口关联的端口中添加恢复通知消息到达端口；

如果该转发表项的出接口关联的端口仅包含故障通知消息到达端口，或该转发表项的出接口关联的端口与故障通知消息到达端口不属于同一个聚合端口，则不修改该转发表项的出接口。

与现有技术相比，本发明具有以下优点：

通过应用本发明的技术方案，堆叠系统的上行设备可以在堆叠系统的成员设备检测到下行链路故障时，接收到故障通知消息，该故障通知消息中携带成员设备查询到的以故障下行链路作为转发路径的目的设备的地址信息，并据此对本地保存的转发表项(路由表或MAC表)进行更新，从而，优化现有聚合网络中的报文转发路径选择方案，在下行链路出现故障时，使得流量在堆叠系统的成员设备中能够更好的进行负载分担，减少聚合链路的转发负担，并避免了成员设备的链路拥塞，提高链路的可靠性。

为了进一步阐述本发明的技术思想，现结合具体的应用场景，对本发明的技术方案进行说明。

为了描述方便，本发明实施例中具体以IRF系统作为堆叠系统的一种具体示例，对本发明所提出的技术方案进行说明，在实际应用中，具体堆叠系统类型的变化并不会影响本发明的保护范围。

基于上述说明，本发明提供了一种在IRF组网环境中的路由更新方法，在下行链路断开时，上行设备(源设备)对相关转发路径重新选择。通过这样的处理，可以消除现有技术中存在的上行设备无法感知下行链路断开，引起IRF系统上转发拥塞丢包的缺陷，使得IRF技术在网络上的应用更加完善。

具体的，对本发明提出的一种IRF组网环境中的路由更新方法的处理流程进行说明如下：

首先，在IRF网络中，各IRF成员设备分别对自身所连接的各链路进行检测。

当IRF成员设备感知到本地某条下行链路断开时，需要查找本成员设备的所有出接口为该下行链路的路由，并将找到的所有路由的目的IP地址等信息(对于二层转发也可以选择目的MAC地址，VLAN等信息)组装为故障通知消息，通知到所有和本成员设备直连的设备(上行设备)。

上行设备收到故障通知消息后，记录收到该故障通知消息的端口，并从故障通知消息中得到目的IP地址等信息，根据得到的信息查找本设备上保存的相应的路由信息(对应相同目的端的路由信息)。

根据具体的查找结果，具体分为以下三种处理情况：

情况一、如果找不到相应的路由或者所找到的相应的路由的出接口不包含收到该故障通知消息的端口，则表示当前的链路更新和本设备的转发路径无关，不需要处理。

情况二、如果找到的相应的路由的出接口只有收到该故障通知消息的端口(比如上行设备的聚合组内只有本端口)，则表示无其他链路可以到达IRF系统，此时虽然还存在其他IRF成员设备到目的的路由，但是该其他IRF成员设备没有和上行设备相连，因此，上行设备仍旧需要通过与发送故障通知消息的IRF成员设备进行通信，来实现向IRF系统的流量传输。

此时，相应的流量需要经由该端口发送到发送故障通知消息的IRF成员设备，然后后再经由IRF链路转发到其他IRF成员设备。因此，上行设备中所找到的相应的路由当前同样不需要变化。

情况三、如果找到相应的路由，并且路由的出接口为包含收到故障通知消息的端口在内的多个端口，则更新该路由的出接口列表，将收到故障通知消息的端口删除。

同样参照前述的图4所示的应用场景，当IRF1将路由的下行链路断开的消息通知到设备A时，设备A需要修改本地保存的路由的出接口。原有的本地保存的路由的出接口为包含4个端口的聚合组(分别为与IRF1、IRF2、IRF3和IRF4相直连的四个端口)。设备A可以直接生成一个新的聚合组，新的聚合组中将设备A和IRF1直连的端口排除在外，同时更新路由的出接口为新的聚合组。在上行设备更新路由的出接口后，从设备A到设备B的流量转发，可以在IRF2、IRF3和IRF4三台IRF成员设备上实现负载分担，从而，避免了拥塞丢包的可能。

需要指出的是，当设备A和IRF系统之间的链路除与IRF1之间的链路外均断开时，设备A检查路由的出接口没有其他端口，则路由不需要变化，流量依然会转发到IRF1，并通过IRF链路的转发到其他IRF成员设备以查找下行接口，从而保证报文能够尽量转发。

当然，在具体的实施场景中，上述的更新过程也可以是通过将设备A和IRF1直连的端口所对应的路由在原有的聚合组中删除来实现，这样的变化并不影响本发明的保护范围。

进一步的，当IRF成员设备和下行设备之间的链路恢复时，IRF成员设备同样会检查所有出接口为该故障恢复的下行链路的路由，并将这些路由的目的地址信息携带在恢复通知消息中通知到上行设备。

继续以图4所示的应用场景为例，在经过前述的处理，设备A将路由的出接口更新为将设备A和IRF1直连的端口排除在外的新的聚合组后，当IRF1和设备B之间的链路恢复时，IRF1查找出接口为该链路的所有路由，将对应的目的IP地址等信息携带在恢复通知消息中，通知到所有和本成员设备(IRF1)相连的上行设备。

上行设备收到该恢复通知消息后，从中得到目的IP地址等信息，根据得到的信息查找本设备上保存的路由信息。

根据具体的查找结果，具体分为以下三种处理情况：

情况一、不存在相应的路由，则表示当前的链路更新和本设备的转发路径无关，不需要处理。

情况二、存在相应的路由，但是相应的路由的出接口为普通端口，或者相应的路由的出接口和收到恢复通知消息的端口不处于同一个聚合组，则不更新路由。

情况三、存在相应的路由，并且该路由的出接口和收到恢复通知消息的端口处于同一个聚合组，则在该路由的出接口(出端口列表)中增加收到该恢复通知消息的端口。

这样，数据流可以在恢复后的多条链路上进行负载分担，从而减轻其他IRF成员设备链路的负担。

在具体的实施场景中，上述的方案同样适用于二层转发报文的链路反向通知，只是通知的信息不是目的IP地址等信息而是目的MAC地址、VLAN等信息。

与现有技术相比，本发明具有以下优点：

通过应用本发明的技术方案，堆叠系统的上行设备可以在堆叠系统的成员设备检测到下行链路故障时，接收到故障通知消息，该故障通知消息中携带成员设备查询到的以故障下行链路作为转发路径的目的设备的地址信息，并据此对本地保存的转发表项进行更新，从而，优化现有聚合网络中的报文转发路径选择方案，在下行链路出现故障时，使得流量在堆叠系统的成员设备中能够更好的进行负载分担，减少聚合链路的转发负担，并避免了成员设备的链路拥塞，提高链路的可靠性。

为了实现本发明的技术方案，基于前述的说明，本发明还提出了一种网络设备，作为上行设备与堆叠系统相连接，其结构示意图如图6所示，至少包括以下模块：

接收模块61，用于接收来自堆叠系统中成员设备的故障通知消息，其中，所述故障通知消息中携带成员设备查询到的以故障下行链路作为转发路径的目的设备的地址信息；

查询模块62，用于在本地存储的转发表中，查询所述故障通知消息中地址信息对应的转发表项；

处理模块63，用于确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口包含故障通知消息到达端口及其他端口，则在该转发表项的出接口关联的端口中，删除故障通知消息到达端口。

优选的，

所述处理模块63，还用于确定未查找到故障通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理；或，

确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口仅包含故障通知消息到达端口，则不修改该转发表项的出接口；或，

确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口不包含故障通知消息到达端口，则不修改该转发表项的出接口。

优选的，

所述接收模块61，还用于接收来自堆叠系统中成员设备发送的恢复通知消息，其中，所述恢复通知消息中携带成员设备查询到的以故障恢复的下行链路作为转发路径的目的设备的地址信息；

所述查询模块62，还用于在本地存储的转发表中，查询恢复通知消息中地址信息对应的转发表项；

所述处理模块63，还用于确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口包含与恢复通知消息到达端口同属于一个聚合端口的其他端口，则在该转发表项的出接口关联的端口中添加恢复通知消息到达端口。

优选的，

所述处理模块63，还用于确定未查找到恢复通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理；或，

确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口仅包含故障通知消息到达端口，则不修改该转发表项的出接口；或，

确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口与故障通知消息到达端口不属于同一个聚合端口，则不修改该转发表项的出接口。

与现有技术相比，本发明具有以下优点：

通过应用本发明的技术方案，堆叠系统的上行设备可以在堆叠系统的成员设备检测到下行链路故障时，接收到故障通知消息，该故障通知消息中携带成员设备查询到的以故障下行链路作为转发路径的目的设备的地址信息，并据此对本地保存的转发表项进行更新，从而，优化现有聚合网络中的报文转发路径选择方案，在下行链路出现故障时，使得流量在堆叠系统的成员设备中能够更好的进行负载分担，减少聚合链路的转发负担，并避免了成员设备的链路拥塞，提高链路的可靠性。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者OAM MASTER设备等)执行本发明各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本发明序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本发明的几个具体实施场景，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims (10)

1.一种应用于网络设备的转发信息更新方法，该网络设备是连接于堆叠系统的上行设备，其特征在于，所述方法至少包括以下步骤：

上行设备接收来自堆叠系统中成员设备的故障通知消息，其中，所述故障通知消息中携带成员设备查询到的以故障下行链路作为转发路径的目的设备的地址信息；

所述上行设备在本地存储的转发表中，查询故障通知消息中地址信息对应的转发表项；

所述上行设备确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口包含故障通知消息到达端口及其他端口，则在该转发表项的出接口关联的端口中，删除故障通知消息到达端口。

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

所述上行设备确定未查找到故障通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理。

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

所述上行设备确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口仅包含故障通知消息到达端口，则不修改该转发表项的出接口；或，

所述上行设备确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口不包含故障通知消息到达端口，则不修改该转发表项的出接口。

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

所述上行设备接收来自堆叠系统中成员设备发送的恢复通知消息，其中，所述恢复通知消息中携带成员设备查询到的以故障恢复的下行链路作为转发路径的目的设备的地址信息；

所述上行设备在本地存储的转发表中，查询恢复通知消息中地址信息对应的转发表项；

所述上行设备确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口包含与恢复通知消息到达端口同属于一个聚合端口的其他端口，则在该转发表项的出接口关联的端口中添加恢复通知消息到达端口。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

所述上行设备确定未查找到恢复通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理。

6.如权利要求4所述的方法，其特征在于，所述方法还包括：

所述上行设备确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口仅包含故障通知消息到达端口，则不修改该转发表项的出接口；或者

所述上行设备确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口与故障通知消息到达端口不属于同一个聚合端口，则不修改该转发表项的出接口。

7.一种网络设备，作为上行设备与堆叠系统相连接，其特征在于，至少包括：

接收模块，用于接收来自堆叠系统中成员设备的故障通知消息，其中，所述故障通知消息中携带成员设备查询到的以故障下行链路作为转发路径的目的设备的地址信息；

查询模块，用于在本地存储的转发表中，查询所述故障通知消息中地址信息对应的转发表项；

处理模块，用于确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口包含故障通知消息到达端口及其他端口，则在该转发表项的出接口关联的端口中，删除故障通知消息到达端口。

8.如权利要求7所述的网络设备，其特征在于，

所述处理模块，还用于确定未查找到故障通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理；或，

确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口仅包含故障通知消息到达端口，则不修改该转发表项的出接口；或，

确定查找到故障通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口不包含故障通知消息到达端口，则不修改该转发表项的出接口。

9.如权利要求7所述的网络设备，其特征在于，

所述接收模块，还用于接收来自堆叠系统中成员设备发送的恢复通知消息，其中，所述恢复通知消息中携带成员设备查询到的以故障恢复的下行链路作为转发路径的目的设备的地址信息；

所述查询模块，还用于在本地存储的转发表中，查询恢复通知消息中地址信息对应的转发表项；

所述处理模块，还用于确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口包含与恢复通知消息到达端口同属于一个聚合端口的其他端口，则在该转发表项的出接口关联的端口中添加恢复通知消息到达端口。

10.如权利要求9所述的网络设备，其特征在于，

所述处理模块，还用于确定未查找到恢复通知消息中地址信息对应的转发表项，则对本地存储的转发表不做处理；或，

确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口仅包含故障通知消息到达端口，则不修改该转发表项的出接口；或，

确定查找到恢复通知消息中地址信息对应的转发表项，且该转发表项的出接口关联的端口与故障通知消息到达端口不属于同一个聚合端口，则不修改该转发表项的出接口。

Images