專利名稱：一種issu的軟重啟升級方法和設備的制作方法
技術(shù)領域：
本發(fā)明涉及通信技術(shù)領域，特別是涉及一種ISSU (In-Service Software Upgrade,不中斷業(yè)務升級)的軟重啟升級方法和設備。
背景技術(shù)：
ISSU是可靠性高的升級設備啟動軟件方式，其包括增量升級、軟重啟升級和重啟升級，這三種方式都能夠?qū)崿F(xiàn)升級過程中業(yè)務不中斷。其中，接口板需要進行軟重啟升級， 主控板需要進行增量升級或重啟升級；在接口板軟重啟升級開始前，主控板需要先升級完畢，并將持續(xù)處于正常穩(wěn)定工作狀態(tài)。
在接口板開始進行軟重啟升級時，需要將運行瞬間的數(shù)據(jù)(如運行數(shù)據(jù)、配置數(shù)據(jù)、硬件數(shù)據(jù)等)和狀態(tài)保存在內(nèi)存中；在軟重啟升級過程中，接口板CPU (Central Processing Unit,中央處理單元)會重啟，且運行在接口板上的業(yè)務進程會全部退出，但是接口板的硬件并沒有被重啟，其將繼續(xù)提供正常的報文轉(zhuǎn)發(fā)能力；在軟重啟升級完畢之后， 需要恢復上次保存的數(shù)據(jù)和狀態(tài)，且接口板將使用升級后新版本繼續(xù)正常運行。
對于接口板上運行的協(xié)議來說，有些協(xié)議全部由主控板CPU發(fā)送，如路由協(xié)議； 有些協(xié)議部分由主控板CPU發(fā)送，部分由接口板CPU發(fā)送，如MSTP (Multiple Spanning Tree Protocol，多生成樹協(xié)議)，其物理口協(xié)議報文由接口板CPU發(fā)送，聚合口協(xié)議報文由主控板CPU發(fā)送；有些協(xié)議全部由接口板CPU發(fā)送,如LACP (Link Aggregation Control Protocol,鏈路聚合控制協(xié)議)。
在軟重啟升級過程中，由于接口板CPU會被重啟，使得由接口板CPU發(fā)送的協(xié)議報文無法發(fā)送；基于此，需要由主控板CPU代理發(fā)送接口板CPU發(fā)送的協(xié)議報文。如圖I所示， 為現(xiàn)有技術(shù)中的網(wǎng)絡示意圖，設備SwitChl (交換機I)處于網(wǎng)絡的核心層，下面連接匯聚層設備 RB6 (Routing Bridge，路由橋)、RB7、RB8 和 RB9 ;假設 Switchl 上開啟 MSTP 和 LACP 等協(xié)議，在Switchl的軟重啟升級過程中，由于接口板CPU重啟，主控板CPU運行正常，原本由接口板CPU發(fā)送的協(xié)議報文，可通過Swichl設備的主控板代理發(fā)送。
但是，當進行軟重啟升級的設備是匯聚層或核心層設備時，匯聚層或核心層設備通常連接大量其它設備，且運行很多復雜業(yè)務，主控板CPU本身業(yè)務比較繁忙，如果由主控板CPU代理發(fā)送接口板CPU發(fā)送的協(xié)議報文，則會加重主控板CPU的負擔；且主控板CPU可能無法及時代理發(fā)送接口板CPU發(fā)送的協(xié)議報文，進一步導致對端設備協(xié)議老化超時，網(wǎng)絡拓撲發(fā)生震蕩。發(fā)明內(nèi)容
本發(fā)明提供一種ISSU的軟重啟升級方法和設備，以降低主控板CPU的負擔，并且可以防止網(wǎng)絡拓撲發(fā)生震蕩。
為達到上述目的，本發(fā)明實施例提供一種不中斷業(yè)務升級ISSU的軟重啟升級方法，應用于包括相互直連的本端設備和對端設備的網(wǎng)絡中，該方法包括以下步驟在所述本端設備進行ISSU的軟重啟升級之前，所述對端設備接收來自所述本端設備的用于表示需要進行軟重啟升級的代理發(fā)包請求報文，且所述代理發(fā)包請求報文中攜帶了需要代理發(fā)包的協(xié)議類型；當所述協(xié)議類型為不需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型時，所述對端設備在端口索引表中記錄收到所述代理發(fā)包請求報文的物理接口的標識；當所述協(xié)議類型為需要轉(zhuǎn)發(fā)協(xié)議保活報文的協(xié)議類型時，所述對端設備在端口索引表中記錄收到所述代理發(fā)包請求報文的物理接口的標識；并在指定時間內(nèi)收到所述協(xié)議類型對應的協(xié)議?；顖笪臅r，在代理發(fā)包內(nèi)容表中記錄收到所述協(xié)議?；顖笪牡奈锢斫涌诘臉俗R和所述協(xié)議保活報文；在所述本端設備進行ISSU的軟重啟升級過程中，所述對端設備在檢測到有物理接口的保活定時器超時時，如果為不需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型的保活定時器，則通過所述物理接口查詢端口索引表，如果有對應記錄，則不進行協(xié)議老化處理；如果為需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型的?；疃〞r器，則通過所述物理接口查詢代理發(fā)包內(nèi)容表，如果有對應記錄，則不進行協(xié)議老化處理，并轉(zhuǎn)發(fā)查詢到的協(xié)議保活報文。
所述對端設備接收來自所述本端設備的用于表示需要進行軟重啟升級的代理發(fā)包請求報文之前，還包括所述本端設備在進行ISSU的軟重啟升級前，獲得需要代理發(fā)包的物理接口，并通過獲得的物理接口向所述對端設備發(fā)送所述代理發(fā)包請求報文。
所述方法進一步包括當所述指定時間到期之后，所述對端設備向所述本端設備發(fā)送用于表示能夠進行軟重啟升級的代理發(fā)包確認報文；由所述本端設備在收到所述代理發(fā)包確認報文之后，啟動ISSU的軟重啟升級過程。
所述指定時間的設置方式，具體包括所述對端設備根據(jù)所述協(xié)議類型對應的協(xié)議保活報文接收時間設置所述指定時間，且所述指定時間大于所述協(xié)議?；顖笪慕邮諘r間。
所述方法進一步包括在所述本端設備進行ISSU的軟重啟升級完成之后，所述對端設備接收來自所述本端設備的用于表示已經(jīng)完成軟重啟升級的代理發(fā)包結(jié)束報文，并通過所述代理發(fā)包結(jié)束報文確認ISSU的軟重啟升級過程結(jié)束。
本發(fā)明實施例提供一種不中斷業(yè)務升級ISSU的軟重啟升級設備，作為對端設備應用于包括相互直連的本端設備和所述對端設備的網(wǎng)絡中，所述對端設備包括接收模塊，用于在所述本端設備進行ISSU的軟重啟升級之前，接收來自所述本端設備的用于表示需要進行軟重啟升級的代理發(fā)包請求報文，且所述代理發(fā)包請求報文中攜帶了需要代理發(fā)包的協(xié)議類型；記錄模塊，用于當所述協(xié)議類型為不需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型時，在端口索引表中記錄收到所述代理發(fā)包請求報文的物理接口的標識；當所述協(xié)議類型為需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型時，在端口索引表中記錄收到所述代理發(fā)包請求報文的物理接口的標識；并在指定時間內(nèi)收到所述協(xié)議類型對應的協(xié)議?；顖笪臅r，在代理發(fā)包內(nèi)容表中記錄收到所述協(xié)議?；顖笪牡奈锢斫涌诘臉俗R和所述協(xié)議?；顖笪?；維護模塊，用于在所述本端設備進行ISSU的軟重啟升級過程中，在檢測到有物理接口的?；疃〞r器超時時，如果為不需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型的?；疃〞r器，則通5所述物理接口查詢端口索引表，如果有對應記錄，則不進行協(xié)議老化處理；如果為需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型的保活定時器，則通過所述物理接口查詢代理發(fā)包內(nèi)容表，如果有對應記錄，則不進行協(xié)議老化處理，并轉(zhuǎn)發(fā)查詢到的協(xié)議?；顖笪?。還包括發(fā)送模塊，用于當所述指定時間到期之后，向所述本端設備發(fā)送用于表示能夠進行軟重啟升級的代理發(fā)包確認報文；由所述本端設備在收到所述代理發(fā)包確認報文之后，啟動ISSU的軟重啟升級過程。還包括設置模塊，用于根據(jù)所述協(xié)議類型對應的協(xié)議?；顖笪慕邮諘r間設置所述指定時間，且所述指定時間大于所述協(xié)議?；顖笪慕邮諘r間。所述接收模塊，還用于在所述本端設備進行ISSU的軟重啟升級完成之后，接收來自所述本端設備的用于表示已經(jīng)完成軟重啟升級的代理發(fā)包結(jié)束報文，并通過所述代理發(fā)包結(jié)束報文確認ISSU的軟重啟升級過程結(jié)束。本發(fā)明實施例提供一種不中斷業(yè)務升級ISSU的軟重啟升級設備，作為本端設備應用于包括相互直連的所述本端設備和對端設備的網(wǎng)絡中，所述本端設備包括
第一發(fā)送模塊，用于在本設備進行ISSU的軟重啟升級之前，獲得需要代理發(fā)包的物理接口，并通過獲得的物理接口向所述對端設備發(fā)送用于表示需要進行軟重啟升級的代理發(fā)包請求報文，且所述代理發(fā)包請求報文中攜帶了需要代理發(fā)包的協(xié)議類型；
接收模塊，用于接收來自所述對端設備的用于表示能夠進行軟重啟升級的代理發(fā)包確認報文；
啟動模塊，用于在收到所述代理發(fā)包確認報文之后，啟動ISSU的軟重啟升級過程；第二發(fā)送模塊，用于在本設備進行ISSU的軟重啟升級完成之后，向所述對端設備發(fā)送用于表示已經(jīng)完成軟重啟升級的代理發(fā)包結(jié)束報文。與現(xiàn)有技術(shù)相比，本發(fā)明實施例至少具有以下優(yōu)點本發(fā)明實施例中，在設備進行ISSU的軟重啟升級過程中，不再通過主控板CPU代理發(fā)包，從而降低主控板CPU的負擔，并提高設備和網(wǎng)絡運行的可靠性和穩(wěn)定性；而且可以防止軟重啟升級過程中的?；疃〞r器超時，防止網(wǎng)絡拓撲發(fā)生震蕩。


圖I是現(xiàn)有技術(shù)中的網(wǎng)絡示意 圖2是本發(fā)明實施例提供的一種ISSU的軟重啟升級方法流程 圖3是本發(fā)明實施例提出的應用場景示意 圖4是本發(fā)明實施例提出的一種對端設備的結(jié)構(gòu)示意 圖5是本發(fā)明實施例提出的一種本端設備的結(jié)構(gòu)示意圖。
具體實施例方式下面結(jié)合附圖對本發(fā)明實施例進行詳細描述。本發(fā)明實施例提出一種ISSU的軟重啟升級方法，該方法應用于包括相互直連的本端設備和對端設備的網(wǎng)絡中，本實施例中以本端設備需要進行ISSU的軟重啟升級為例進行說明，如圖2所示，該方法包括以下步驟
步驟201，本端設備在進行ISSU的軟重啟升級之前，獲得需要代理發(fā)包的物理接口，并通過獲得的物理接口向?qū)Χ嗽O備發(fā)送代理發(fā)包請求報文。本發(fā)明實施例中，該代理發(fā)包請求報文用于表示需要進行軟重啟升級，且該代理發(fā)包請求報文中攜帶了需要代理發(fā)包的協(xié)議類型。以圖3為本發(fā)明實施例的應用場景示意圖，進行ISSU的軟重啟升級的設備為設備A,假設設備A、設備B和設備C上開啟聚合功能,運行LACP協(xié)議；設備A、設備B、設備C、設備D和設備E上開啟MSTP功能，運行MSTP協(xié)議。在圖3中，設備A通過物理接口 A_1連接設備B的物理接口 B_1 ;設備A通過聚合口 Aggl連接設備B的聚合口 Aggl，設備A上Aggl包含物理接口 A_2和物理接口 A_3，設備B上Aggl包含物理接口 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的軟重啟升級之前，需要遍歷搜集需要代理發(fā)包的物理接口，且需要代理發(fā)包的物理接口包括物理接口 A_l、物理接口A_2、物理接口 A_3、物理接口 A_4、物理接口 A_5和物理接口 A_6 ;進一步的，物理接口 A_1和物理接口 A_4對應的需要代理發(fā)包的協(xié)議類型為MSTP ;物理接口 A_2、物理接口 A_3、物理接口 A_5和物理接口 A_6對應的需要代理發(fā)包的協(xié)議類型為LACP。因此，設備A通過物理接口 A_1發(fā)送攜帶需要代理發(fā)包的協(xié)議類型為MSTP的代理發(fā)包請求報文，通過物理接口 A_2發(fā)送攜帶需要代理發(fā)包的協(xié)議類型為LACP的代理發(fā)包請求報文，通過物理接口 A_3發(fā)送攜帶需要代理發(fā)包的協(xié)議類型為LACP的代理發(fā)包請求報文，通過物理接口 A_4發(fā)送攜帶需要代理發(fā)包的協(xié)議類型為MSTP的代理發(fā)包請求報文，通過物理接口 A_5發(fā)送攜帶需要代理發(fā)包的協(xié)議類型為LACP的代理發(fā)包請求報文，通過物理接口 A_6發(fā)送攜帶需要代理發(fā)包的協(xié)議類型為LACP的代理發(fā)包請求報文。步驟202，在本端設備進行ISSU的軟重啟升級之前，對端設備接收來自本端設備的代理發(fā)包請求報文，并確認本端設備需要進行軟重啟升級。在圖3所示的應用場景下，以設備B為對端設備的處理為例進行說明，設備C的處理與設備B類似，后續(xù)不再贅述。其中，設備B可以通過物理接口 B_1收到來自物理接口A_1的攜帶需要代理發(fā)包的協(xié)議類型為MSTP的代理發(fā)包請求報文，通過物理接口 B_2收到來自物理接口 A_2的攜帶需要代理發(fā)包的協(xié)議類型為LACP的代理發(fā)包請求報文，通過物理接口 B_3收到來自物理接口 A_3的攜帶需要代理發(fā)包的協(xié)議類型為LACP的代理發(fā)包請求報文。步驟203，對端設備在端口索引表中記錄收到代理發(fā)包請求報文的物理接口的標識；如表I所示，為記錄物理接口的標識的端口索引表。表I
權(quán)利要求
1.一種不中斷業(yè)務升級ISSU的軟重啟升級方法，應用于包括相互直連的本端設備和對端設備的網(wǎng)絡中，其特征在于，該方法包括以下步驟 在所述本端設備進行ISSU的軟重啟升級之前，所述對端設備接收來自所述本端設備的用于表示需要進行軟重啟升級的代理發(fā)包請求報文，且所述代理發(fā)包請求報文中攜帶了需要代理發(fā)包的協(xié)議類型； 當所述協(xié)議類型為不需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型時，所述對端設備在端口索引表中記錄收到所述代理發(fā)包請求報文的物理接口的標識； 當所述協(xié)議類型為需要轉(zhuǎn)發(fā)協(xié)議保活報文的協(xié)議類型時，所述對端設備在端口索引表中記錄收到所述代理發(fā)包請求報文的物理接口的標識；并在指定時間內(nèi)收到所述協(xié)議類型對應的協(xié)議?；顖笪臅r，在代理發(fā)包內(nèi)容表中記錄收到所述協(xié)議保活報文的物理接口的標識和所述協(xié)議?；顖笪模? 在所述本端設備進行ISSU的軟重啟升級過程中，所述對端設備在檢測到有物理接口的保活定時器超時時，如果為不需要轉(zhuǎn)發(fā)協(xié)議保活報文的協(xié)議類型的?；疃〞r器，則通過所述物理接口查詢端口索引表，如果有對應記錄，則不進行協(xié)議老化處理；如果為需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型的保活定時器，則通過所述物理接口查詢代理發(fā)包內(nèi)容表，如果有對應記錄，則不進行協(xié)議老化處理，并轉(zhuǎn)發(fā)查詢到的協(xié)議?；顖笪摹?br> 2.如權(quán)利要求I所述的方法，其特征在于，所述對端設備接收來自所述本端設備的用于表示需要進行軟重啟升級的代理發(fā)包請求報文之前，還包括 所述本端設備在進行ISSU的軟重啟升級之前，獲得需要代理發(fā)包的物理接口，并通過獲得的物理接口向所述對端設備發(fā)送所述代理發(fā)包請求報文。
3.如權(quán)利要求I所述的方法，其特征在于，所述方法進一步包括 當所述指定時間到期之后，所述對端設備向所述本端設備發(fā)送用于表示能夠進行軟重啟升級的代理發(fā)包確認報文；由所述本端設備在收到所述代理發(fā)包確認報文之后，啟動ISSU的軟重啟升級過程。
4.如權(quán)利要求I至3任一權(quán)利要求所述的方法，其特征在于，所述指定時間的設置方式，具體包括 所述對端設備根據(jù)所述協(xié)議類型對應的協(xié)議?；顖笪慕邮諘r間設置所述指定時間，且所述指定時間大于所述協(xié)議?；顖笪慕邮諘r間。
5.如權(quán)利要求I所述的方法，其特征在于，所述方法進一步包括 在所述本端設備進行ISSU的軟重啟升級完成之后，所述對端設備接收來自所述本端設備的用于表示已經(jīng)完成軟重啟升級的代理發(fā)包結(jié)束報文，并通過所述代理發(fā)包結(jié)束報文確認ISSU的軟重啟升級過程結(jié)束。
6.一種不中斷業(yè)務升級ISSU的軟重啟升級設備，作為對端設備應用于包括相互直連的本端設備和所述對端設備的網(wǎng)絡中，其特征在于，所述對端設備包括 接收模塊，用于在所述本端設備進行ISSU的軟重啟升級之前，接收來自所述本端設備的用于表示需要進行軟重啟升級的代理發(fā)包請求報文，且所述代理發(fā)包請求報文中攜帶了需要代理發(fā)包的協(xié)議類型； 記錄模塊，用于當所述協(xié)議類型為不需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型時，在端口索引表中記錄收到所述代理發(fā)包請求報文的物理接口的標識；當所述協(xié)議類型為需要轉(zhuǎn)發(fā)協(xié)議保活報文的協(xié)議類型時，在端口索引表中記錄收到所述代理發(fā)包請求報文的物理接口的標識；并在指定時間內(nèi)收到所述協(xié)議類型對應的協(xié)議?；顖笪臅r，在代理發(fā)包內(nèi)容表中記錄收到所述協(xié)議保活報文的物理接口的標識和所述協(xié)議?；顖笪?； 維護模塊，用于在所述本端設備進行ISSU的軟重啟升級過程中，在檢測到有物理接口的?；疃〞r器超時時，如果為不需要轉(zhuǎn)發(fā)協(xié)議?；顖笪牡膮f(xié)議類型的?；疃〞r器，則通過所述物理接口查詢端口索引表，如果有對應記錄，則不進行協(xié)議老化處理；如果為需要轉(zhuǎn)發(fā)協(xié)議保活報文的協(xié)議類型的?；疃〞r器，則通過所述物理接口查詢代理發(fā)包內(nèi)容表，如果有對應記錄，則不進行協(xié)議老化處理，并轉(zhuǎn)發(fā)查詢到的協(xié)議保活報文。
7.如權(quán)利要求6所述的設備，其特征在于，還包括 發(fā)送模塊，用于當所述指定時間到期之后，向所述本端設備發(fā)送用于表示能夠進行軟重啟升級的代理發(fā)包確認報文；由所述本端設備在收到所述代理發(fā)包確認報文之后，啟動ISSU的軟重啟升級過程。
8.如權(quán)利要求6或7所述的設備，其特征在于，還包括 設置模塊，用于根據(jù)所述協(xié)議類型對應的協(xié)議?；顖笪慕邮諘r間設置所述指定時間，且所述指定時間大于所述協(xié)議?；顖笪慕邮諘r間。
9.如權(quán)利要求6所述的設備，其特征在于， 所述接收模塊，還用于在所述本端設備進行ISSU的軟重啟升級完成之后，接收來自所述本端設備的用于表示已經(jīng)完成軟重啟升級的代理發(fā)包結(jié)束報文，并通過所述代理發(fā)包結(jié)束報文確認ISSU的軟重啟升級過程結(jié)束。
10.一種不中斷業(yè)務升級ISSU的軟重啟升級設備，作為本端設備應用于包括相互直連的所述本端設備和對端設備的網(wǎng)絡中，其特征在于，所述本端設備包括 第一發(fā)送模塊，用于在本設備進行ISSU的軟重啟升級之前，獲得需要代理發(fā)包的物理接口，并通過獲得的物理接口向所述對端設備發(fā)送用于表示需要進行軟重啟升級的代理發(fā)包請求報文，且所述代理發(fā)包請求報文中攜帶了需要代理發(fā)包的協(xié)議類型； 接收模塊，用于接收來自所述對端設備的用于表示能夠進行軟重啟升級的代理發(fā)包確認報文； 啟動模塊，用于在收到所述代理發(fā)包確認報文之后，啟動ISSU的軟重啟升級過程； 第二發(fā)送模塊，用于在本設備進行ISSU的軟重啟升級完成之后，向所述對端設備發(fā)送用于表示已經(jīng)完成軟重啟升級的代理發(fā)包結(jié)束報文。
全文摘要
本發(fā)明公開了一種ISSU的軟重啟升級方法和設備，該方法包括在本端設備進行ISSU的軟重啟升級之前，對端設備接收來自本端設備的代理發(fā)包請求報文；所述對端設備在端口索引表中記錄收到所述代理發(fā)包請求報文的物理接口的標識；在所述本端設備進行ISSU的軟重啟升級過程中，所述對端設備在檢測到有物理接口的?；疃〞r器超時時，通過所述物理接口查詢端口索引表，如果有對應記錄，則不進行協(xié)議老化處理；本發(fā)明中，可以降低主控板CPU的負擔，防止網(wǎng)絡拓撲發(fā)生震蕩。
文檔編號H04L12/70GK102984055SQ20121050765
公開日2013年3月20日 申請日期2012年12月3日 優(yōu)先權(quán)日2012年12月3日
發(fā)明者吳文國 申請人:杭州華三通信技術(shù)有限公司