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.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构建针对指定用户的内网全天候监控。

本文转载自公众号UCloud技术（ID：ucloud_tech）。

原文链接：

https://mp.weixin.qq.com/s/M46d-Vync6M272dsGEg_tQ

创作场景

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