CN101094186A - 一种保持邻居关系的方法和接口板 - Google Patents

Abstract

本发明公开了一种保持邻居关系的方法以及一种接口板。在分布式设备与其邻居设备中设定邻居关系保持报文；分布式设备中的接口板生成邻居关系保持报文，并在预先设置的每个报文发送周期到来时，向所述邻居设备发送邻居关系保持报文；所述邻居设备判断在预先设置的保活间隔内是否接收到邻居关系保持报文，如果是，则保持与分布式设备的邻居关系，否则，断开与分布式设备的邻居关系。本发明没有延长保活间隔，因此，可以保证网络的路由收敛速度，并且，即使分布式设备中发生主备倒换，也能够保证邻居设备在保活间隔内收到用于保持邻居关系的报文，因此，也保证了GR过程的成功。

Description

一种保持邻居关系的方法和接口板

技术领域

本发明涉及网络通信技术，特别是涉及一种保持邻居关系的方法和接口板。

背景技术

在网络中，分布式设备是一种将数据转发功能和控制功能分离的网络设备，其内部包括主控板和接口板。其中，主控板完成控制功能，如发现与其他设备之间的路由并与邻居设备保持邻居关系等，而接口板则完成数据转发功能。图1是双主控分布式设备的结构示意图。参见图1，在目前，为了提高分布式设备的可靠性，在分布式设备内部设置了主用主控板和备用主控板，当主用主控板发生故障时，进行主备倒换过程，备用主控板切换成主用主控板，负责所有控制业务的运行。

为了使得双主控分布式设备在进行主备倒换时，其数据转发业务不中断，目前提出了优雅重启(graceful restart，GR)的实现方案。分布式设备实现GR的过程包括：分布式设备在其控制软件重启即需要进行主备倒换时，向其邻居设备发出通知，邻居设备根据接收到的通知，在一段时间内可以实现到该分布式设备的邻居关系和路由不变，也就是说，该邻居设备仍然与分布式设备中的接口板进行正常的数据交互，使得网络的转发业务保持不中断，并且，在分布式设备的主备倒换完成后，该邻居设备还可以帮助倒换后的主用主控板完成路由信息同步，使得分布式设备恢复到正常工作状态。

目前，分布式设备与其邻居设备保持邻居关系的方法为：分布式设备中当前的主用主控板在每个报文发送周期到来时，向其邻居设备发送Hello报文，邻居设备监测在Hello报文对应的保活间隔内是否接收到分布式设备发来的Hello报文，如果接收到，则启动下一个保活间隔内的监测，并保持与分布式设备的邻居关系，即维持与分布式设备之间的路由不变，从而继续与分布式设备中的接口板进行数据交互，如果未接收到，则断开与分布式设备的邻居关系，同时删除下一跳为分布式设备的路由，从而不再与分布式设备中的接口板进行数据交互。

由以上描述可以看出，在现有的保持邻居关系的过程中，分布式设备是通过内部的主控板向邻居设备发送Hello报文从而保持邻居关系。这样，在GR实现过程中，如果分布式设备在Hello报文对应的保活间隔内未完成GR过程的主备倒换，就无法由主控板向其邻居设备发送Hello报文，使得邻居设备断开与分布式设备的邻居关系，从而导致分布式设备的数据流量中断，GR过程无法成功。

为了保证GR过程的成功，现有技术的一种处理方法为：延长Hello报文对应的保活间隔，使保活间隔的时间长度大于分布式设备主备倒换所需的时间长度，保证分布式设备在保活间隔内能够完成主备倒换，并向邻居设备发送Hello报文，从而保证GR过程的成功。

然而，现有技术延长保活间隔的做法会降低网络故障时的路由收敛速度，往往导致网络数据流量的中断。比如，当分布式设备发生整机断电故障或分布式设备与其邻居设备之间的链路断开，使得分布式设备根本无法再继续进行数据转发后，由于延长了保活间隔，邻居设备则只能在等待一个较长的时间后才能探测到该故障，才能进行相应的路由收敛处理，从而降低了网络的路由收敛速度，导致网络数据流量的长时间中断，大大降低了业务服务质量。

由此可见，如何在保证GR成功的同时保证网络的路由收敛速度，已经成为了一个亟待解决的问题。

发明内容

有鉴于此，本发明的一个目的在于提供一种保持邻居关系的方法，本发明的又一个目的在于提供一种接口板，以便于在保证GR成功的同时，保证网络的路由收敛速度。

为了达到上述目的，本发明的技术方案是这样实现的：

一种保持邻居关系的方法，在分布式设备与其邻居设备中设定邻居关系保持报文，该方法还包括：

分布式设备中的接口板生成邻居关系保持报文，并在预先设置的每个报文发送周期到来时，向所述邻居设备发送邻居关系保持报文；

所述邻居设备判断在预先设置的保活间隔内是否接收到邻居关系保持报文，如果是，则保持与分布式设备的邻居关系，否则，断开与分布式设备的邻居关系。

一种接口板，该接口板包括：

报文生成单元，用于生成邻居关系保持报文；

计时单元，用于在每次计时到达一个报文发送周期时，向收发单元发送触发通知；

收发单元，用于在接收到触发通知后，将报文生成单元生成的邻居关系保持报文发送至外部邻居设备。

可见，在本发明中，没有延长保活间隔，因此，可以保证网络的路由收敛速度，并且，又由于是由分布式设备中的接口板生成并发送保持邻居关系的报文，而不是由主控板生成并发送用于保持邻居关系的报文，因此，即使分布式设备中发生主备倒换，也能够保证邻居设备在保活间隔内收到用于保持邻居关系的报文，因此，也保证了GR过程的成功。

另外，在本发明中，不仅可以利用分布式设备与其邻居设备原来使用的Hello报文来作为保持邻居关系的报文，而且，还可以利用目前广泛使用的通用监测协议的探测报文来作为保持邻居关系的报文，因此，大大增加了本发明实现的灵活性。

附图说明

图1是分布式设备的结构示意图。

图2是在本发明实施例1中保持邻居关系的流程图。

图3是在本发明实施例2中保持邻居关系的流程图。

图4是在本发明一个实施例中提出的接口板内部的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图及具体实施例对本发明作进一步地详细描述。

本发明提出了一种保持邻居关系的方法。在该方法中，在分布式设备与其邻居设备中设定邻居关系保持报文；分布式设备中的接口板生成邻居关系保持报文，并在预先设置的每个报文发送周期到来时，向所述邻居设备发送邻居关系保持报文；所述邻居设备判断在预先设置的保活间隔内是否接收到邻居关系保持报文，如果是，则保持与分布式设备的邻居关系，否则，断开与分布式设备的邻居关系。

可见，在本发明提出的保持邻居关系的方法中，没有延长用于等待保持邻居关系的报文的保活间隔，因此，可以保证网络的路由收敛速度，并且，又由于是由分布式设备中的接口板生成并发送保持邻居关系的邻居关系保持报文，而不是由主控板生成并发送用于保持邻居关系的报文，因此，即使分布式设备中发生主备倒换，也能够保证邻居设备在保活间隔内收到用于保持邻居关系的报文，因此，也保证了GR过程的成功。

在本发明中，用于保持邻居关系的邻居关系保持报文可以采用多种方式实现，比如，

方式一、利用现有技术中用于保持邻居关系的Hello报文来实现。

方式二、利用通用监测协议的探测报文来实现。

下面针对上述实现邻居关系保持报文的两种方式分别举一个具体实施例来说明本发明的全部实现过程。

实施例1：

在本实施例中，邻居关系保持报文采用上述方式一中的Hello报文来实现。

图2是在本发明实施例1中保持邻居关系的流程图。参见图2，在本实施例中，保持邻居关系的一种较佳实现过程包括以下步骤：

步骤201：在分布式设备与其邻居设备中设定用于保持邻居关系的报文为Hello报文。

本步骤与现有技术的相应处理相同，均将Hello报文作为保持邻居关系的报文。

步骤202：在分布式设备中，当前的主用主控板与分布式设备的邻居设备建立邻居关系。

本步骤中，当前的主用主控板可以是分布式设备未发生主备倒换时的主用主控板，此时，本步骤以及图2后续步骤的处理可以是在分布式设备初始启动时，由初始的主用主控板触发执行的。比如，本步骤中，接口板1上的接口1刚启动路由协议如开放式最短路径优先路由(OSPF)协议或中间***间域内路由交换(ISIS)协议时，初始的主用主控板从该接口板1的接口1上发送Hello报文，当初始的主用主控板接收到邻居设备返回的Hello报文后，则与该邻居设备建立邻居结构。

另外，当前的主用主控板也可以是分布式设备发生主备倒换后的主用主控板，此时，本步骤以及图2后续步骤的处理可以是在分布式设备进行GR过程时，由倒换后的主用主控板触发执行的。

步骤203：当前的主用主控板检测所建立的邻居关系的状态是否达到稳定，如果是，则执行步骤205，否则，执行步骤204。

这里，检测邻居关系的状态是否达到稳定的方法为现有技术，可以简单举例为：如果分布式设备与其邻居设备支持的路由协议为OSPF协议，那么，当分布式设备中当前的主用主控板检测到与邻居设备之间的状态到达FULL时，则可确定邻居关系已到达稳定，否则，确定邻居关系未到达稳定；如果分布式设备与其邻居设备支持的路由协议为ISIS协议，那么，当分布式设备中当前的主用主控板检测到与邻居设备之间的状态到达UP时，则可确定邻居关系已到达稳定，否则，确定邻居关系未到达稳定。

另外，如果本步骤的处理是由倒换后的主用主控板触发执行的，也就是说是在分布式设备进行GR过程中执行的，那么，较佳地，在当前的主用主控板即倒换后的主用主控板检测到所建立的邻居关系的状态达到稳定后，可以不立即执行步骤205，而是等到GR过程结束后，再执行步骤205。

步骤204：当前的主用主控板在Hello报文对应的每个报文发送周期到来时，向分布式设备的邻居设备发送Hello报文，执行步骤203。

步骤205：当前的主用主控板将Hello报文对应的信息携带在故障探测触发通知中发送至接口板。

步骤206：分布式设备中的接口板从接收到的故障探测触发通知中获取Hello报文对应的信息。

步骤207：分布式设备中的接口板根据Hello报文对应的信息，生成Hello报文，并在每个Hello报文对应的报文发送周期到来时，向邻居设备发送Hello报文。

这里，Hello报文对应的信息至少包括Hello报文完整的内容、发送Hello报文的接口索引和报文发送周期。因此，在本步骤207中，分布式设备中的接口板可以根据获取的Hello报文完整的内容来生成Hello报文，并且根据获取的发送Hello报文的接口索引在接口板上对应的接口上发送Hello报文，并且，根据获取的报文发送周期来确定每个Hello报文对应的报文发送周期是否到来。

步骤208：分布式设备的邻居设备判断在Hello报文对应的保活间隔内是否接收到分布式设备发来的Hello报文，如果是，则执行步骤209，否则，执行步骤210。

步骤209：分布式设备的邻居设备保持与分布式设备的邻居关系，结束当前流程。

步骤210：分布式设备的邻居设备断开与分布式设备的邻居关系。

需要说明的是，在上述图2所示过程中，是由分布式设备中当前的主用主控板将Hello报文对应的信息发送给接口板，也就是说，分布式设备中的接口板是从当前的主用主控板中获取Hello报文对应的信息。此种情况下，如果当前的主用主控板需要修改Hello报文对应的信息，如修改Hello报文的相关参数或报文发送周期，则当前的主用主控板将更新后的Hello报文对应的信息发送至接口板，接口板则根据更新后的Hello报文对应的信息，发送Hello报文。

在实际的业务实现中，也可以直接在接口板上配置Hello报文对应的信息，这样，接口板则根据自身配置获取Hello报文对应的信息。此种情况下，如果需要修改Hello报文对应的信息，如修改Hello报文的相关参数或报文发送周期，则可以由管理人员将更新后的Hello报文对应的信息发送至接口板，接口板则根据更新后的Hello报文对应的信息，发送Hello报文。

进一步地，在上述图2所示流程中，如果当前的主用主控板需要中止Hello报文的发送(如当前的主用主控板接收到管理人员输入的去使能接口的路由协议的命令，或关闭接口的命令等)，那么，当前的主用主控板通知接口板，接口板根据接收到的通知停止发送Hello报文，并删除自身获取的Hello报文对应的信息。

实施例2：

在本实施例中，邻居关系保持报文采用上述方式二中的通用监测协议的探测报文来实现，并且，具体地，以目前应用广泛的双向转发探测(BFD)协议中的探测报文来实现。

图3是在本发明实施例2中保持邻居关系的流程图。参见图3，在本实施例中，保持邻居关系的一种较佳实现过程包括以下步骤：

步骤301：预先在分布式设备的接口板和其邻居设备中配置BFD协议。

这里，BFD协议是目前设备广泛支持的一种与路由协议无关的用于探测链路故障的通用监测协议。BFD协议中已经定义好了完成探测链路故障需要使用的探测报文的内容、报文发送周期和保活间隔。较佳地，在本步骤中，BFD对应的报文发送周期和保活间隔的时间长度，可以由BFD协议根据网络的故障探测敏感度要求设定。比如，网络要求在5秒内发现链路故障，那么，则可以将保活间隔的时间长度设为5秒。

步骤302：预先在分布式设备与其邻居设备中设定用于保持邻居关系的报文可以为BFD协议的探测报文。

步骤303：在分布式设备中，当前的主用主控板与分布式设备的邻居设备建立邻居关系。

步骤304：当前的主用主控板检测所建立的邻居关系的状态是否达到稳定，如果是，则执行步骤306，否则，执行步骤305。

步骤305：当前的主用主控板在Hello报文对应的每个报文发送周期到来时，向分布式设备的邻居设备发送Hello报文，执行步骤304。

上述步骤303至步骤305的具体实现过程的描述与图2中步骤202至步骤204的具体实现过程的描述相同。

步骤306：当前的主用主控板将故障探测触发通知发送至接口板。

步骤307：分布式设备中的接口板接收到故障探测触发通知后，根据配置的BFD协议，生成BFD协议的探测报文。

步骤308：分布式设备中的接口板根据配置的BFD协议，在每个探测报文对应的报文发送周期到来时，向邻居设备发送该探测报文。

步骤309：分布式设备的邻居设备根据配置的BFD协议，判断在探测报文对应的保活间隔内是否接收到分布式设备发来的探测报文，如果是，则执行步骤310，否则，执行步骤311。

步骤310：分布式设备的邻居设备保持与分布式设备的邻居关系，结束当前流程。

步骤311：分布式设备的邻居设备断开与分布式设备的邻居关系。

为了进一步确保GR过程的成功，较佳地，在本实施例2中，也可以延长Hello报文对应的保活间隔，使得该保活间隔大于主备倒换所需要的时间，这样，在GR过程中，当图3所示流程中的当前主用主控板为发生主备倒换后的主用主控板时，通过上述步骤303至步骤305的处理，则可以保证邻居设备在保活间隔内收到倒换后主用主控板发送的Hello报文，进一步确保邻居设备在GR过程中不会断开与分布式设备的邻居关系，保证GR过程的成功。另一方面，由于探测链路故障，触发网络路由收敛的处理是由接口板通过与邻居设备交互BFD协议的探测报文来实现，因此，即使延长Hello报文对应的保活间隔，也不会降低网络的路由收敛速度。

在上述图3所示过程中，是以通用监测协议中的BFD协议为例来说明本实施例的实现过程。在实际的业务实现中，也可以使用通用监测协议中的操作管理维护(OAM)协议，也就是说采用OAM协议中的探测报文来作为保持邻居关系的报文，其具体实现保持邻居关系的过程与上述图3所示过程相同。

在上述图2和图3所示过程中，较佳地，所使用的接口板为与所述邻居设备直接相连的接口板。

需要说明的是，由于在分布式设备的主用主控板与邻居设备建立的邻居关系未达到稳定之前，主用主控板所进行的邻居关系相关处理比较复杂，比如，需要与邻居设备进行状态协商以及进行邻居探测等，因此，在上述图2和图3所示过程中，采用了在邻居关系达到稳定之前，由当前的主用主控板发送能够保持邻居关系的Hello报文，在邻居关系达到稳定之后，再由接口板发送能够保持邻居关系的Hello报文或探测报文。当然，这种处理方式只是为了减少接口板的业务负荷量，保证接口板完成数据转发处理的较佳处理方式。在实际的业务实现过程中，也可以不考虑所建立的邻居关系的状态，在分布式设备启动后，始终由接口板发送能够保持邻居关系的Hello报文或探测报文。

本发明还提出了一种分布式设备，其内部的结构如图1所示，包括：主用主控板、备用主控板和接口板，其中，

接口板，用于生成邻居关系保持报文，并在预先设置的每个报文发送周期到来时，向分布式设备的邻居设备发送邻居关系保持报文。

具体地，分布式设备中的接口板可以采用分布式设备原有支持的Hello报文来作为邻居关系保持报文，此种情况下，所述接口板用于获取Hello报文对应的信息，并根据获取的该信息生成Hello报文，将Hello报文作为所述邻居关系保持报文进行上述的发送处理。

另外，分布式设备中的接口板还可以配置与路由协议无关的通用监测协议，如BFD协议或OAM协议等，并根据配置的通用监测协议生成探测报文，将探测报文作为所述邻居关系保持报文进行上述的发送处理。

较佳地，在分布式设备中，主用主控板则可以在与所述邻居设备建立邻居关系时，检测所建立的邻居关系的状态，当该邻居关系的状态达到稳定后，向所述接口板发送故障探测触发通知；所述接口板，在接收到故障探测触发通知后，再执行上述的生成邻居关系保持报文的处理。进一步地，所述主用主控板还在检测到所述邻居关系的状态未达到稳定之前，在Hello报文对应的每个报文发送周期到来时，向所述分布式设备的邻居设备发送Hello报文。

本发明还提出了一种接口板。图4是在本发明一个实施例中提出的接口板内部的结构示意图。参见图4，分布式设备中的接口板包括：报文生成单元、计时单元和收发单元，其中，

报文生成单元，用于生成邻居关系保持报文；

计时单元，用于在每次计时到达一个报文发送周期时，向收发单元发送触发通知；

收发单元，用于在接收到触发通知后，将报文生成单元生成的邻居关系保持报文发送至外部邻居设备。

参见图4，所述报文生成单元生成邻居关系保持报文的一种实现方式为：所述报文生成单元从所在分布式设备的当前主用主控板中获取Hello报文对应的信息或根据自身配置获取Hello报文对应的信息，并根据获取的该信息生成作为邻居关系保持报文的Hello报文。

参见图4，所述报文生成单元生成邻居关系保持报文的另一种实现方式为：所述报文生成单元配置与路由协议无关的通用监测协议，根据通用监测协议生成作为邻居关系保持报文的探测报文。

总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1、一种保持邻居关系的方法，其特征在于，在分布式设备与其邻居设备中设定邻居关系保持报文，该方法还包括：

分布式设备中的接口板生成邻居关系保持报文，并在预先设置的每个报文发送周期到来时，向所述邻居设备发送邻居关系保持报文；

所述邻居设备判断在预先设置的保活间隔内是否接收到邻居关系保持报文，如果是，则保持与分布式设备的邻居关系，否则，断开与分布式设备的邻居关系。

2、根据权利要求1所述的方法，其特征在于，所述邻居关系保持报文为Hello报文；所述报文发送周期和所述保活间隔分别为Hello报文对应的报文发送周期和保活间隔；

所述分布式设备中的接口板生成邻居关系保持报文的步骤包括：分布式设备中的所述接口板从当前的主用主控板中获取Hello报文对应的信息或根据自身配置获取Hello报文对应的信息，并根据获取的该信息生成Hello报文。

3、根据权利要求2所述的方法，其特征在于，所述Hello报文对应的信息包括：Hello报文完整的内容、发送Hello报文的接口索引和报文发送周期。

4、根据权利要求1所述的方法，其特征在于，该方法进一步包括：在分布式设备的所述接口板和所述邻居设备中配置与路由协议无关的通用监测协议；

所述邻居关系保持报文为通用监测协议的探测报文；所述报文发送周期和所述保活间隔分别为通用监测协议对应的报文发送周期和保活间隔。

5、根据权利要求4所述的方法，其特征在于，所述通用监测协议对应的报文发送周期和保活间隔的时间长度，由通用监测协议根据故障探测敏感度要求设定。

6、根据权利要求4所述的方法，其特征在于，所述通用监测协议为双向转发探测BFD协议或操作管理维护OAM协议。

7、根据权利要求1至6中任意一项所述的方法，其特征在于，该方法进一步包括：分布式设备中当前的主用主控板在与所述邻居设备建立邻居关系时，检测所建立的邻居关系的状态，在所述邻居关系的状态未达到稳定之前，当前的主用主控板在Hello报文对应的每个报文发送周期到来时，向所述分布式设备的邻居设备发送Hello报文，在所述邻居关系的状态达到稳定后，当前的主用主控板向所述接口板发送故障探测触发通知；

所述接口板在接收到故障探测触发通知后，执行所述的生成邻居关系保持报文的步骤。

8、根据权利要求1至6中任意一项所述的方法，其特征在于，所述接口板为与所述邻居设备直接相连的接口板。

9、一种接口板，其特征在于，该接口板包括：

报文生成单元，用于生成邻居关系保持报文；

计时单元，用于在每次计时到达一个报文发送周期时，向收发单元发送触发通知；

收发单元，用于在接收到触发通知后，将报文生成单元生成的邻居关系保持报文发送至外部邻居设备。

10、根据权利要求9所述的接口板，其特征在于，所述报文生成单元，用于从所在分布式设备的当前主用主控板中获取Hello报文对应的信息或根据自身配置获取Hello报文对应的信息，并根据获取的该信息生成作为邻居关系保持报文的Hello报文；或者，用于配置与路由协议无关的通用监测协议，根据通用监测协议生成作为邻居关系保持报文的探测报文。

Images