仮想ネットワークのトラブルシューティング難しい問題は、そのような多くの場合に大きな役割を果たしていることは困難tracerouteのような伝統的なツールは、ホスト上のトラブルシューティングのためにキャプチャする必要がある、ハイブリッドクラウドゲートウェイ、時間がかかり、骨の折れます。いくつかのシーンでのパケット伝送路が比較的長い（例えば、クロスドメイン、混合雲など）、パケット損失可能な場合より、それはトラブルシューティングの難しさを増大させます。
この目的のために、我々は設計されたサポート完全なネットワーク接続リンクの大規模な内部検出システムBigBrotherを。直接障害が発生した時点、または仮想キーの判断を見つけ、複雑な雲物理学と地域横断的シーンをサポートすることができますが、また、運用・保守に同僚を助けるために、完全なテストフレームワークを作成するには、TCPパケット染色メッセージとユーザトラフィックエリアに基づいて分離することができます問題がある場合、ネットワーク。
オンラインの通信クラウドホストの移行の検証前後のBigBrother、タイムリーな警告異常なロールバックを確実にします。8月の初めは、2ヶ月間続いていることから、2000以上のマイグレーション・ホストの合計は、ほぼ10例異常な移動を検出します。
未満、ネットワーク接続ツールの第一世代
前にこのBigBrother設計では、我々はまた、ツールをチェックし、ネットワーク接続の第一世代を持って、原理が出て送信されたメッセージのコマンド構造、そして最終的にホストピアからパケットOVS使用し、ターゲットホストにジャンプするSSH経由で接続を越え検証するために、メッセージをtcpdumpの。それがどのように動作するかを見ることは難しいことではありません。しかし、この検出方法は大きな欠点があります。
sshは、アウトパケットかどうか、非効率的な検出、またはtcpdumpのは、大規模な簡単なチェックをサポートすることはできません。
シーンの限られた適応、いくつかのdpdk、P4のゲートウェイ製品のため、キャプチャに、tcpdumpによって判断することはできません。
だから、私たちの目標は、操作およびメンテナンスを行うことで、非常に必要である大規模なサポートフルリンク接続検知システムの操作を行い、NOCの学生はすぐにネットワークの問題を発見し、解決することができ意味をなさない、と私たちの仮想ネットワークサービスに変更されていません護衛。
BigBrotherの原則の第二に、実現
BigBrother（以下、BBと呼ぶ）ジョージ・オーウェルの「1984」から単語小説、BigBrother含意という名前のこの検出システムを使用すると、リアルタイムでそれらを監視し、ネットワーク全体の接続リソースを持つことができるということです。いくつかの構成要素の完了にBB全検出システム、コンソールを提供し、タスクの結果を表示するために作成マフィアは、パケットの注入の範囲内にパラメータを渡すためにユーザーのためのminitrue、テレスクリーンは、パケットとパケットを送受信するように構成される。
1、エントリポイント和エンドポイント
BBは、特定の原則の導入前に、の二つの概念を見てみましょう。我々の仮想ネットワークでは、各インスタンス（uhost、UMEM、UDBなど）の仮想ネットワークにアクセスするためにアクセスポイントによって実装され、アクセスポイントは、2つの部分で構成さ：
エントリポイント：アウトバウンド/インバウンドメッセージが送信され、エントリポイントの行動を介して受信されています。
エンドポイント：接続エンドポイントインスタンス、ネットワーク要素のエンドポイントの最も近い例。
例えば、パブリッククラウドシナリオでは、エントリポイントとエンドポイントはopenvswitchであり、物理的なクラウドのシナリオでは、エントリポイントは、私たちの物理的な転送ゲートウェイ（vpcgw、hybridgw）をクラウドで、エンドポイントは、関節のToR物理クラウドホストです。
これらは、アクセスポイントは、さまざまなシナリオ、我々はGREのプローブパケットを送信するために、パッケージエントリポイントのポイントに注意しますように、これらの2つの概念は、理由BBシステムでは、明確でなければならない理由を説明しているエンドポイント間のサンプリングポイントとして、エンドポイントは認識し、BBに特殊なプローブパケットをミラーリング。
2、試験手順
図検出スキームに示すように、図では、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/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
跨域网关
公有云跨域互通场景下，探测报文生命周期如下：
本地域 —> 地域 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基づいて、指定したユーザーのネットワーク気象監視を構築します。