原标题：揭秘Google的SDN广域网

深度解读：云网融合的多云网络

作者：马绍文 丨首发于SDNLAB

随着AR 相机 和社交VR（SocialVR）的等新应用的到来，互联网的流量还会持续高速增长。大部分的流量增长没有体现在运营商SP 的网络中，而是主要集中在OTT 网络中。

OTT 的数据中心/WAN/PoP流量快速增长，带来OTT 网络架构的快速迭代和升级。传统的设备形态和网管工具无法适应流量和业务的快速发展。OTT 纷纷采用自研设备，引入SDN 来管理全球骨干网。

Google 的SDN 网络大概可以分为四个主要部分：

②数据中心 Jupiter（木星）

Google 的广域网实际上分为B4（DCI）数据中心互联和B2 骨干网。如下图所示。

B4 作为Google全球数据中心互联采用自研交换机设备，运行纯IP 网络。B2 连接数据中心和POP 点，采用厂家路由器设备，并且运行MPLS RSVP-TE 进行流量工程调节，还没有进行SDN 改造。

简单的说B2负责数据中心到用户的流量转发（Machine to User），B4 负责数据中心到数据中心的流量转发（Machine to Machine）。

B4 的流量增长率远远高于B2，容量每9 个月就要翻倍（Double），5 年时间，流量增长了100倍。没有商用单机路由器可以支持这么大容量的业务增长。所以Google 决定利用交换机芯片来自定义自己的『超级核心路由器』

如下图所示，红色图标中的数字，说明在位置附近有多少个站点（sites）

业界对于B4 的理解仅仅停留在两篇晦涩的白皮书上。本文从一个架构师的视角试图解析B4 的自研设备，网络架构，SDN 控制和部署中碰到的难题。对于Google 如何构建云计算平台GCP 请参考作者的另一篇关于混合云/多云网络的文章：深度解读：云网融合的多云网络。对于 OTT 网络架构的深入理解，基本上来源于 SIGCOM 的白皮书和一些公开视频和讨论。

为了应对数据中心流量的快速增长，Google 2009 年在数据中心部署了第四代机框式 Saturn（土 星）交换机，可以在半高机箱中支持 288x10GE 接口，单槽 240Gbps， 一个机架支持

有了新的 CLOS 路由器，Google 的 WAN 是如何构建的？首先你需要设计：

● 从 DC Cluster 搜集流量发送请求，发多少流量，到哪个目的地址。

● BwE 的设计原则是，路由器/交换机不是一个对 IP 报文 per packet 做策略、带宽预留控制的理想节点，尤其 B4 采用小 buffer 交换芯片，很难做到海量数据流量 QoS 控制。所以 BwE 设计流量控制在 Host 层次，并且在 B4 提供层次化 TE 管道控制。

● BwE 修改了 Linux 网络协议栈，任何 Container 发出的流量，都可以被识别，每 5 秒钟间 隔，Host 汇报流量情况。并且汇聚 Task/Job/User/Cluster 的流量要求，最后汇聚成 SiteSite 的流量请求。并且能够根据历史流量数据，进行带宽预留的预测。如下图所示：

在 Google 数据中心里，有大量自研设备，包括 Leaf/Spine 交换机，还有前面提到的 CLOS Fabric，如何感知网络拓扑，构建 SPF 最短路径树？

Google 的一个工程师基于 ISIS 协议，创造一个新的 IGP 协议 Firepath 路由协议来计算路径。

首先，把路由控制平面集中到 Firepath Master 服务器上，并且在服务器之间跑专门的 FMRP 做备 份。对于每个 Leaf/Spine 交换机，他们不需要互相建立 IGP 邻居去发现拓扑。而是仅仅跟 Master 建立邻居关系，上报拓扑信息，拿到 master 下发的路由表。

新的 SDN 控制器能拿到网络的 topo 信息，就可以计算出最优路径。不需要任何 OSPF/ISIS 或者 BGP 协议。关于新的 SDN 路由协议，我们后续再做详细分析。

选择 Tunnel 技术做流量调度

OFC 利用 TED 来下发沿路的 tunnel 转发表，OFC 等待沿路的每个路由器给出回应（成功/失败）。

● 比如对于目的地址是