共计 6933 个字符，预计需要花费 18 分钟才能阅读完成。
虚拟网络排查问题困难，传统的 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）一词源自乔治奥威尔的小说《1984》，将此检测系统命名为 BigBrother 寓意就是可以将全网资源连通情况都实时监控起来。整个 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 <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 进行扫描，详见 https://docs.ucloud.cn/networ…
），报文如下图所示。
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：将接收的报⽂存入内存中，同时对报文进⾏分析。
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.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 进行发包即可。
四、投入使用和未来计划
BigBrother 上线后就参与到了资源整合项目中，用于云主机迁移前后的连通性验证，保证出现异常后可以及时告警回滚。从 8 月初至今历时两个月，共迁移 2000 多台主机，及时发现迁移异常近 10 起。
同时，我们对 BigBrother 后续版本也有着一定的规划，例如：
除了对连通性的检测外，还需要有平均时延，最大时延对、丢包率的检测；
打算基于 BigBrother 构建针对指定用户的内网全天候监控。
