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

為此，我們設計了一款支持全鏈路大規模的網絡連通性內部檢測系統BigBrother。基于TCP報文的染色可將檢測報文和用戶流量區分開，能支持物理云和跨地域的復雜場景，還打造了完整的檢測框架，幫助運維同事直接定位故障點，或一鍵判斷虛擬網絡是否存在問題。BigBrother上線后即用于云主機遷移前后的連通性驗證，保證出現異常后可以及時告警回滾。從8月初至今歷時兩個月，共遷移2000多臺主機，及時發現遷移異常近10起。

一、第一代網絡連通性工具的不足在設計BigBrother這前，我們也有第一代的網絡連通性檢查工具，原理就是通過SSH跳轉到目標宿主機上，利用ovs的packet out命令將構造的報文發出去，最后在對端的宿主機上tcpdump該報文，從而驗證兩端的連通性。但是從它的原理就不難看出，這種檢測方式有著很大的缺點：

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

• 適應的場景有限，對于部分dpdk、p4網關類產品，無法通過tcpdump進行抓包判斷。

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

Entrypoint和Endpoint

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

• Entrypoint： inbound/outbound報文都是經由Entrypoint進行接受和發送的。

• Endpoint：連接實例的端點，Endpoint為最接近實例的網元。

例如在公有云場景中，entrypoint和endpoint都是openvswitch，而在物理云場景中，entrypoint是我們的物理云轉發網關(vpcgw、hybridgw)，endpoint則是物理云主機的上聯ToR。

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

以上就是各種場景中的接入點說明，之所以要明確這兩個概念，是因為在BB系統中，我們將Entrypoint作為注包點，向其發送GRE探測報文，同時將Endpoint作為采樣點，Endpoint會識別并鏡像特殊的探測報文至BB。

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

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

而一個合格的探測報文首先應該具備以下特征：

• 染色信息與主機、OS無關；

• ovs2.3、ovs2.6版本(現網主要版本)可以識別并處理此種染色信息。

因此我們詳細比較了如下兩種候選方案。1)icmp + tos方案第一種方案以icmp報文為載體，使用tos對icmp_request進行染色，采集時將此tos的icmp報文鏡像至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()對于hook icmp_request的flow可以簡化為如下邏輯：action部分主要由三部分組成：

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

• Learn() 通過icmp_request報文學習到一條用于匹配icmp_reply報文的flow，該條flow的主要動作包括：染色、鏡像至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() 將該報文送回table_0，進行常規的轉發操作。

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

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

4各場景下探測報文的生命周期BB被設計為支持多種網絡場景，能應對物理云和跨域互通的網絡復雜性。這章節我們以探測物理云和跨域為例，詳細分析下BB探測報文的生命周期。

• 物理云

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

公有云—> 物理云

1)BigBrother向公有云宿主機發送探測報文

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

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

• 跨域網關

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

本地域—> 地域B

1)BigBrother 向本域主機發送探測報文

2)ovs收到報文后鏡像至BigBrother3)ovs將報文送至實例4)實例回應報文5)ovs將回應報文鏡像至BigBrother6)ovs將報文送至sdngw7)sdngw將報文鏡像至BigBrother地域B—> 本地域

1)BigBrother 向本域sdngw發送探測報文2)sdngw收到報文后鏡像至BigBrother3)sdngw將報文送至對端sdngw進行轉發4)本域sdngw收到對端回應報文5)sdngw將回應報文鏡像至BigBrother6)sdngw將報文送至本地域宿主機7)ovs將報文鏡像至BigBrother三、Bigbrother服務框架整個BB檢測系統由若干個組件配合完成，minitrue用于將用戶傳入的參數轉化為注包的范圍，telescreen用于構造報文及收發報文。

1服務框架圖API：FE服務對外提供的HTTP接口，用于創建任務和查詢任務進度；Logic：業務處理層，?于分析?參并將其轉換為若干源?主機對放入Disruptor中；Disruptor：此組件為開源高性能隊列；Sender：將Disruptor中pop的數據組裝成GRE packet，并發送給EntryPoint；Receiver：接收從EndPoint上報的GRE packet；Analysis：將接收的報?存入內存中，同時對報文進?分析。2Task的執行及結果分析?1)task上文中我們詳細介紹了BB探測報文的設計和生命周期，但是我們還有一個問題需要解決：提高BB的并發能力。按照上文的介紹，每次BB只能執行一次探測，順序執行才能保證檢測結果的準確性，所以我們設計利用TCP報頭中的序列號來提高并發。以下是一個TCP報文的首部結構：

其中32位的Seq序列號就是我們要利用的，在BB探測過程中每個Seq序列號都唯?標識?個pair對，然后我們將Seq序列號分成了兩部分：

• Task_id：?于標識一個Task，由于僅有5位，所以每次同時進?的Task不能超過32個 ；

• Pair_id：用于標識在一個Task內，待檢測的一個pair對。

因此，我們可以將BB并發的任務數提高到了32個，而每個任務支持最大的檢測pair對數可以達到2的27次方，相當于每個任務都可以支持一個容量為10000臺云主機的VPC進行Full Mesh檢測，足以覆蓋現有用戶的網絡規模。2)task的執行當運維同學在mafia(任務控制臺)上點擊創建一個BB task進行連通性檢查時，會經歷以下幾個過程：

?請求發送給minitrue服務，根據輸入的參數來確定探測范圍；?minitrue將計算得到的探測范圍以源、目節點列表的形式發送給telescreen服務；?telescreen構建Gre報文，并放入高性能隊列中進行發包；同時，telescreen會監聽網卡獲取鏡像報文回來的報文并存入內存；?minitrue的分析程序定時獲取telescreen的收包結果并進行分析；?最后運維同學可以在mafia上看到最終的探測結果。

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

我們再回顧下第二章中BigBrother檢測的流程圖，首先BigBrother會模擬10.9.88.160向10.8.17.169的宿主機上發送探測報文，報文的內容為。如果10.8.17.169 —>10.9.88.160 單向連通性正常的話，BigBrother最終會收到3個報文：

(1)

nw_dst=10.8.17.169>

(2)

nw_dst=10.9.88.160>

(3)

nw_dst=10.9.88.160>

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

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

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

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

• 打算基于BigBrother構建針對指定用戶的內網全天候監控。

來源：本文轉自公眾號 Ucloud 技術。

更多云實踐和技術干貨，歡迎關注“UCloud技術”！

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。