BigBrother：UCloud 全鏈路大規模網絡連通性檢測系統詳解

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

爲此，咱們設計了一款支持全鏈路大規模的網絡連通性內部檢測系統 BigBrother。基於 TCP 報文的染色可將檢測報文和用戶流量區分開，能支持物理雲和跨地域的複雜場景，還打造了完整的檢測框架，幫助運維同事直接定位故障點，或一鍵判斷虛擬網絡是否存在問題。

BigBrother 上線後即用於雲主機遷移先後的連通性驗證，保證出現異常後能夠及時告警回滾。從 8 月初至今歷時兩個月，共遷移 2000 多臺主機，及時發現遷移異常近 10 起。

1、第一代網絡連通性工具的不足

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

檢測效率低下，不管是 ssh、packet out，仍是 tcpdump 都沒法支持大規模的快速檢查； 適應的場景有限，對於部分 dpdk、p4 網關類產品，沒法經過 tcpdump 進行抓包判斷。 所以作一款支持全鏈路大規模的連通性檢測系統是很是有必要的，咱們的目標就是讓運維、NOC 的同窗可以迅速發現並解決網絡不通的問題，同時爲咱們的虛擬網絡服務變動保駕護航。

2、BigBrother 的實現原理

BigBrother（下文簡稱 BB）一詞源自喬治奧威爾的小說《1984》，將此檢測系統命名爲 BigBrother 寓意就是能夠將全網資源連通狀況都實時監控起來。整個 BB 檢測系統由若干個組件配合完成，mafia 提供 console 進行建立及展現 task 的結果，minitrue 用於將用戶傳入的參數轉化爲注包的範圍，telescreen 用於構造報文及收發報文。

一、Entrypoint 和 Endpoint

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

Entrypoint： inbound/outbound 報文都是經由 Entrypoint 進行接受和發送的。 Endpoint：鏈接實例的端點，Endpoint 爲最接近實例的網元。 例如在公有云場景中，entrypoint 和 endpoint 都是 openvswitch，而在物理雲場景中，entrypoint 是咱們的物理雲轉發網關（vpcgw、hybridgw），endpoint 則是物理雲主機的上聯 ToR。

以上就是各類場景中的接入點說明，之因此要明確這兩個概念，是由於在 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.三、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 <gre_iface_name> 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 進行掃描，詳見 docs.ucloud.cn/network/une…

），報文以下圖所示。

四、各場景下探測報文的生命週期

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

3、Bigbrother 服務框架

整個 BB 檢測系統由若干個組件配合完成，minitrue 用於將用戶傳入的參數轉化爲注包的範圍，telescreen 用於構造報文及收發報文。

一、服務框架圖

API： FE 服務對外提供的 HTTP 接口，用於建立任務和查詢任務進度；

Logic：業務處理層，⽤於分析⼊參並將其轉換爲若干源⽬主機對放入 Disruptor 中；Disruptor：此組件爲開源高性能隊列；Sender：將 Disruptor 中 pop 的數據組裝成 GRE packet，併發送給 EntryPoint；Receiver：接收從 EndPoint 上報的 GRE packet；Analysis：將接收的報⽂存入內存中，同時對報文進⾏分析。

二、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.160<—>10.8.17.169) 的雙向連通性。

咱們再回顧下第二章中 BigBrother 檢測的流程圖，首先 BigBrother 會模擬 10.9.88.160 向 10.8.17.169 的宿主機上發送探測報文，報文的內容爲 <flag=SYN, nw_src=10.9.88.160, nw_dst=10.8.17.169>。若是 10.8.17.169 —>10.9.88.160 單向連通性正常的話，BigBrother 最終會收到 3 個報文：

（1）<flag=SYN, nw_src=10.9.88.160,

nw_dst=10.8.17.169>

（2）<flag=ACK, nw_src=10.8.17.169,

nw_dst=10.9.88.160>

（3）<flag=ACK, nw_src=10.8.17.169,

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 進行發包便可。

4、投入使用和將來計劃

BigBrother 上線後就參與到了資源整合項目中，用於雲主機遷移先後的連通性驗證，保證出現異常後能夠及時告警回滾。從 8 月初至今歷時兩個月，共遷移 2000 多臺主機，及時發現遷移異常近 10 起。

同時，咱們對 BigBrother 後續版本也有着必定的規劃，例如：

除了對連通性的檢測外，還須要有平均時延，最大時延對、丟包率的檢測； 打算基於 BigBrother 構建針對指定用戶的內網全天候監控。