虛擬網(wǎng)絡(luò)排查問題困難，傳統(tǒng)的traceroute等工具很難起到太大作用，大部分情況下都需要到宿主機(jī)、混合云網(wǎng)關(guān)上抓包來troubleshooting，耗時(shí)又費(fèi)力。有些場景中包的傳送路徑比較長(如跨域、混合云等)，可能丟包的地方比較多，更增加了故障排查的難度。

為此，我們?cè)O(shè)計(jì)了一款支持全鏈路大規(guī)模的網(wǎng)絡(luò)連通性內(nèi)部檢測系統(tǒng)BigBrother?；赥CP報(bào)文的染色可將檢測報(bào)文和用戶流量區(qū)分開，能支持物理云和跨地域的復(fù)雜場景，還打造了完整的檢測框架，幫助運(yùn)維同事直接定位故障點(diǎn)，或一鍵判斷虛擬網(wǎng)絡(luò)是否存在問題。BigBrother上線后即用于云主機(jī)遷移前后的連通性驗(yàn)證，保證出現(xiàn)異常后可以及時(shí)告警回滾。從8月初至今歷時(shí)兩個(gè)月，共遷移2000多臺(tái)主機(jī)，及時(shí)發(fā)現(xiàn)遷移異常近10起。

一、第一代網(wǎng)絡(luò)連通性工具的不足在設(shè)計(jì)BigBrother這前，我們也有第一代的網(wǎng)絡(luò)連通性檢查工具，原理就是通過SSH跳轉(zhuǎn)到目標(biāo)宿主機(jī)上，利用ovs的packet out命令將構(gòu)造的報(bào)文發(fā)出去，最后在對(duì)端的宿主機(jī)上tcpdump該報(bào)文，從而驗(yàn)證兩端的連通性。但是從它的原理就不難看出，這種檢測方式有著很大的缺點(diǎn)：

• 檢測效率低下，無論是ssh、packet out，還是tcpdump都無法支持大規(guī)模的快速檢查；

• 適應(yīng)的場景有限，對(duì)于部分dpdk、p4網(wǎng)關(guān)類產(chǎn)品，無法通過tcpdump進(jìn)行抓包判斷。

因此做一款支持全鏈路大規(guī)模的連通性檢測系統(tǒng)是非常有必要的，我們的目標(biāo)就是讓運(yùn)維、NOC的同學(xué)能夠迅速發(fā)現(xiàn)并解決網(wǎng)絡(luò)不通的問題，同時(shí)為我們的虛擬網(wǎng)絡(luò)服務(wù)變更保駕護(hù)航。二、BigBrother的實(shí)現(xiàn)原理BigBrother(下文簡稱BB)可以將全網(wǎng)資源連通情況都實(shí)時(shí)監(jiān)控起來，整個(gè)BB檢測系統(tǒng)由若干個(gè)組件配合完成，mafia提供console進(jìn)行創(chuàng)建及展示task的結(jié)果，minitrue用于將用戶傳入的參數(shù)轉(zhuǎn)化為注包的范圍，telescreen用于構(gòu)造報(bào)文及收發(fā)報(bào)文。1

Entrypoint和Endpoint

?在具體介紹BB的原理前，我們先來看兩個(gè)概念。在我們的虛擬網(wǎng)絡(luò)中，每個(gè)實(shí)例(uhost、umem、udb等)都是通過接入點(diǎn)來接入虛擬網(wǎng)絡(luò)，接入點(diǎn)由兩部分組成：

• Entrypoint： inbound/outbound報(bào)文都是經(jīng)由Entrypoint進(jìn)行接受和發(fā)送的。

• Endpoint：連接實(shí)例的端點(diǎn)，Endpoint為最接近實(shí)例的網(wǎng)元。

例如在公有云場景中，entrypoint和endpoint都是openvswitch，而在物理云場景中，entrypoint是我們的物理云轉(zhuǎn)發(fā)網(wǎng)關(guān)(vpcgw、hybridgw)，endpoint則是物理云主機(jī)的上聯(lián)ToR。

場景	Entrypoint	Endpoint
公有云	ovs	ovs
物理云	vpcgw、hybridgw	ToR
托管云	hcgw、cloudgw	PE
跨域網(wǎng)關(guān)	sdngw	ovs
公共服務(wù)	ovs	ovs
CNAT	ovs	ovs
托管云(UXR)	UXR	PE
跨域網(wǎng)關(guān)(UXR)	UXR	ovs
CNAT(UXR)	UXR	ovs

以上就是各種場景中的接入點(diǎn)說明，之所以要明確這兩個(gè)概念，是因?yàn)樵贐B系統(tǒng)中，我們將Entrypoint作為注包點(diǎn)，向其發(fā)送GRE探測報(bào)文，同時(shí)將Endpoint作為采樣點(diǎn)，Endpoint會(huì)識(shí)別并鏡像特殊的探測報(bào)文至BB。

2檢測流程檢測方案如圖所示，可分為兩部分組成，在圖中的流向分為橙色和紫色。

以橙色流向部分為例(SRC->DST)：1)BigBrother模擬DST向Endpoint發(fā)送探測報(bào)文；2)SRC端Entrypoint收到該探測報(bào)文后轉(zhuǎn)發(fā)給Endpoint；3)Endpoint將該報(bào)文鏡像至BigBrother；4)Endpoint將報(bào)文正常轉(zhuǎn)發(fā)至實(shí)例；5)實(shí)例回復(fù)報(bào)文給Endpoint；6)Endpoint收到該回復(fù)報(bào)文后進(jìn)行GRE封裝，然后鏡像至BigBrother；7)Endpoint將報(bào)文正常轉(zhuǎn)發(fā)至Entrypoint；8)SRC Entrypoint將回復(fù)報(bào)文發(fā)送至DST Entrypoint；9)DST Entrypoint收到回復(fù)報(bào)文后發(fā)送給Endpoint；10)DST Endpoint將回復(fù)報(bào)文鏡像至Bigbrother。至此，單邊的檢測結(jié)束。在檢測過程中，BigBrother發(fā)送了1個(gè)探測報(bào)文，共收到了3個(gè)采樣報(bào)文，通過分析這3個(gè)采樣點(diǎn)可以確認(rèn)SRC->DST方向是否通信正常。反之亦然，紫色部分原理相同。全部檢測結(jié)束后，BigBrother共可以收到6個(gè)探測報(bào)文，如果6個(gè)報(bào)文均收到則表示連通性正常。3探測報(bào)文設(shè)計(jì)?上文中介紹了BB的檢測流程，下面我們?cè)賮砜聪绿綔y報(bào)文及轉(zhuǎn)發(fā)面的設(shè)計(jì)實(shí)現(xiàn)。公有云和混合云的設(shè)計(jì)存在很多不同。公有云轉(zhuǎn)發(fā)面需要在全局hook點(diǎn)(table_1)，分別hook探測報(bào)文的request和response，然后進(jìn)行染色、鏡像至BB等步驟。而混合云轉(zhuǎn)發(fā)面則需要ToR、PE交換機(jī)開啟ERSPAN功能，將染色的報(bào)文鏡像至BB即可。整體數(shù)據(jù)包交互如下圖所示：

而一個(gè)合格的探測報(bào)文首先應(yīng)該具備以下特征：

• 染色信息與主機(jī)、OS無關(guān)；

• ovs2.3、ovs2.6版本(現(xiàn)網(wǎng)主要版本)可以識(shí)別并處理此種染色信息。

因此我們?cè)敿?xì)比較了如下兩種候選方案。1)icmp + tos方案第一種方案以icmp報(bào)文為載體，使用tos對(duì)icmp_request進(jìn)行染色，采集時(shí)將此tos的icmp報(bào)文鏡像至BB即可。cookie=0x20008,table=1,priority=40000,metadata=0x1,icmp,icmp_type=8,icmp_code=0,nw_tos=0x40 actions=Send_BB(),Learn(),Back_0()對(duì)于hook icmp_request的flow可以簡化為如下邏輯：action部分主要由三部分組成：

• Send_BB() 將報(bào)文鏡像給BB；

• Learn() 通過icmp_request報(bào)文學(xué)習(xí)到一條用于匹配icmp_reply報(bào)文的flow，該條flow的主要?jiǎng)幼靼?#xff1a;染色、鏡像至BB；

# 1. ??REG3 ?64200# (global hook) reg3 load:64200->NXM_NX_REG3[], #?2.?learn?action?learn(table=31,idle_timeout=2,hard_timeout=4,priority=30000,dl_type=0x0800,ip_proto=1,icmp_type=0,icmp_code=0,NXM_OF_IP_SRC[]=NXM_OF_IP_DST[],NXM_OF_IP_DST[?]=NXM_OF_IP_SRC[],Stain(),Send_BB()),# 3. REG3 0load:0->NXM_NX_REG3[]?

• Back_0() 將該報(bào)文送回table_0，進(jìn)行常規(guī)的轉(zhuǎn)發(fā)操作。

對(duì)于hook icmp_reply的flow可以簡化為如下邏輯：cookie=0x20008,table=1,priority=40000,metadata=0x1,icmp,icmp_type=0,icmp_code=0,nw_tos=0x40action部分主要由四部分組成：?Save(in_port, tun_src) 將報(bào)文中的in_port和tun_src保存下來；?Resubmit(table=31) 跳轉(zhuǎn)至table31，匹配icmp_request learn生成的flow；?Restore(in_port, tun_src) 恢復(fù)in_port和tun_src；?Back_0() 將該報(bào)文送回table_0，進(jìn)行常規(guī)的轉(zhuǎn)發(fā)操作。以上討論的是公有云側(cè)ovs的染色及鏡像方法，而混合云側(cè)就需要交換機(jī)ERSPAN來進(jìn)行支持，為了使ERSPAN規(guī)則可以鏡像tos染色報(bào)文，需要GRE外層Ip Header中的tos繼承overlay Ip Header中標(biāo)記的tos，所以需要全網(wǎng)對(duì)GRE隧道設(shè)置繼承內(nèi)層tos的隧道屬性，執(zhí)行命令如下：ovs-vsctl set in options:tos=inherit此種方案雖然可以實(shí)現(xiàn)染色及鏡像的功能，但是hook點(diǎn)預(yù)埋的flow過于復(fù)雜，不容易維護(hù)，最關(guān)鍵的一點(diǎn)在于，混合云網(wǎng)絡(luò)中，該方案無法支持 learn flow，所以無法對(duì)反向的流量進(jìn)行染色。2)tcp方案第二種方案以tcp報(bào)文為載體，使用特定的端口作為染色條件，采集時(shí)將此源目端口的tcp報(bào)文鏡像至BB即可。cookie=0x20008,table=1,priority=40000,tcp,metadata=0x1,tp_src=[port],tp_dst=[port]?actions=Send_BB(),Back_0()對(duì)于hook tcp_request的flow可以簡化為如下邏輯：action部分主要由兩部分組成：?Send_BB() 將報(bào)文鏡像給BB；?Back_0() 將該報(bào)文送回table_0，進(jìn)行常規(guī)的轉(zhuǎn)發(fā)操作。

以上兩種方案進(jìn)行對(duì)比不難看出，第一種方案依賴較多并且適用場景受限，所以BB采用的是第二種方案。但是tcp方案也有一定的缺陷，如何選擇染色的port并且要與用戶的流量區(qū)分開來，這是一個(gè)難點(diǎn)。經(jīng)過我們幾次踩坑后分析，最后決定使用tcp源目port=11來進(jìn)行染色(目前已告知用戶會(huì)使用TCP 端口11進(jìn)行掃描，詳見文檔)，報(bào)文如下圖所示。

4各場景下探測報(bào)文的生命周期BB被設(shè)計(jì)為支持多種網(wǎng)絡(luò)場景，能應(yīng)對(duì)物理云和跨域互通的網(wǎng)絡(luò)復(fù)雜性。這章節(jié)我們以探測物理云和跨域?yàn)槔?#xff0c;詳細(xì)分析下BB探測報(bào)文的生命周期。

• 物理云

公有云互通物理云場景下，探測報(bào)文生命周期如下：

公有云—> 物理云

1)BigBrother向公有云宿主機(jī)發(fā)送探測報(bào)文

2)ovs收到報(bào)文后鏡像至BigBrother3)ovs將報(bào)文送至實(shí)例4)實(shí)例回應(yīng)報(bào)文5)ovs將回應(yīng)報(bào)文鏡像至BigBrother6)物理云核心交換機(jī)收到報(bào)文，并發(fā)送給匯聚交換機(jī)7)8)9)10)物理云匯聚交換機(jī)發(fā)送報(bào)文給vpcgw，vpcgw處理報(bào)文后回送至匯聚交換機(jī)11)在物理云匯聚交換機(jī)配置ERSPAN，將報(bào)文鏡像至BigBrother。物理云—> 公有云

1)BigBrother向vpcgw發(fā)送探測報(bào)文2)3)vpcgw處理報(bào)文后回送至匯聚交換機(jī)4)在物理云匯聚交換機(jī)配置ERSPAN，將報(bào)文鏡像至BigBrother5)匯聚交換機(jī)將報(bào)文送至phost的上聯(lián)Tor6)Tor將報(bào)文送至phost7)phost回應(yīng)報(bào)文8)在phost的上聯(lián)Tor配置ERSPAN，將報(bào)文鏡像至BigBrother9)報(bào)文送至公有云宿主機(jī)ovs10)ovs收到報(bào)文后鏡像至BigBrother

• 跨域網(wǎng)關(guān)

公有云跨域互通場景下，探測報(bào)文生命周期如下：

本地域—> 地域B

1)BigBrother 向本域主機(jī)發(fā)送探測報(bào)文

2)ovs收到報(bào)文后鏡像至BigBrother3)ovs將報(bào)文送至實(shí)例4)實(shí)例回應(yīng)報(bào)文5)ovs將回應(yīng)報(bào)文鏡像至BigBrother6)ovs將報(bào)文送至sdngw7)sdngw將報(bào)文鏡像至BigBrother地域B—> 本地域

1)BigBrother 向本域sdngw發(fā)送探測報(bào)文2)sdngw收到報(bào)文后鏡像至BigBrother3)sdngw將報(bào)文送至對(duì)端sdngw進(jìn)行轉(zhuǎn)發(fā)4)本域sdngw收到對(duì)端回應(yīng)報(bào)文5)sdngw將回應(yīng)報(bào)文鏡像至BigBrother6)sdngw將報(bào)文送至本地域宿主機(jī)7)ovs將報(bào)文鏡像至BigBrother三、Bigbrother服務(wù)框架整個(gè)BB檢測系統(tǒng)由若干個(gè)組件配合完成，minitrue用于將用戶傳入的參數(shù)轉(zhuǎn)化為注包的范圍，telescreen用于構(gòu)造報(bào)文及收發(fā)報(bào)文。

1服務(wù)框架圖API：FE服務(wù)對(duì)外提供的HTTP接口，用于創(chuàng)建任務(wù)和查詢?nèi)蝿?wù)進(jìn)度；Logic：業(yè)務(wù)處理層，?于分析?參并將其轉(zhuǎn)換為若干源?主機(jī)對(duì)放入Disruptor中；Disruptor：此組件為開源高性能隊(duì)列；Sender：將Disruptor中pop的數(shù)據(jù)組裝成GRE packet，并發(fā)送給EntryPoint；Receiver：接收從EndPoint上報(bào)的GRE packet；Analysis：將接收的報(bào)?存入內(nèi)存中，同時(shí)對(duì)報(bào)文進(jìn)?分析。2Task的執(zhí)行及結(jié)果分析?1)task上文中我們?cè)敿?xì)介紹了BB探測報(bào)文的設(shè)計(jì)和生命周期，但是我們還有一個(gè)問題需要解決：提高BB的并發(fā)能力。按照上文的介紹，每次BB只能執(zhí)行一次探測，順序執(zhí)行才能保證檢測結(jié)果的準(zhǔn)確性，所以我們?cè)O(shè)計(jì)利用TCP報(bào)頭中的序列號(hào)來提高并發(fā)。以下是一個(gè)TCP報(bào)文的首部結(jié)構(gòu)：

其中32位的Seq序列號(hào)就是我們要利用的，在BB探測過程中每個(gè)Seq序列號(hào)都唯?標(biāo)識(shí)?個(gè)pair對(duì)，然后我們將Seq序列號(hào)分成了兩部分：

• Task_id：?于標(biāo)識(shí)一個(gè)Task，由于僅有5位，所以每次同時(shí)進(jìn)?的Task不能超過32個(gè) ；

• Pair_id：用于標(biāo)識(shí)在一個(gè)Task內(nèi)，待檢測的一個(gè)pair對(duì)。

因此，我們可以將BB并發(fā)的任務(wù)數(shù)提高到了32個(gè)，而每個(gè)任務(wù)支持最大的檢測pair對(duì)數(shù)可以達(dá)到2的27次方，相當(dāng)于每個(gè)任務(wù)都可以支持一個(gè)容量為10000臺(tái)云主機(jī)的VPC進(jìn)行Full Mesh檢測，足以覆蓋現(xiàn)有用戶的網(wǎng)絡(luò)規(guī)模。2)task的執(zhí)行當(dāng)運(yùn)維同學(xué)在mafia(任務(wù)控制臺(tái))上點(diǎn)擊創(chuàng)建一個(gè)BB task進(jìn)行連通性檢查時(shí)，會(huì)經(jīng)歷以下幾個(gè)過程：

?請(qǐng)求發(fā)送給minitrue服務(wù)，根據(jù)輸入的參數(shù)來確定探測范圍；?minitrue將計(jì)算得到的探測范圍以源、目節(jié)點(diǎn)列表的形式發(fā)送給telescreen服務(wù)；?telescreen構(gòu)建Gre報(bào)文，并放入高性能隊(duì)列中進(jìn)行發(fā)包；同時(shí)，telescreen會(huì)監(jiān)聽網(wǎng)卡獲取鏡像報(bào)文回來的報(bào)文并存入內(nèi)存；?minitrue的分析程序定時(shí)獲取telescreen的收包結(jié)果并進(jìn)行分析；?最后運(yùn)維同學(xué)可以在mafia上看到最終的探測結(jié)果。

3)task的結(jié)果分析task執(zhí)行結(jié)束后，運(yùn)維同學(xué)可以在mafia查看到最后的檢測報(bào)告，包括發(fā)送的總pair數(shù)、收到的pair數(shù)、成功以及失敗的數(shù)量。同時(shí)，檢測失敗的源目詳細(xì)信息也會(huì)展示出來，最終以bitmap的方式呈現(xiàn)出來，0表示沒有收到報(bào)文，1表示收到報(bào)文。我們以下圖的結(jié)果為例，解釋其含義。圖中是檢測ip pair(10.9.88.16010.8.17.169)的雙向連通性。

我們?cè)倩仡櫹碌诙轮蠦igBrother檢測的流程圖，首先BigBrother會(huì)模擬10.9.88.160向10.8.17.169的宿主機(jī)上發(fā)送探測報(bào)文，報(bào)文的內(nèi)容為。如果10.8.17.169 —>10.9.88.160 單向連通性正常的話，BigBrother最終會(huì)收到3個(gè)報(bào)文：

(1)

nw_dst=10.8.17.169>

(2)

nw_dst=10.9.88.160>

(3)

nw_dst=10.9.88.160>

上圖bitmap后三位的結(jié)果為111，表示這3個(gè)報(bào)文都收到了，即10.8.17.169 —>10.9.88.160 單向的連通性正常。

反之亦然，前三位則表示10.9.88.160 —> 10.8.17.169單向的連通性情況，結(jié)果為100，(2)(3)報(bào)文沒有收到，即表示 10.9.88.160 —> 10.8.17.169單向的連通性異常，虛機(jī)10.9.88.160沒有回復(fù)報(bào)文，可以斷定虛機(jī)內(nèi)部異常或虛機(jī)內(nèi)部存在iptables規(guī)則將探測報(bào)文過濾。3基于活躍flow的連通性檢查上文我們提到，運(yùn)維同學(xué)可以在mafia上創(chuàng)建BB task來進(jìn)行連通性的檢查，通過傳入mac、子網(wǎng)id、VPC id來確定檢測的范圍，進(jìn)而進(jìn)行全量驗(yàn)證。但是大多數(shù)場景中，我們不需要進(jìn)行全互聯(lián)檢查，這樣不僅浪費(fèi)時(shí)間而且還會(huì)對(duì)控制面造成一定的壓力。我們僅需要針對(duì)指定范圍內(nèi)的活躍flow驗(yàn)證連通性即可，所以我們又引入了活躍flow檢測的服務(wù)——river。river是虛擬網(wǎng)絡(luò)億級(jí)別活躍流的分析系統(tǒng)，借助這個(gè)系統(tǒng)BB可以拿到用戶的活躍通信源目，類似于緩存里的熱點(diǎn)數(shù)據(jù)，這樣可以讓BB快速精準(zhǔn)驗(yàn)證變更。

與上文全量BB探測的區(qū)別在于，minitrue無須自己計(jì)算源、目節(jié)點(diǎn)列表，只需指定范圍后向river獲取活躍列表，然后通過常規(guī)的檢測流程將列表傳送給telescreen進(jìn)行發(fā)包即可。四、投入使用和未來計(jì)劃BigBrother上線后就參與到了資源整合項(xiàng)目中，用于云主機(jī)遷移前后的連通性驗(yàn)證，保證出現(xiàn)異常后可以及時(shí)告警回滾。從8月初至今歷時(shí)兩個(gè)月，共遷移2000多臺(tái)主機(jī)，及時(shí)發(fā)現(xiàn)遷移異常近10起。同時(shí)，我們對(duì)BigBrother后續(xù)版本也有著一定的規(guī)劃，例如：

• 除了對(duì)連通性的檢測外，還需要有平均時(shí)延，最大時(shí)延對(duì)、丟包率的檢測；

• 打算基于BigBrother構(gòu)建針對(duì)指定用戶的內(nèi)網(wǎng)全天候監(jiān)控。

來源：本文轉(zhuǎn)自公眾號(hào) Ucloud 技術(shù)。

更多云實(shí)踐和技術(shù)干貨，歡迎關(guān)注“UCloud技術(shù)”！

總結(jié)

以上是生活随笔為你收集整理的c语言 判断一个图是否全连通_基于云平台的全链路大规模网络连通性检测系统详解...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。