BigBrother：UCloud全链路大规模网络连通性检测系统详解

摘要：宋体为此，我们设计了一款支持全链路大规模的网络连通性内部检测系统。宋体因此做一款支持全链路大规模的连通性检测系统是非常有必要的，我们的目标就是让运维的同学能够迅速发现并解决网络不通的问题，同时为我们的虚拟网络服务变更保驾护航。

虚拟网络排查问题困难，传统的 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

• 跨域网关

公有云跨域互通场景下，探测报文生命周期如下：