摘要：宋體為此，我們設計了一款支持全鏈路大規模的網絡連通性內部檢測系統。宋體因此做一款支持全鏈路大規模的連通性檢測系統是非常有必要的，我們的目標就是讓運維的同學能夠迅速發現并解決網絡不通的問題，同時為我們的虛擬網絡服務變更保駕護航。

虛擬網絡排查問題困難，傳統的 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。

以上就是各種場景中的接入點說明，之所以要明確這兩個概念，是因為在 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 進行掃描，詳見 https://docs.ucloud.cn/network/unet/faq

），報文如下圖所示。

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

• 跨域網關

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