軟件定義網(wǎng)絡(luò)中網(wǎng)絡(luò)診斷的思考和探索

趙宇粟　張鵬飛　金耀輝

摘要：提出一種輕量級(jí)的診斷平面，它利用OpenFlow協(xié)議中多流表的功能，將探針包注入網(wǎng)絡(luò)，探針包經(jīng)過(guò)各個(gè)網(wǎng)絡(luò)設(shè)備后會(huì)攜帶相關(guān)的轉(zhuǎn)發(fā)規(guī)則的信息。通過(guò)收集攜帶這些信息的探針包、利用一組類似于程序調(diào)試的診斷原語(yǔ)，能夠快速地檢測(cè)數(shù)據(jù)平面轉(zhuǎn)發(fā)的正確性和網(wǎng)絡(luò)性能問(wèn)題。認(rèn)為主動(dòng)診斷數(shù)據(jù)平面真實(shí)的轉(zhuǎn)發(fā)行為會(huì)是SDN網(wǎng)絡(luò)診斷的一個(gè)重要方向。

關(guān)鍵詞： 網(wǎng)絡(luò)診斷；軟件定義網(wǎng)絡(luò)；診斷平面

Abstract：We propose a lightweight network debugging plane leveraging multiple flow tables to send probe packets into the network. When traversing network devices， probe packets carry information about forwarding rules. By collecting those probes packets and using debug primitives similar to program debugging， we can determine the correctness and network performance of the data plane forwarding. Debug the forwarding behavior of data plane is an important direction of software-defined network （SDN） network debugging.

Key words：network debugging； SDN； debugging plane

1網(wǎng)絡(luò)故障和網(wǎng)絡(luò)診斷

一般來(lái)說(shuō)，網(wǎng)絡(luò)診斷針對(duì)的網(wǎng)絡(luò)故障，只包括網(wǎng)絡(luò)的連通性問(wèn)題，即端到端是否可達(dá)，但在廣義上還包括了網(wǎng)絡(luò)的性能問(wèn)題，比如網(wǎng)絡(luò)延遲和帶寬。雖然網(wǎng)絡(luò)性能問(wèn)題更多的是用戶之間的競(jìng)爭(zhēng)所造成的，但是錯(cuò)誤的配置以及軟硬件的故障也會(huì)導(dǎo)致網(wǎng)絡(luò)性能的急劇下降，而且事實(shí)上很多用戶會(huì)要求網(wǎng)絡(luò)管理員去解決網(wǎng)絡(luò)的性能問(wèn)題[1]，因此網(wǎng)絡(luò)診斷的對(duì)象不僅是網(wǎng)絡(luò)的連通性問(wèn)題，而且還應(yīng)當(dāng)包括網(wǎng)絡(luò)的一些性能方面問(wèn)題。

一直以來(lái)，網(wǎng)絡(luò)診斷都是非常困難的工作。網(wǎng)絡(luò)管理員每天都要處理各種原因?qū)е碌木W(wǎng)絡(luò)故障，比如錯(cuò)誤的配置、鏈路或者器件的失效以及軟硬件的故障等等。而目前，僅有很少的工具可用于網(wǎng)絡(luò)診斷，包括ping、traceroute和SNMP等，這些工具功能簡(jiǎn)單，能夠解決的問(wèn)題有限，而面對(duì)特別是網(wǎng)絡(luò)性能問(wèn)題的時(shí)候，更是一籌莫展，網(wǎng)絡(luò)管理員依然需要依靠自己豐富的經(jīng)驗(yàn)去排查具體的故障原因。

1.1網(wǎng)絡(luò)故障的普遍性

文獻(xiàn)[1]對(duì)61名網(wǎng)絡(luò)管理員做了一份詳盡的調(diào)查，得到了一些結(jié)論。

（1）超過(guò)50%的人提到，經(jīng)常發(fā)生的網(wǎng)絡(luò)故障包括3類：端到端可達(dá)性的失效、網(wǎng)絡(luò)延遲和吞吐問(wèn)題以及間歇性的連接問(wèn)題。即既存在連通性方面問(wèn)題，也存在著網(wǎng)絡(luò)性能方面問(wèn)題。

（2）超過(guò)40%的人提到，經(jīng)常性的故障原因在于交換機(jī)/路由器的軟件故障和硬件失效。

（3）超過(guò)80%的人經(jīng)常使用ping和traceroute，超過(guò)60%的人經(jīng)常使用SNMP。

（4）35%的網(wǎng)絡(luò)管理員每月收到超過(guò)100起網(wǎng)絡(luò)故障的通告。

（5）解決每一起網(wǎng)絡(luò)故障的平均時(shí)間中，31.6%的人需要半個(gè)小時(shí)至一個(gè)小時(shí)，而24.6%的人需要超過(guò)一個(gè)小時(shí)的時(shí)間。

由此可見(jiàn)，網(wǎng)絡(luò)管理員面對(duì)的網(wǎng)絡(luò)故障種類繁多、原因復(fù)雜，而且遇到的次數(shù)和花費(fèi)的時(shí)間都很巨大，但是可用的工具卻十分有限。因此，網(wǎng)絡(luò)管理員急需更為強(qiáng)大的網(wǎng)絡(luò)診斷工具。

1.2網(wǎng)絡(luò)診斷的困難性

結(jié)合上文的分析，在傳統(tǒng)網(wǎng)絡(luò)中，網(wǎng)絡(luò)診斷比較困難的原因是多方面的：

（1）表征網(wǎng)絡(luò)的各種狀態(tài)參數(shù)分散在各個(gè)網(wǎng)絡(luò)設(shè)備上，在傳統(tǒng)的網(wǎng)絡(luò)中，通常需要管理員親自登陸這樣一些設(shè)備，才能獲得相關(guān)的網(wǎng)絡(luò)狀態(tài)參數(shù)，同時(shí)這些狀態(tài)參數(shù)是會(huì)經(jīng)常變化的，這導(dǎo)致了要想準(zhǔn)確地捕捉網(wǎng)絡(luò)相關(guān)狀態(tài)，就要不停地去監(jiān)測(cè)整個(gè)網(wǎng)絡(luò)的情況。

（2）導(dǎo)致網(wǎng)絡(luò)故障的原因很多，除了人為的配置錯(cuò)誤外，各種網(wǎng)絡(luò)設(shè)備都有可能失效或者發(fā)生軟硬件的故障。

（3）網(wǎng)絡(luò)規(guī)模不斷擴(kuò)大，網(wǎng)絡(luò)拓?fù)涓訌?fù)雜，可能失效的網(wǎng)絡(luò)設(shè)備和鏈路也不斷增多，文獻(xiàn)[2]就提到在其觀測(cè)的數(shù)據(jù)中心內(nèi)部（規(guī)模沒(méi)有具體說(shuō)明，但是可以看到有1.3萬(wàn)條鏈路，因此規(guī)模不算大），每天平均都含有40.8次的鏈路失效以及5.2次的器件失效。

（4）可用工具的缺乏導(dǎo)致網(wǎng)絡(luò)故障不容易定位，并且故障原因不容易查明。

1.3 SDN給網(wǎng)絡(luò)診斷帶來(lái)的機(jī)遇和

挑戰(zhàn)

軟件定義網(wǎng)絡(luò)（SDN）將傳統(tǒng)網(wǎng)絡(luò)中分布式的控制平面剝離了出來(lái)，放到了邏輯上集中式的控制器中，這使得網(wǎng)絡(luò)狀態(tài)可以直接通過(guò)對(duì)話控制器而獲得；而由于其可編程的特性，我們可以輕松地實(shí)現(xiàn)對(duì)所有網(wǎng)絡(luò)設(shè)備的統(tǒng)一管理，同時(shí)還可以根據(jù)自身的需求，開(kāi)發(fā)一些新的功能，比如網(wǎng)絡(luò)診斷。

然而SDN還處于發(fā)展的初期，目前也僅僅只有一種廣泛應(yīng)用的實(shí)現(xiàn)（OpenFlow[3]），而控制器的性能不足問(wèn)題以及網(wǎng)絡(luò)設(shè)備的兼容問(wèn)題導(dǎo)致了還沒(méi)有真正商用的SDN環(huán)境。同時(shí)，針對(duì)SDN的研究和應(yīng)用還處于活躍的上升期，暫時(shí)還沒(méi)有成熟的技術(shù)去支撐類似傳統(tǒng)網(wǎng)絡(luò)中的各種網(wǎng)絡(luò)應(yīng)用，因此也沒(méi)有很多針對(duì)SDN的網(wǎng)絡(luò)診斷工具。

2 SDN中網(wǎng)絡(luò)診斷的研究

現(xiàn)狀

2.1網(wǎng)絡(luò)診斷的形式化描述

如圖1所示，在應(yīng)用層的各種網(wǎng)絡(luò)策略（NP）通過(guò)編譯器（C）編譯成可被網(wǎng)絡(luò)設(shè)備執(zhí)行的預(yù)期網(wǎng)絡(luò)狀態(tài)（ENS），而ENS通過(guò)網(wǎng)絡(luò)設(shè)備的執(zhí)行（SE），生成真實(shí)的網(wǎng)絡(luò)狀態(tài)（ANS），

ANS還受到真實(shí)的網(wǎng)絡(luò)拓?fù)洌═）的制約。則有：

[NP→CENSSETANS]

網(wǎng)絡(luò)故障的最終體現(xiàn)是ANS有錯(cuò)誤，若往前推則有以下3種類型的故障：

（1）SE有錯(cuò)誤，即網(wǎng)絡(luò)設(shè)備的軟硬件故障。

（2）T有錯(cuò)誤，即鏈路或器件的失效。

（3）ENS有錯(cuò)誤，即配置錯(cuò)誤。

需要指出的是，一般都可以假定C是正確的，因此NP有錯(cuò)誤等價(jià)于ENS有錯(cuò)誤，即針對(duì)應(yīng)用層的網(wǎng)絡(luò)診斷等價(jià)于針對(duì)控制平面的網(wǎng)絡(luò)診斷。則在SDN環(huán)境下，網(wǎng)絡(luò)診斷的層面可分為兩種：針對(duì)控制平面的和針對(duì)數(shù)據(jù)平面的。

2.2 控制平面的網(wǎng)絡(luò)診斷

邏輯上集中式的控制平面給網(wǎng)絡(luò)管理帶來(lái)了方便，也增加了故障的可能性：所有的網(wǎng)絡(luò)應(yīng)用都有操作轉(zhuǎn)發(fā)狀態(tài)的權(quán)利，如果一個(gè)網(wǎng)絡(luò)應(yīng)用要求某一數(shù)據(jù)包轉(zhuǎn)發(fā)到端口A，而另一應(yīng)用要求轉(zhuǎn)發(fā)到端口B，那么就有可能發(fā)生錯(cuò)誤。因此有必要對(duì)控制平面的所有策略進(jìn)行評(píng)估。

文獻(xiàn)[4]-[5]提出了包頭字段分析（HSA）的方法，將數(shù)據(jù)包處理的過(guò)程抽象成同協(xié)議無(wú)關(guān)的幾何模型，即所有的網(wǎng)絡(luò)設(shè)備都是針對(duì)輸入數(shù)據(jù)包的轉(zhuǎn)移函數(shù)，網(wǎng)絡(luò)拓?fù)湟餐瑯映橄蟪梢粋€(gè)轉(zhuǎn)移函數(shù)。通過(guò)從指定數(shù)據(jù)源開(kāi)始，計(jì)算端到端的可達(dá)性，從而可以發(fā)現(xiàn)網(wǎng)絡(luò)中斷的具體位置，為網(wǎng)絡(luò)診斷提供了幫助。

文獻(xiàn)[6]提出了一種高層次的編程語(yǔ)言，提供了針對(duì)分類和匯聚網(wǎng)絡(luò)流量的聲明式查詢以及描述高層數(shù)據(jù)包轉(zhuǎn)發(fā)策略的功能庫(kù)，從而提高了網(wǎng)絡(luò)編程代碼的正確性和可重用性，類似的還有文獻(xiàn)[7]。文獻(xiàn)[8]提出了一種實(shí)時(shí)檢測(cè)網(wǎng)絡(luò)不變量的方法，它在控制器和網(wǎng)絡(luò)設(shè)備之間增加了一層，每當(dāng)有新的轉(zhuǎn)發(fā)流表項(xiàng)要插入到網(wǎng)絡(luò)設(shè)備時(shí)，該層都會(huì)去檢查，看這條新的規(guī)則是否違反了某個(gè)網(wǎng)絡(luò)不變量，從而在一定程度上避免了控制平面上多應(yīng)用之間的矛盾所帶來(lái)的網(wǎng)絡(luò)問(wèn)題。

然而針對(duì)控制平面的網(wǎng)絡(luò)診斷通常假設(shè)控制平面的所有要求都能夠被數(shù)據(jù)平面所執(zhí)行，因此只需要檢查控制平面是否存在錯(cuò)誤就可以了。顯然，這樣的假設(shè)沒(méi)有考慮到數(shù)據(jù)平面由于軟硬件故障或是固件故障的存在，而導(dǎo)致的錯(cuò)誤的轉(zhuǎn)發(fā)行為；同時(shí)，網(wǎng)絡(luò)中器件或是鏈路的失效也無(wú)法被控制平面的靜態(tài)檢測(cè)探查到。

2.3 數(shù)據(jù)平面的網(wǎng)絡(luò)診斷

文獻(xiàn)[9]-[10]利用OpenFlow協(xié)議修改每一條流表項(xiàng)，使得途徑交換機(jī)的每一個(gè)數(shù)據(jù)包都產(chǎn)生一個(gè)“明信片”，這個(gè)明信片中包含了該數(shù)據(jù)包所經(jīng)的交換機(jī)ID、出端口號(hào)和流表的版本號(hào)等信息，這樣一些信息能夠刻畫(huà)出數(shù)據(jù)包在網(wǎng)絡(luò)傳輸中途徑每一跳的真實(shí)情況，反映了數(shù)據(jù)包的網(wǎng)絡(luò)中的詳細(xì)歷史，在網(wǎng)絡(luò)診斷時(shí)能夠提供更為真實(shí)、詳細(xì)的數(shù)據(jù)支持。雖然文章提到了使用壓縮算法以及在交換機(jī)和主機(jī)端提供相應(yīng)的數(shù)據(jù)壓縮支持，但是每一個(gè)數(shù)據(jù)包產(chǎn)生一個(gè)明信片的代價(jià)依然很高。同時(shí)，局限于OpenFlow1.0協(xié)議，文章必須修改明信片中的目的多媒體接入控制（MAC）地址來(lái)輸出相關(guān)信息，而如果數(shù)據(jù)包的目的MAC地址曾被修改過(guò)，該方法是無(wú)法發(fā)現(xiàn)的。

文獻(xiàn)[11]提出在SDN/OpenFlow環(huán)境下，記錄控制信道的所有網(wǎng)絡(luò)流量和數(shù)據(jù)平面的所有網(wǎng)絡(luò)流量，并強(qiáng)調(diào)在需要診斷網(wǎng)絡(luò)時(shí)，將這些流量按照原有的順序重放出來(lái)，就能夠重現(xiàn)問(wèn)題。同時(shí)，重放流量時(shí)，可以選擇在一個(gè)隔離的試驗(yàn)環(huán)境中，這樣可以排除生產(chǎn)環(huán)境中其他因素的干擾，為網(wǎng)絡(luò)診斷和問(wèn)題診斷提供了極大的方便。該方法需要額外的數(shù)據(jù)存儲(chǔ)來(lái)儲(chǔ)存相關(guān)的網(wǎng)絡(luò)流量，當(dāng)重放的數(shù)據(jù)量很大時(shí)，存儲(chǔ)的開(kāi)銷也會(huì)相應(yīng)提高，同時(shí)，僅僅將問(wèn)題重現(xiàn)出來(lái)，并不能夠直接找到造成網(wǎng)絡(luò)故障的原因。

以上的兩種方法屬于被動(dòng)監(jiān)測(cè)的方式，通常需要很多額外的資源，比如帶寬或者是存儲(chǔ)，這樣的方式雖然很全面，但是毫無(wú)疑問(wèn)包含了很多無(wú)用的信息，這就造成了資源的浪費(fèi)。因此，還有一些工作著眼于主動(dòng)式的發(fā)送探針包，去針對(duì)數(shù)據(jù)平面進(jìn)行網(wǎng)絡(luò)診斷。

文獻(xiàn)[1]通過(guò)對(duì)網(wǎng)絡(luò)設(shè)備中所有規(guī)則的爬取，計(jì)算出能夠觸發(fā)所有規(guī)則的數(shù)據(jù)包的集合，然后周期性地在網(wǎng)絡(luò)邊緣的測(cè)試終端上發(fā)送這樣一些數(shù)據(jù)包，去定位網(wǎng)絡(luò)問(wèn)題所發(fā)生的位置。這樣的方式需要假設(shè)網(wǎng)絡(luò)狀態(tài)在較長(zhǎng)的一段時(shí)間內(nèi)是穩(wěn)定不變的，因?yàn)橛?jì)算數(shù)據(jù)包集合的時(shí)間很長(zhǎng)，這對(duì)于類似數(shù)據(jù)中心這樣的動(dòng)態(tài)場(chǎng)景顯然是不合適的。文章著重在于網(wǎng)絡(luò)故障的定位，而對(duì)于故障原因的挖掘沒(méi)有提供更有效的幫助。

文獻(xiàn)[12]提出了SDN版本的traceroute，該方法不局限在IP層，能夠輸出數(shù)據(jù)包在網(wǎng)絡(luò)中的完整路徑。局限于OpenFlow1.0協(xié)議，文章采用了染色算法去捕獲相應(yīng)的探針包，這在網(wǎng)絡(luò)設(shè)備支持多流表的情況下是完全不需要的。

3 SDN中的網(wǎng)絡(luò)診斷平面

我們提出了網(wǎng)絡(luò)診斷平面，它通過(guò)主動(dòng)的方式，利用OpenFlow1.1+協(xié)議中的多流表的功能，實(shí)現(xiàn)了探針包的識(shí)別和捕獲、流表項(xiàng)信息的輸出和各種診斷原語(yǔ)，還能夠?qū)崿F(xiàn)：

（1）主動(dòng)式的探測(cè)數(shù)據(jù)平面的真實(shí)轉(zhuǎn)發(fā)行為。

（2）診斷網(wǎng)絡(luò)連通性問(wèn)題和網(wǎng)絡(luò)性能問(wèn)題。

（3）提供程序調(diào)試器的原語(yǔ)，包括breakpoint、backtrace、single-step和continue。

主動(dòng)式網(wǎng)絡(luò)診斷系統(tǒng)的整個(gè)架構(gòu)如圖2所示，以下是主要組成部分及其功能說(shuō)明。

代理：檢查控制器下發(fā)的流修改信息，在原始信息的后面添加額外的指令，使用于網(wǎng)絡(luò)診斷的探針包能夠攜帶途徑網(wǎng)絡(luò)設(shè)備的ID、匹配的流表、匹配的流表項(xiàng)等信息。

網(wǎng)絡(luò)診斷器：根據(jù)管理員的診斷需求（測(cè)試網(wǎng)絡(luò)可達(dá)性或是網(wǎng)絡(luò)性能，不同的診斷原語(yǔ)）產(chǎn)生相關(guān)的探針包，并解析和分析收到的探針包，給出相應(yīng)的結(jié)果。

監(jiān)控端口：在網(wǎng)絡(luò)設(shè)備端，專門(mén)用來(lái)收發(fā)探針包。該端口既可以是獨(dú)占的，也可以是復(fù)用其他端口，在獨(dú)占的情況下，能夠更準(zhǔn)確地去診斷網(wǎng)絡(luò)的性能問(wèn)題。

診斷信道：帶外信道，可以復(fù)用控制信道。

網(wǎng)絡(luò)診斷的流程如圖3所示。

（1）網(wǎng)絡(luò)診斷器根據(jù)網(wǎng)絡(luò)管理員的需求，生成相關(guān)的探針包，發(fā)往指定網(wǎng)絡(luò)設(shè)備的監(jiān)控端口。

（2）探針包像正常的數(shù)據(jù)包一樣在該網(wǎng)絡(luò)設(shè)備中去匹配流表，轉(zhuǎn)發(fā)到相應(yīng)的出端口后，復(fù)制一份數(shù)據(jù)包，經(jīng)過(guò)多一級(jí)流表的處理，再通過(guò)監(jiān)控端口發(fā)往網(wǎng)絡(luò)診斷器。

（3）探針包到達(dá)下一個(gè)網(wǎng)絡(luò)設(shè)備，重復(fù)步驟2。

（5）直到探針包到達(dá)主機(jī)端被丟棄，或者跳數(shù)達(dá)到上限（由于回路的原因，或者是診斷的需求，比如只轉(zhuǎn)發(fā)三跳、到了某個(gè)交換機(jī)就不繼續(xù)轉(zhuǎn)發(fā)）。

（6）網(wǎng)絡(luò)診斷器收集并解析所有的探針包后，給出路徑信息以及每一跳所匹配過(guò)的流表項(xiàng)信息。

4 結(jié)束語(yǔ)

傳統(tǒng)網(wǎng)絡(luò)的診斷工具簡(jiǎn)單有限，對(duì)于網(wǎng)絡(luò)狀態(tài)無(wú)法及時(shí)獲取，也沒(méi)有全網(wǎng)的視角，面對(duì)各種可能導(dǎo)致網(wǎng)絡(luò)問(wèn)題的錯(cuò)誤配置、鏈路和器件失效以及軟硬件故障時(shí)，顯得無(wú)能為力。軟件定義網(wǎng)絡(luò)的誕生，帶來(lái)了控制平面和數(shù)據(jù)平面的分離，網(wǎng)絡(luò)管理員可以通過(guò)邏輯上集中式的控制器快速地獲取所有的網(wǎng)絡(luò)狀態(tài)，得到整個(gè)網(wǎng)絡(luò)的視角；而網(wǎng)絡(luò)的可編程性使定制的網(wǎng)絡(luò)診斷成為可能，加速了診斷的效率和準(zhǔn)確性。在SDN環(huán)境下，針對(duì)控制平面和數(shù)據(jù)平面的網(wǎng)絡(luò)診斷都有了一定的研究和發(fā)展，而主動(dòng)式的診斷相對(duì)被動(dòng)式有著資源消耗少、針對(duì)性強(qiáng)的特點(diǎn)，因此主動(dòng)地去診斷數(shù)據(jù)平面真實(shí)的轉(zhuǎn)發(fā)行為會(huì)是SDN網(wǎng)絡(luò)診斷的一個(gè)重要方向。

參考文獻(xiàn)

[1] Zeng H， Kazemian P， Varghese G， et al. Automatic test packet generation[C]//Proceedings of the 8th International Conference on Emerging Networking Experiments and Technologies， 2012： 241-252.doi： 10.1109/TNET.2013.2253121

[2] Gill P， Jain N， and Nagappan N. Understanding Network Failures in Data Centers： Measurement， Analysis， and Implications [C]//ACM SIGCOMM Computer Communication Review， 2011， 41（4）： 350-361.doi： 10.1145/2018436.2018477

[3] OpenFlow[EB/OL]// https：//www.opennetworking.org/sdn-resources/openflow

[4] Kazemian P， Varghese G， and McKeown N. Header Space Analysis： Static Checking for Networks[C]//NSDI， 2012： 113-126

[5] Kazemian P， Chan M， Zeng H， et al. Real Time Network Policy Checking Using Header Space Analysis[C]//NSDI， 2013： 99-111

[6] Foster N， Harrison R， Freedman M J， et al. Frenetic： A Network Programming Language[C]//ACM SIGPLAN Notices， 2011， 46（9）： 279-291

[7] Voellmy A， Agarwal A， Hudak P. Nettle： Functional Reactive programming for Openflow Networks[R]. USA： YALE University New Haven CT Dept. of Computer Science， 2010

[8] Khurshid A， Zhou W， Caesar M， et al. Veriflow： Verifying Network-Wide Invariants in Real Time [J]. ACM SIGCOMM Computer Communication Review， 2012， 42（4）： 467-472

[9] Handigol N， Heller B， Jeyakumar V， et al. Where is the Debugger for My Software-Defined Network？[C]//Proceedings of the First Workshop on Hot Topics in Software Defined Networks， 2012： 55-60

[10] Handigol N， Heller B， Jeyakumar V， et al. I know What Your Packet Did Last Hop： Using Packet Histories to Troubleshoot Networks[C]//Proc. USENIX NSDI， 2014

[11] Wundsam A， Levin D， Seetharaman S， et al. OFRewind： Enabling Record and Replay Troubleshooting for Networks[C]//USENIX Annual Technical Conference， 2011

[12] Agarwal K， Rozner E， Dixon C， et al. SDN Traceroute： Tracing SDN Forwarding Without Changing Network Behavior[C]//Proceedings of the Third Workshop on Hot Topics in Software Defined Networking， 2014： 145-150