虛拟網絡排查問題困難，傳統的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=0x40
action部分主要由四部分組成： •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收到封包後鏡像至BigBrother 3)ovs将封包送至執行個體 4)執行個體回應封包 5)ovs将回應封包鏡像至BigBrother 6)實體雲核心交換機收到封包，并發送給彙聚交換機 7)8)9)10)實體雲彙聚交換機發送封包給vpcgw，vpcgw處理封包後回送至彙聚交換機 11)在實體雲彙聚交換機配置ERSPAN，将封包鏡像至BigBrother。 實體雲—> 公有雲
1)BigBrother向vpcgw發送探測封包 2)3)vpcgw處理封包後回送至彙聚交換機 4)在實體雲彙聚交換機配置ERSPAN，将封包鏡像至BigBrother 5)彙聚交換機将封包送至phost的上聯Tor 6)Tor将封包送至phost 7)phost回應封包 8)在phost的上聯Tor配置ERSPAN，将封包鏡像至BigBrother 9)封包送至公有雲主控端ovs 10)ovs收到封包後鏡像至BigBrother
- 跨域網關
公有雲跨域互通場景下，探測封包生命周期如下：
本地域—> 地域B
1)BigBrother 向本域主機發送探測封包
2)ovs收到封包後鏡像至BigBrother 3)ovs将封包送至執行個體 4)執行個體回應封包 5)ovs将回應封包鏡像至BigBrother 6)ovs将封包送至sdngw 7)sdngw将封包鏡像至BigBrother 地域B—> 本地域
1)BigBrother 向本域sdngw發送探測封包 2)sdngw收到封包後鏡像至BigBrother 3)sdngw将封包送至對端sdngw進行轉發 4)本域sdngw收到對端回應封包 5)sdngw将回應封包鏡像至BigBrother 6)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： 将接收的報⽂存入記憶體中，同時對封包進⾏分析。2 Task的執行及結果分析 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技術”
！