SDN網絡中的故障檢測與修復技術研究

摘 要：【目的】雖然軟件定義網絡（SDN）是一種開放的架構，但也存在著各類網絡錯誤。為實現SDN的高可用性，對故障檢測與修復機制進行研究是至關重要的。【方法】首先，對SDN架構與OpenFlow協議進行分析，總結出SDN網絡中可能出現的錯誤，并設計出數據平面錯誤檢測方法。其次，基于主動修復與被動修復機制，并考慮數據流量服務的質量（QoS）需求，從而提出主動與被動相結合的故障修復機制。在此基礎上，本研究設計出基于開源代碼的故障檢測與修復方法，其使用的是非同步報警機制監測網絡，根據故障數量和影響程度選擇3種修復模式。【結果】試驗結果表明，本研究設計的方法能有效檢測出SDN數據平面中常見的錯誤，在保障QoS的前提下，能最大限度恢復網絡功能。【結論】該方法在處理多類故障和考慮QoS需求方面超過現有機制，為SDN高可用性和應用提供理論與實踐基礎，而進一步提高對復雜故障的處理能力和增強自修復智能性是后續的研究方向。

關鍵詞：SDN聯網；故障檢測；故障修復

中圖分類號：TP393.06" " 文獻標志碼：A" " 文章編號：1003-5168（2024）02-0021-06

DOI：10.19968/j.cnki.hnkj.1003-5168.2024.02.004

Research on Fault Detection and Recovery Techniques in SDN Networks

XU Haohao

（China Mobile Communications Group Henan Co.， Ltd.， Zhengzhou 450008， China）

Abstract： [Purposes] Although Software Defined Networking （SDN） is an open architecture， there are also various network errors. In order to realize the high availability of SDN， it is very important to study the fault detection and repair mechanism. [Methods] Firstly， the SDN architecture and OpenFlow protocol are analyzed， and the possible errors in the SDN network are summarized， and the data plane error detection method is designed. Secondly， based on the active repair and passive repair mechanism， and considering the quality of service（QoS） requirements of data traffic， a fault repair mechanism combining active and passive repair is proposed. On this basis， this study designs a fault detection and repair method based on open source code， which uses an asynchronous alarm mechanism monitoring network， and selects three repair modes according to the number of faults and the degree of influence. [Findings] The experimental results show that the method designed in this study can effectively detect common errors in the SDN

data plane， and can maximize the recovery of network functions under the premise of guaranteeing QoS. [Conclusions] This method is superior to the existing mechanisms in dealing with multiple types of faults and considering QoS requirements， which provides a theoretical and practical basis for SDN high availability and application. Further improving the ability to deal with complex faults and enhancing self-healing intelligence are the follow-up research directions.

Keywords： SDN networking; fault detection; fault recovery

0 引言

隨著互聯網和通信技術的發展，互聯網規模和服務種類也日益豐富，尤其是移動互聯網、物聯網、云計算等領域發展迅猛，從而使互聯網服務需求更加多樣化。在傳統的分布式網絡中，節點必須同時具備控制邏輯、數據傳輸等功能，且節點還需要同時接收數千種不同的分布協議，只有這樣，才能讓整個網絡更加智能化，但這會導致原本十分簡單的網絡設備變得越來越復雜。由于不同設備是由不同廠商自行設計生產的，都有專屬的接口，從而導致對網絡的管理比較麻煩，很可能會產生一些差錯，且無法根據網絡的持續改變及時進行調整，導致新的控制技術無法直接應用到現有網絡中，其靈活性和可擴充性無法適應飛速發展的網絡。

1 相關技術分析

1.1 SDN體系結構

軟件定義網絡（Software Defined Network，SDN）能解決網絡控制與轉發之間的矛盾，并在邏輯上對其進行集中式編程，使其能對上層應用和業務進行抽象化操作。開放網絡基金（ONF）是由谷歌、雅虎、Facebook等企業于2011年聯合發起的一個非營利組織，主要負責SDN的開發與標準化工作，是當前研發SDN標準中最活躍、最大的一個組織。由ONF機構定義的SDN體系架構如圖1所示。由圖1可知，SDN網絡架構可分成3個層次：①數據層。數據層是由幾個沒有控制功能的網絡裝置組成的，用來處理數據、轉發和收集局部狀態信息；②控制層。在邏輯上，控制層是一個被中心化的控制器，可用來對數據層中的網絡設備進行控制和管理，并對網絡中的拓撲結構和狀態信息進行維護；③應用層。在SDN網絡中，最上面的是由多個SDN網絡業務應用組成的應用層。在SDN網絡架構中，控制數據層、應用程序控制層之間的界面也是重要的組成部分，能實現對整個網絡設備轉發行為的控制，并對設備的性能進行查詢、對整個網絡架構狀態進行統計和匯報、對設備目前狀態進行統計和對事件進行匯報。應用程序控制層界面為用戶提供了一個抽象的網絡視圖，讓用戶對網絡行為進行直接控制，從多個層次對網絡及功能進行抽象化操作。

根據ONF對SDN的定義，在SDN體系結構中，集中式控制和分布式數據平面是互相獨立的。在此基礎上，提出了一種基于數據層的網絡拓撲結構設計方法。在應用層中，利用控制器的開放性可編程接口對網絡中的數據包進行控制與管理。此外，ONF還提供了控制數據層接口的公開OpenFlow標準，要求下層所有設備使用統一的接口，從而使下層的控制層與應用層不用再依靠下層廠商提供的交換機設備。

1.2 OpenFlow技術

在OpenFlow交換機中，僅有一張組表，不依賴多層次的流表，此外，還包含多個數據組的條目。組表項包括組ID（Group ID）、組類型、計數器、行動桶。一個組ID可唯一識別一個表格項目，計數器是對這個表格項目進行計數。組類型在行動桶中定義了執行指令的方式，包含以下4種類型。①所有（All）。在全部行動桶中執行全部行動，適合在廣播或組播時使用。數據包會被大量拷貝，這些拷貝會被單獨的行動桶所處理。②選擇（Select）。在一個特定的行動桶中執行一個行動，由交換機使用特定的算法選擇出一個行動桶來處理數據包。③間接（Indirect）。在指定表格條目中執行特定的操作，該表格條目中僅存在一個操作。④快速故障恢復（Fast Failover）。在第一個有效操作桶中執行一個操作。在組表項目中，Fast Failove至少包含兩個動作，每個動作都要包含一個活動狀態監測（Liveness Monitoring）項目。當一個行動桶中的活躍狀態項目在某一范圍內時（觀察端口和觀察組均不等于OxffffffffL），這個行動桶是有效的。這些行動桶是有順序的，第一個在活躍狀態的行動桶中的動作會被執行，若第一個行動桶出現故障（Oxffffffff），下一個處于活躍狀態的行動桶生效，以此類推。如果行動桶的監控狀態不起作用，這個數據包就會被拋棄。本研究通過對FastFailover進行分析，提出了一種基于FastFailover的交換算法［1］。

2 SDN網絡故障檢測與恢復技術設計

2.1 SDN網絡故障

SDN是一個由數據和控制組成的獨立網絡，傳輸信道被分為兩部分，即控制信道和數據信道。Tnband控制表示控制信道與數據信道共用同一鏈路，Outbound控制表示控制信道與數據信道采用獨立鏈路，且控制信道由一條特殊鏈路構成。目前，大多數對SDN的研究與應用都基于對SDN的外部控制展開，本研究也是基于此展開的。其中，控制信道是一種在控制器與交換機之間進行信息交換、裝置狀態報告、流表格入口傳輸等的專用通信鏈路。在上述情況中，數據通道作為交換機和主機之間傳輸數據的通信鏈路。當只有一個控制器的控制層發生故障時，極易導致系統癱瘓，而應用多個控制器形成的簇將會提高控制層的可靠性，SDN控制層中有多個控制器。綜上所述，SDN中有3個主要失敗區域，即數據級故障（switch或link故障）、控制信道故障（控制器和交換機之間的連接故障）、控制層故障（控制層故障或控制層之間的連接故障）。

控制層面和控制通道故障可通過冗余備份機制來解決，使用主從型控制器簇、OpenFlow多控制器連通、控制器角色（Master、Slave與Equal）的柔性過渡等方法，對控制層與控制信道的故障進行研究。控制信道故障可分為兩種，即交換結點故障和連接故障，以下將重點討論這兩類故障。①鏈路故障。交換機之間的鏈路連接被破壞或交換機網絡介面失效（交換網卡介面或網卡自身失效）。盡管這兩個錯誤并不相同，但都會造成兩臺交換器之間的連接中斷。因此，都被認為是連接故障。②交換節點故障。交換節點失效的原因有很多，每一種都會對業務轉發產生不同影響。SDN交換機結構如圖2所示。從圖2可以看出，交換機節點故障可分為3類：①交換機電源供給中斷。如果交換機沒有備用電源，斷電將會使交換機完全停止工作，并使其出現功能故障；②交換機安全信道故障。交換機與控制器相連的安全信道發生故障，交換機與控制器之間的通信被切斷，交換機無法收到控制器發出的轉發決策和管理指令，只能按照原來的流表項進行轉發。③交換機的轉送函數發生錯誤。交換機數據包轉發函數故障是由交換機數據流存儲被破壞或與數據包相匹配的轉送組件被破壞所引起的［2］。

2.2 結構設計

基于SDN的網絡故障檢測與恢復系統總體結構設計如圖3所示，其中，錯誤檢測模塊由開關錯誤和鏈接錯誤組成，用來監聽網絡變化、收集警報信息。在此基礎上，提出了一種新的故障診斷方法。將故障恢復模塊分為3個部分，分別為網絡拓撲構建、路徑計算和轉發規則下發，用來維護網絡拓撲和轉發規則倉庫。這些倉庫會隨著網絡變化而實時更新，同時還可為路由故障修復提供路徑計算和轉發規則下發的功能。

3 結果分析

3.1 故障修復時間

首先，對系統故障的修復速度進行估計，并將該方法與現有的主動性故障修復方法（ARM）和被動性故障修復法 （PRM）進行對比分析，從而驗證了該方法的有效性。其次，將連接帶寬的上限限定為10 Mbps，并利用Iperf對1個10 Mbps的UDP進行分組，以0.4 ms的時間間隔分別從H1到H3、H1到H4、H2到H3進行同步傳輸，連續傳輸30 s，此時BFD探測到的傳輸速度為10 Mbps。該算法在工作通道上進行普通轉送，當某一節點發生錯誤時，能找出數據包丟失情況。在應用本研究所提出的修復機制時，服務端 UDP會分組接收報告。

目前，傳輸5 s時，從H1到H4丟包的個數為92個，從H1到H3、H2到H3丟包的個數均為94個，平均值為37.1 ms，連續進行50次測試，并取平均值。ARM方案大約需要24～35 ms的時間才能復原，而平均復原時間為30.82 ms；VLAN PS方案的修復時間為31～43 ms，平均復原時間為37.43 ms；PRM的波動幅度為117～146 ms，平均復原時間為128.81 ms。由于該系統不用對控制端進行任何操作，且交換機能將發生故障后的數據流直接轉換到備份通道中，因此，該系統的恢復時間較短。此外，由于本研究設計的方案在交換機輸出端口采用了基于優先級的排隊管理調度策略來保證服務質量，因此，該方案的恢復時間要高于ARM所需要的恢復時間，但仍在可接受的范圍內，即低于電信級別（50 ms）的要求［3］。

3.2 備份資源消耗

在對網絡失效進行修復時，需要的傳輸規則包括工作通路上的流表項、組表項和備用通路上的流表項。在Mininet中輸入CLI指令“pingall”后，每個主機都會發出一個“ping”的要求，然后生成一個不同來源或目標地址的數據， Ryu控制程序會對工作路線和備用路線進行處理，并將該操作指令發給相應開關。為驗證該方案在存儲容量上的正確性，通過VLAN PS與ARM這兩種方案對數據備份的占用進行對比。當一個“pingall”指令被執行一次后，兩個交換機就會生成6個具有不同來源和目標地址的數據流，最終會在網絡拓撲中生成一個完整的連接。所以，試驗過程中會逐步加大互相ping的對數，并對比兩種方式所需傳輸項目的個數。在更小的組合對數下，這兩種方式的轉發費用幾乎相同。然而，隨著網絡中不同主機之間的數據流增多，當互ping主機的組合對數為3時，二者產生差異，ARM的轉發項數量逐漸大于VLAN PS，ARM消耗的轉發表項為64條，VLAN PS消耗的轉發表項為54條。這是因為VLAN PS只與鏈路相關，所以當一個數據流經過同一條鏈路時，備用通道中的所有開關都會按照一定規律來完成相應操作，而ARM則是按照一定規律來完成相應操作，當源地址和目的地址發生變化時，會發出相應的轉發請求。

3.3 主動修復模式

3.3.1 即時主動修復模式。主機h1（IP地址為10.0.0.1）在 Iperf Client狀態下工作，主機h3 （IP地址為10.0.0.3）在 Iperf Service狀態下工作， hl利用iperf-c10.0.0.3-a-t30-150-b800k，每隔0.5 ms將正常的UDP數據包發送給h3，h3利用iperf-s-a-i5來接收h1發送的數據包，并生成數據包傳輸性能報告。在Mininet指令列下，通過將指令鏈接s1s2down仿真鏈路〈sl〉斷裂開來，用來仿真主要通路上的鏈路故障情況。在linux命令行下，輸入命令sudoovs-vsctldel-brs2來模擬交換機s2出現故障，本研究著重分析故障檢測和恢復系統在處理鏈路故障時的函數和性能結果。網絡處于正常狀態時，UDP的數據分組通過“sl”的主路徑傳輸到目標主機h3，當鏈路“sl”出現問題時，通過Wireshark的抓包工具，可以發現UDP的數據分組通過備用路徑從開關s1的s1-eth4端口通過備用路徑。在〈s〉傳輸至h3時，h3的數據包收到報告，在0.0～5.0 s內，數據包收到正常，在5.0～10.0 s時，數據包丟失，在10.0 s時，數據包收到回復。試驗結果表明，該方法可在主要通道中偵測到單一故障狀態，并在沒有QoS保障的前提下，使用一種積極的方式來修復數據包。根據主機h3的Iperf服務端分組接收到的報告，當系統的主動式恢復模式進行單故障處理時，丟失12個分組，則故障恢復時間為12×0.5 ms=6 ms。在此基礎上，通過20次試驗來檢驗該系統的穩定性，并對該系統的各項性能指標進行統計分析。

3.3.2 審議主動修復模式。首先，主機h1以0.5 ms的時間間隔將所要傳輸的UDP文件流（iperf-c10.0.0.3-a-150-b800k-Ftestvideo.m4e）傳送到主機h3中。其次，在Mininet指令列下輸入指令鏈接s1s2下仿真鏈路〈sl〉斷裂，可模擬出主要通路上的鏈路故障情況。當主要通路上〈sl〉鏈路被切斷后，由Wireshark抓包結果可知，UDP視頻分組先經過備份通路〈s〉，再經過s1的s1-eth4端口被發送到h3。最后，通過Wireshark抓包發現，文件通過〈s〉路徑流動到在交換機s5的s5-eth3端口上抓包的h3。h3的數據包接收報告，數據包丟失發生在20.0-25.0，此后數據包傳輸正常。試驗結果證明，該系統在發現單一故障時，能對數據流的流量特征進行辨識，并使用模型對故障數據流進行優化求解。由數據包接收報告可知，在以0.5 ms間隔發送的文件流故障期間，共丟失了20個數據包，即主動修復模式的修復時間為20×0.5 ms=10 ms。此外，針對該類故障提出解決方案，并通過20個試驗來檢驗其穩定性，對其各項性能指標進行統計［4］。

3.4 被動修復模式

主機h1每隔0.5 ms運行一次iperf-c10.0.0.3-a-t30-150-b800k，將正常的UDP數據包傳送到主機h3。在Mininet指令行下，運行“鏈接s1S2下降”“鏈接s1S5下降”指令，分別仿真鏈接〈sl，s2〉和〈s1，s5〉的斷開，從而使h1到h3的主要通路和備用通路同時故障。當網絡運作良好時，封包會經由〈sl，s2，s3〉private通路抵達傳送目標。在發生2次鏈接錯誤后，利用Wireshark進行捕捉，可知UDP數據包在s1的sl-eth3端口上經過新的路徑〈s〉向h3傳送。對目標主機的封包收到情況進行檢查，發現在0.0～5.0 s時間內，資料傳輸情況良好，無封包丟包現象；在5.0～20.0 s的時間內，出現數據包遺失現象，表示有一個錯誤；在20.0 s后，數據包的傳輸重新回到原來狀態，這意味著系統發現一個錯誤，且路由重新獲得成功。試驗結果證明，該方法能有效辨識出多重故障情況，并利用一種無源的復原方式對受損流量進行再一次有效的復原。由h3的Iperf服務器端統計信息可知，在故障過程中，以0.5 ms間隔發送的數據包共丟失了330個，即該系統被動修復模式的修復時間為330×0.5 ms=165 ms。對這兩種類型的失效情況進行了20次試驗，并進行相應的性能評估。

3.5 測試結果分析

對上述試驗結果進行分析，從而證明了該系統能有效解決數據級故障問題。通過對3種不同的故障情況進行仿真試驗，結果表明，該系統能正確偵測出故障情況，并對故障情況做出判斷，可使用最優的復原方式來復原路徑。通過對各種故障情況進行仿真分析，表明該故障檢測與修復方法的性能良好，具有較強的魯棒性，能長期穩定工作。在效能上，以上述3個故障場景為例，進行20個模擬故障試驗，并以目標主機所接收到的數據包丟失為統計依據，計算出故障修復所需的時間，備用路徑的主動型故障恢復時間約為6.75 ms，在電信網絡中能達到50 ms的標準，這是因為主動型故障恢復無需與控制器進行交互，且交換機可直接切換到備份路徑。針對單一故障情況，可使用主動恢復方式，當主回路發生故障時，將切換到備用回路，并由故障檢測與修復系統重新分配最佳回路。在切換到備份路徑過程中，與主動式相比，花費時間一樣。但在向交換機發送新路徑過程中，會導致一些數據包丟失。在失敗過程中，平均恢復時間大約為13.8 ms，比正常的主動修復要稍微長一些，但也符合運營商的需求。此外，在失敗過程中，還可使用語音、視頻等，為用戶提供高質量服務。在多個故障情況下，使用控制器的故障被動修復時間為170.5 ms左右，這是因為要把網絡故障信息傳輸到控制器上，系統對故障種類進行判定，然后重新計算出一條路徑，再將流表項下發給交換機，所以，故障修復時間相對較長，不能達到運營商的要求。因此，為了減少故障修復時間，應對被動修復模式進行深入研究［5］。

4 結語

SDN具有控制層和數據層分離的特點，對SDN中交換節點和數據層的故障檢測與修復技術進行了大量研究，但對控制層中控制器單點失效問題的研究并不多。SDN控制器是整個網絡的核心，其失效會導致整個網絡癱瘓。本研究利用集群技術對軟件定義網中的控制節點進行主從式熱備份，主從式控制節點發生故障后，可快速切換到備用控制節點。在此基礎上，進一步研究SDN中控制器的故障檢測與修復方法，提高SDN在控制層中的可靠性。

參考文獻：

［1］潘海霞，曹寧.基于SDN的數據中心端口故障檢測方法設計［J］.自動化與儀器儀表，2023（2）：56-60.

［2］李松州，潘正高，辛政華，等.基于消息通知的SDN控制器故障處理機制［J］.蘭州文理學院學報（自然科學版），2022（4）：66-70.

［3］崔麗麗，曾學文，朱小勇.基于鏈路權重的SDN組播鏈路恢復機制［J］.電子設計工程，2022（6）：141-146.

［4］陳泳潔，王勇，葉苗.一種多控制器SDN網絡中控制器故障處理策略［J］.桂林電子科技大學學報，2021（6）：484-488.

［5］基于模擬退火的分層軟件定義網絡控制器高效故障轉移機制［J］.無線電通信技術，2020（3）：314.