CN102984055B - 一种issu的软重启升级方法和设备 - Google Patents

Abstract

本发明公开了一种ISSU的软重启升级方法和设备，该方法包括：在本端设备进行ISSU的软重启升级之前，对端设备接收来自本端设备的代理发包请求报文；所述对端设备在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；在所述本端设备进行ISSU的软重启升级过程中，所述对端设备在检测到有物理接口的保活定时器超时时，通过所述物理接口查询端口索引表，如果有对应记录，则不进行协议老化处理；本发明中，可以降低主控板CPU的负担，防止网络拓扑发生震荡。

Description

一种ISSU的软重启升级方法和设备

技术领域

本发明涉及通信技术领域，特别是涉及一种ISSU（In-ServiceSoftwareUpgrade，不中断业务升级）的软重启升级方法和设备。

背景技术

ISSU是可靠性高的升级设备启动软件方式，其包括增量升级、软重启升级和重启升级，这三种方式都能够实现升级过程中业务不中断。其中，接口板需要进行软重启升级，主控板需要进行增量升级或重启升级；在接口板软重启升级开始前，主控板需要先升级完毕，并将持续处于正常稳定工作状态。

在接口板开始进行软重启升级时，需要将运行瞬间的数据（如运行数据、配置数据、硬件数据等）和状态保存在内存中；在软重启升级过程中，接口板CPU（CentralProcessingUnit，中央处理单元）会重启，且运行在接口板上的业务进程会全部退出，但是接口板的硬件并没有被重启，其将继续提供正常的报文转发能力；在软重启升级完毕之后，需要恢复上次保存的数据和状态，且接口板将使用升级后新版本继续正常运行。

对于接口板上运行的协议来说，有些协议全部由主控板CPU发送，如路由协议；有些协议部分由主控板CPU发送，部分由接口板CPU发送，如MSTP（MultipleSpanningTreeProtocol，多生成树协议），其物理口协议报文由接口板CPU发送，聚合口协议报文由主控板CPU发送；有些协议全部由接口板CPU发送，如LACP（LinkAggregationControlProtocol，链路聚合控制协议）。

在软重启升级过程中，由于接口板CPU会被重启，使得由接口板CPU发送的协议报文无法发送；基于此，需要由主控板CPU代理发送接口板CPU发送的协议报文。如图1所示，为现有技术中的网络示意图，设备Switch1（交换机1）处于网络的核心层，下面连接汇聚层设备RB6（RoutingBridge，路由桥）、RB7、RB8和RB9；假设Switch1上开启MSTP和LACP等协议，在Switch1的软重启升级过程中，由于接口板CPU重启，主控板CPU运行正常，原本由接口板CPU发送的协议报文，可通过Swich1设备的主控板代理发送。

但是，当进行软重启升级的设备是汇聚层或核心层设备时，汇聚层或核心层设备通常连接大量其它设备，且运行很多复杂业务，主控板CPU本身业务比较繁忙，如果由主控板CPU代理发送接口板CPU发送的协议报文，则会加重主控板CPU的负担；且主控板CPU可能无法及时代理发送接口板CPU发送的协议报文，进一步导致对端设备协议老化超时，网络拓扑发生震荡。

发明内容

本发明提供一种ISSU的软重启升级方法和设备，以降低主控板CPU的负担，并且可以防止网络拓扑发生震荡。

为达到上述目的，本发明实施例提供一种不中断业务升级ISSU的软重启升级方法，应用于包括相互直连的本端设备和对端设备的网络中，该方法包括以下步骤：

在所述本端设备进行ISSU的软重启升级之前，所述对端设备接收来自所述本端设备的用于表示需要进行软重启升级的代理发包请求报文，且所述代理发包请求报文中携带了需要代理发包的协议类型；

当所述协议类型为不需要转发协议保活报文的协议类型时，所述对端设备在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；

当所述协议类型为需要转发协议保活报文的协议类型时，所述对端设备在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；并在指定时间内收到所述协议类型对应的协议保活报文时，在代理发包内容表中记录收到所述协议保活报文的物理接口的标识和所述协议保活报文；

在所述本端设备进行ISSU的软重启升级过程中，所述对端设备在检测到有物理接口的保活定时器超时时，如果为不需要转发协议保活报文的协议类型的保活定时器，则通过所述物理接口查询端口索引表，如果有对应记录，则不进行协议老化处理；如果为需要转发协议保活报文的协议类型的保活定时器，则通过所述物理接口查询代理发包内容表，如果有对应记录，则不进行协议老化处理，并转发查询到的协议保活报文。

所述对端设备接收来自所述本端设备的用于表示需要进行软重启升级的代理发包请求报文之前，还包括：所述本端设备在进行ISSU的软重启升级之前，获得需要代理发包的物理接口，并通过获得的物理接口向所述对端设备发送所述代理发包请求报文。

所述方法进一步包括：当所述指定时间到期之后，所述对端设备向所述本端设备发送用于表示能够进行软重启升级的代理发包确认报文；由所述本端设备在收到所述代理发包确认报文之后，启动ISSU的软重启升级过程。

所述指定时间的设置方式，具体包括：所述对端设备根据所述协议类型对应的协议保活报文接收时间设置所述指定时间，且所述指定时间大于所述协议保活报文接收时间。

所述方法进一步包括：在所述本端设备进行ISSU的软重启升级完成之后，所述对端设备接收来自所述本端设备的用于表示已经完成软重启升级的代理发包结束报文，并通过所述代理发包结束报文确认ISSU的软重启升级过程结束。

本发明实施例提供一种不中断业务升级ISSU的软重启升级设备，作为对端设备应用于包括相互直连的本端设备和所述对端设备的网络中，所述对端设备包括：

接收模块，用于在所述本端设备进行ISSU的软重启升级之前，接收来自所述本端设备的用于表示需要进行软重启升级的代理发包请求报文，且所述代理发包请求报文中携带了需要代理发包的协议类型；

记录模块，用于当所述协议类型为不需要转发协议保活报文的协议类型时，在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；

当所述协议类型为需要转发协议保活报文的协议类型时，在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；并在指定时间内收到所述协议类型对应的协议保活报文时，在代理发包内容表中记录收到所述协议保活报文的物理接口的标识和所述协议保活报文；

维护模块，用于在所述本端设备进行ISSU的软重启升级过程中，在检测到有物理接口的保活定时器超时时，如果为不需要转发协议保活报文的协议类型的保活定时器，则通过所述物理接口查询端口索引表，如果有对应记录，则不进行协议老化处理；如果为需要转发协议保活报文的协议类型的保活定时器，则通过所述物理接口查询代理发包内容表，如果有对应记录，则不进行协议老化处理，并转发查询到的协议保活报文。

还包括：发送模块，用于当所述指定时间到期之后，向所述本端设备发送用于表示能够进行软重启升级的代理发包确认报文；由所述本端设备在收到所述代理发包确认报文之后，启动ISSU的软重启升级过程。

还包括：设置模块，用于根据所述协议类型对应的协议保活报文接收时间设置所述指定时间，且所述指定时间大于所述协议保活报文接收时间。

所述接收模块，还用于在所述本端设备进行ISSU的软重启升级完成之后，接收来自所述本端设备的用于表示已经完成软重启升级的代理发包结束报文，并通过所述代理发包结束报文确认ISSU的软重启升级过程结束。

本发明实施例提供一种不中断业务升级ISSU的软重启升级设备，作为本端设备应用于包括相互直连的所述本端设备和对端设备的网络中，所述本端设备包括：

第一发送模块，用于在本设备进行ISSU的软重启升级之前，获得需要代理发包的物理接口，并通过获得的物理接口向所述对端设备发送用于表示需要进行软重启升级的代理发包请求报文，且所述代理发包请求报文中携带了需要代理发包的协议类型；

接收模块，用于接收来自所述对端设备的用于表示能够进行软重启升级的代理发包确认报文；

启动模块，用于在收到所述代理发包确认报文之后，启动ISSU的软重启升级过程；

第二发送模块，用于在本设备进行ISSU的软重启升级完成之后，向所述对端设备发送用于表示已经完成软重启升级的代理发包结束报文。

与现有技术相比，本发明实施例至少具有以下优点：本发明实施例中，在设备进行ISSU的软重启升级过程中，不再通过主控板CPU代理发包，从而降低主控板CPU的负担，并提高设备和网络运行的可靠性和稳定性；而且可以防止软重启升级过程中的保活定时器超时，防止网络拓扑发生震荡。

附图说明

图1是现有技术中的网络示意图；

图2是本发明实施例提供的一种ISSU的软重启升级方法流程图；

图3是本发明实施例提出的应用场景示意图；

图4是本发明实施例提出的一种对端设备的结构示意图；

图5是本发明实施例提出的一种本端设备的结构示意图。

具体实施方式

下面结合附图对本发明实施例进行详细描述。

本发明实施例提出一种ISSU的软重启升级方法，该方法应用于包括相互直连的本端设备和对端设备的网络中，本实施例中以本端设备需要进行ISSU的软重启升级为例进行说明，如图2所示，该方法包括以下步骤：

步骤201，本端设备在进行ISSU的软重启升级之前，获得需要代理发包的物理接口，并通过获得的物理接口向对端设备发送代理发包请求报文。

本发明实施例中，该代理发包请求报文用于表示需要进行软重启升级，且该代理发包请求报文中携带了需要代理发包的协议类型。

以图3为本发明实施例的应用场景示意图，进行ISSU的软重启升级的设备为设备A，假设设备A、设备B和设备C上开启聚合功能，运行LACP协议；设备A、设备B、设备C、设备D和设备E上开启MSTP功能，运行MSTP协议。在图3中，设备A通过物理接口A_1连接设备B的物理接口B_1；设备A通过聚合口Agg1连接设备B的聚合口Agg1，设备A上Agg1包含物理接口A_2和物理接口A_3，设备B上Agg1包含物理接口B_2和物理接口B_3；设备A通过物理接口A_4连接设备C的物理接口C_1；设备A通过聚合口Agg2连接设备C的聚合口Agg2，设备A上Agg2包含物理接口A_5和物理接口A_6，设备C上Agg2包含物理接口C_2和物理接口C_3。

在上述应用场景下，设备A（即本端设备）在进行ISSU的软重启升级之前，需要遍历搜集需要代理发包的物理接口，且需要代理发包的物理接口包括物理接口A_1、物理接口A_2、物理接口A_3、物理接口A_4、物理接口A_5和物理接口A_6；进一步的，物理接口A_1和物理接口A_4对应的需要代理发包的协议类型为MSTP；物理接口A_2、物理接口A_3、物理接口A_5和物理接口A_6对应的需要代理发包的协议类型为LACP。

因此，设备A通过物理接口A_1发送携带需要代理发包的协议类型为MSTP的代理发包请求报文，通过物理接口A_2发送携带需要代理发包的协议类型为LACP的代理发包请求报文，通过物理接口A_3发送携带需要代理发包的协议类型为LACP的代理发包请求报文，通过物理接口A_4发送携带需要代理发包的协议类型为MSTP的代理发包请求报文，通过物理接口A_5发送携带需要代理发包的协议类型为LACP的代理发包请求报文，通过物理接口A_6发送携带需要代理发包的协议类型为LACP的代理发包请求报文。

步骤202，在本端设备进行ISSU的软重启升级之前，对端设备接收来自本端设备的代理发包请求报文，并确认本端设备需要进行软重启升级。

在图3所示的应用场景下，以设备B为对端设备的处理为例进行说明，设备C的处理与设备B类似，后续不再赘述。其中，设备B可以通过物理接口B_1收到来自物理接口A_1的携带需要代理发包的协议类型为MSTP的代理发包请求报文，通过物理接口B_2收到来自物理接口A_2的携带需要代理发包的协议类型为LACP的代理发包请求报文，通过物理接口B_3收到来自物理接口A_3的携带需要代理发包的协议类型为LACP的代理发包请求报文。

步骤203，对端设备在端口索引表中记录收到代理发包请求报文的物理接口的标识；如表1所示，为记录物理接口的标识的端口索引表。

表1

本发明实施例中，对端设备（如设备B）在收到代理发包请求报文之后，可以利用代理发包请求报文中携带的需要代理发包的协议类型，获知协议类型为不需要转发协议保活报文的协议类型（如LACP等），或者，获知协议类型为需要转发协议保活报文的协议类型（如MSTP等）。

当协议类型为不需要转发协议保活报文的协议类型时，对端设备只需要在端口索引表中记录收到代理发包请求报文的物理接口的标识；当协议类型为需要转发协议保活报文的协议类型时，对端设备需要在端口索引表中记录收到代理发包请求报文的物理接口的标识，并且还需要执行后续步骤204。

步骤204，当协议类型（如MSTP）为需要转发协议保活报文的协议类型时，如果在指定时间内收到MSTP对应的协议保活报文，则对端设备在代理发包内容表中记录收到协议保活报文的物理接口的标识和协议保活报文。

本发明实施例的一种优选实施方式中，如果在指定时间内收到MSTP对应的协议保活报文，则对端设备通过收到协议保活报文的物理接口的标识查询端口索引表；如果端口索引表中有对应的记录，则对端设备在代理发包内容表中记录收到协议保活报文的物理接口的标识和协议保活报文（即协议保活报文的具体内容）。

在图3所示的应用场景下，设备B可以通过物理接口B_1收到MSTP对应的协议保活报文，通过物理接口B_2收到LACP对应的协议保活报文，通过物理接口B_3收到LACP对应的协议保活报文；进一步的，通过物理接口B_1查询表1所示的端口索引表，可以获知端口索引表中有物理接口B_1对应的记录，因此需要在代理发包内容表中记录物理接口B_1和收到的MSTP对应的协议保活报文的具体内容，如表2所示。

表2

本发明实施例中，该指定时间的设置方式具体包括但不限于：对端设备根据协议类型对应的协议保活报文接收时间设置指定时间，且指定时间大于协议保活报文接收时间。例如，对于MSTP来说，对端设备可以将其指定时间设置为MSTP的协议保活报文接收时间的3倍。

本发明实施例中，当指定时间到期之后，对端设备还可以向本端设备发送用于表示能够进行软重启升级的代理发包确认报文；由本端设备在收到代理发包确认报文之后，可以直接开始启动ISSU的软重启升级过程。

进一步的，当没有需要转发协议保活报文的协议类型时，对端设备可以直接向本端设备发送代理发包确认报文；当需要转发协议保活报文的协议类型为多个时，对端设备需要等到每个需要转发协议保活报文的协议类型所对应的指定时间都到期之后，向本端设备发送代理发包确认报文。

对于需要转发协议保活报文的协议类型和不需要转发协议保活报文的协议类型，在维护上述端口索引表和代理发包内容表之后，在本端设备进行ISSU的软重启升级过程中，该方法还可以包括如下步骤：

步骤205，在本端设备进行ISSU的软重启升级过程中，对端设备在检测到有物理接口的保活定时器超时时，获取保活定时器对应的协议类型；如果为不需要转发协议保活报文的协议类型的保活定时器，则执行步骤206，如果为需要转发协议保活报文的协议类型的保活定时器，则执行步骤207。

在图3所示的应用场景下，当物理接口B_1的保活定时器超时时，保活定时器对应的协议类型为MSTP，即保活定时器为需要转发协议保活报文的协议类型的保活定时器，执行步骤207；当物理接口B_2的保活定时器超时时，保活定时器对应的协议类型为LACP，即保活定时器为不需要转发协议保活报文的协议类型的保活定时器，执行步骤206；当物理接口B_3的保活定时器超时时，保活定时器对应的协议类型为LACP，即保活定时器为不需要转发协议保活报文的协议类型的保活定时器，执行步骤206。

步骤206，对端设备通过保活定时器超时的物理接口的标识查询端口索引表，如果有对应记录，则不进行协议老化处理。

在图3所示的应用场景下，当物理接口B_2的保活定时器超时时，对端设备通过物理接口B_2查询端口索引表，且端口索引表中有物理接口B_2对应记录，因此物理接口B_2不需要进行LACP的协议老化处理，认为保活定时器没有超时；当物理接口B_3的保活定时器超时时，对端设备通过物理接口B_3查询端口索引表，且端口索引表中有物理接口B_3对应记录，因此物理接口B_3不需要进行LACP的协议老化处理，认为保活定时器没有超时。

步骤207，对端设备通过保活定时器超时的物理接口的标识查询代理发包内容表，如果有对应记录，则不进行协议老化处理，并转发查询到的协议保活报文（即代理发包内容表中记录的协议保活报文内容）。

在图3所示的应用场景下，当物理接口B_1的保活定时器超时时，对端设备通过物理接口B_1查询代理发包内容表，且代理发包内容表中有物理接口B_1对应记录，因此物理接口B_1不需要进行MSTP的协议老化处理，认为保活定时器没有超时；此外，对端设备还需要转发查询到的协议保活报文内容，即通过本设备CPU处理协议保活报文内容，从相应物理接口转发出去。

本发明实施例中，在本端设备进行ISSU的软重启升级完成之后，本端设备会正常发送协议报文，且本端设备向对端设备发送用于表示已经完成软重启升级的代理发包结束报文；对端设备在收到来自本端设备的代理发包结束报文之后，可以通过代理发包结束报文确认ISSU的软重启升级过程结束，后续进行正常的协议老化处理流程，即不再执行本发明实施例的上述流程。

基于与上述方法同样的发明构思，本发明还提出了一种不中断业务升级ISSU的软重启升级设备，作为对端设备应用于包括相互直连的本端设备和所述对端设备的网络中，如图4所示，所述对端设备包括：

接收模块11，用于在所述本端设备进行ISSU的软重启升级之前，接收来自所述本端设备的用于表示需要进行软重启升级的代理发包请求报文，且所述代理发包请求报文中携带了需要代理发包的协议类型；

记录模块12，用于当所述协议类型为不需要转发协议保活报文的协议类型时，在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；

当所述协议类型为需要转发协议保活报文的协议类型时，在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；并在指定时间内收到所述协议类型对应的协议保活报文时，在代理发包内容表中记录收到所述协议保活报文的物理接口的标识和所述协议保活报文；

维护模块13，用于在所述本端设备进行ISSU的软重启升级过程中，在检测到有物理接口的保活定时器超时时，如果为不需要转发协议保活报文的协议类型的保活定时器，则通过所述物理接口查询端口索引表，如果有对应记录，则不进行协议老化处理；如果为需要转发协议保活报文的协议类型的保活定时器，则通过所述物理接口查询代理发包内容表，如果有对应记录，则不进行协议老化处理，并转发查询到的协议保活报文。

还包括：发送模块14，用于当所述指定时间到期之后，向所述本端设备发送用于表示能够进行软重启升级的代理发包确认报文；由所述本端设备在收到所述代理发包确认报文之后，启动ISSU的软重启升级过程。

还包括：设置模块15，用于根据所述协议类型对应的协议保活报文接收时间设置所述指定时间，且所述指定时间大于所述协议保活报文接收时间。

所述接收模块11，还用于在所述本端设备进行ISSU的软重启升级完成之后，接收来自所述本端设备的用于表示已经完成软重启升级的代理发包结束报文，并通过所述代理发包结束报文确认ISSU的软重启升级过程结束。

其中，本发明装置的各个模块可以集成于一体，也可以分离部署。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。

基于与上述方法同样的发明构思，本发明还提出了一种不中断业务升级ISSU的软重启升级设备，作为本端设备应用于包括相互直连的所述本端设备和对端设备的网络中，如图5所示，所述本端设备包括：

第一发送模块21，用于在本设备进行ISSU的软重启升级之前，获得需要代理发包的物理接口，并通过获得的物理接口向所述对端设备发送用于表示需要进行软重启升级的代理发包请求报文，且所述代理发包请求报文中携带了需要代理发包的协议类型；

接收模块22，用于接收来自所述对端设备的用于表示能够进行软重启升级的代理发包确认报文；

启动模块23，用于在收到所述代理发包确认报文之后，启动ISSU的软重启升级过程；

第二发送模块24，用于在本设备进行ISSU的软重启升级完成之后，向所述对端设备发送用于表示已经完成软重启升级的代理发包结束报文。

其中，本发明装置的各个模块可以集成于一体，也可以分离部署。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。

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

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

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

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

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

Claims (8)

1.一种不中断业务升级ISSU的软重启升级方法，应用于包括相互直连的本端设备和对端设备的网络中，其特征在于，该方法包括以下步骤：

在所述本端设备进行ISSU的软重启升级之前，所述对端设备接收来自所述本端设备的用于表示需要进行软重启升级的代理发包请求报文，且所述代理发包请求报文中携带了需要代理发包的协议类型；

当所述协议类型为不需要转发协议保活报文的协议类型时，所述对端设备在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；

当所述协议类型为需要转发协议保活报文的协议类型时，所述对端设备在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；并在指定时间内收到所述协议类型对应的协议保活报文时，在代理发包内容表中记录收到所述协议保活报文的物理接口的标识和所述协议保活报文；

在所述本端设备进行ISSU的软重启升级过程中，所述对端设备在检测到有物理接口的保活定时器超时时，如果为不需要转发协议保活报文的协议类型的保活定时器，则通过所述物理接口查询端口索引表，如果有对应记录，则不进行协议老化处理；如果为需要转发协议保活报文的协议类型的保活定时器，则通过所述物理接口查询代理发包内容表，如果有对应记录，则不进行协议老化处理，并转发查询到的协议保活报文；

其中，所述指定时间的设置方式，具体包括：

所述对端设备根据所述协议类型对应的协议保活报文接收时间设置所述指定时间，且所述指定时间大于所述协议保活报文接收时间。

2.如权利要求1所述的方法，其特征在于，所述对端设备接收来自所述本端设备的用于表示需要进行软重启升级的代理发包请求报文之前，还包括：

所述本端设备在进行ISSU的软重启升级之前，获得需要代理发包的物理接口，并通过获得的物理接口向所述对端设备发送所述代理发包请求报文。

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

当所述指定时间到期之后，所述对端设备向所述本端设备发送用于表示能够进行软重启升级的代理发包确认报文；由所述本端设备在收到所述代理发包确认报文之后，启动ISSU的软重启升级过程。

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

在所述本端设备进行ISSU的软重启升级完成之后，所述对端设备接收来自所述本端设备的用于表示已经完成软重启升级的代理发包结束报文，并通过所述代理发包结束报文确认ISSU的软重启升级过程结束。

5.一种不中断业务升级ISSU的软重启升级设备，作为对端设备应用于包括相互直连的本端设备和所述对端设备的网络中，其特征在于，所述对端设备包括：

接收模块，用于在所述本端设备进行ISSU的软重启升级之前，接收来自所述本端设备的用于表示需要进行软重启升级的代理发包请求报文，且所述代理发包请求报文中携带了需要代理发包的协议类型；

记录模块，用于当所述协议类型为不需要转发协议保活报文的协议类型时，在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；

当所述协议类型为需要转发协议保活报文的协议类型时，在端口索引表中记录收到所述代理发包请求报文的物理接口的标识；并在指定时间内收到所述协议类型对应的协议保活报文时，在代理发包内容表中记录收到所述协议保活报文的物理接口的标识和所述协议保活报文；

维护模块，用于在所述本端设备进行ISSU的软重启升级过程中，在检测到有物理接口的保活定时器超时时，如果为不需要转发协议保活报文的协议类型的保活定时器，则通过所述物理接口查询端口索引表，如果有对应记录，则不进行协议老化处理；如果为需要转发协议保活报文的协议类型的保活定时器，则通过所述物理接口查询代理发包内容表，如果有对应记录，则不进行协议老化处理，并转发查询到的协议保活报文；

设置模块，用于根据所述协议类型对应的协议保活报文接收时间设置所述指定时间，且所述指定时间大于所述协议保活报文接收时间。

6.如权利要求5所述的设备，其特征在于，还包括：

发送模块，用于当所述指定时间到期之后，向所述本端设备发送用于表示能够进行软重启升级的代理发包确认报文；由所述本端设备在收到所述代理发包确认报文之后，启动ISSU的软重启升级过程。

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

所述接收模块，还用于在所述本端设备进行ISSU的软重启升级完成之后，接收来自所述本端设备的用于表示已经完成软重启升级的代理发包结束报文，并通过所述代理发包结束报文确认ISSU的软重启升级过程结束。

8.一种不中断业务升级ISSU的软重启升级设备，作为本端设备应用于包括相互直连的所述本端设备和对端设备的网络中，其特征在于，所述本端设备包括：

第一发送模块，用于在本设备进行ISSU的软重启升级之前，获得需要代理发包的物理接口，并通过获得的物理接口向所述对端设备发送用于表示需要进行软重启升级的代理发包请求报文，且所述代理发包请求报文中携带了需要代理发包的协议类型；

接收模块，用于接收来自所述对端设备的用于表示能够进行软重启升级的代理发包确认报文；

启动模块，用于在收到所述代理发包确认报文之后，启动ISSU的软重启升级过程；

第二发送模块，用于在本设备进行ISSU的软重启升级完成之后，向所述对端设备发送用于表示已经完成软重启升级的代理发包结束报文。