SDN私享汇（十五）：SDN之道JuniperContrail深入解析

1.介绍

云计算为了适应业务/APP 的快速开发和部署，会把网络分为两层：Overlay和Underlay网络。对于Underlay网络适用于传统的物理网络的自动化部署，提供基本的物理连通性，不需要经常变化网络拓扑等。对于Overlay网络来说，需要经常性的网络变更以适用于DevOps的要求，必须要引入SDN来控制Overlay网络，对于Overlay网络来说，也分为纯软件的（比如基于 vRouter）方案和软硬混合的方案（比如基于 TOR Switch上的E***+VxLAN）方案。

对应于Juniper的产品策略，Juniper除了坚持自研芯片，引领数据中心和核心边缘路由器的发展，帮助客户构建最强的 Underlay网络。同时发力NFV在网络的三个不同位置推动虚拟化：1) CPE演进，着力在SDWAN推出CSO（Contrail Service Orchestration）来颠覆企业网接入。2)Edge,推进Telco Cloud弹性云，在CORD小微数据中心里面推出MEC, vBNG, vPEC 适应无线边缘计算要求。 3)在云数据中心，采用多种VNF功能，例如DPI，FW等功能。

对于Underlay/Overlay网络，Juniper分别推出Northstar（北极星）和Contrail（飞机云，飞机划过天空带来的云）来进行Underlay和Overlay的SDN控制。

对于SDN（Software Defined Network）有很多不同的理解。大体上从最早的网管系统，自动化部署，监测网络状态，演变成：

A.通过软件API来直接控制路由器，比如ZTP自动化部署和基于Syslog/Event的变化而改变网络配置脚本Script等。

B.Underlay SDN

a.传统的SDN 理念，简化设备功能支持，引入集中式SDN控制器。交换机上仅仅支持OpenFlow Agent，统一通过 OpenFlow 控制器去下发转发表项，设备商在路由器/交换机上甚至可以不用实现动态路由协议。适合新建的DC等网络。

b.Hybrid（融合）SDN，保留设备上的大部分协议，同时引入全网 SDN 控制器。通过OpenFlow/PCEP/BGP/Segment Routing等等协议来指导设备进行路径规划。适合在现有网络中逐渐演进成SDN，充分利用现有设备能力。比如 NorthStar/WAE/ONOS/ODL 等等。

C.Overlay SDN

a.在 IP/MPLS Fabric Underlay基础的连通性之上，通过VXLAN， 或者E***/L3***等虚拟化技术，构造一层Overlay的网络，提供更灵活的连接性。 更方便的对接Openstack, K8S等云平台。Overlay控制器一般有一个大脑，来构造网络而不仅仅关注创建Tunnel。

b.基于硬件的Overlay：控制器直接控制交换机路由器，建立一张VXLAN，或者E***网络。比如国内某OTT尝试通过OpenFlow 驱动VXLAN来建立数据中心的Overlay，Cisco APIC也是把用户应用映射到不同的VXLAN Tunnel，并且扩展 VXLAN header 来实现应用QOS等功能。

c.基于软件的Overlay：控制器不控制物理设备，而是控制Hypervisor层面的vRouter/OvS等设备。比如VMware的NSX，通过 OVSDB在OVS上实现VXLAN隧道，Nuage通过OpenFlow来控制OVS。Contrail通过 XMPP（BGP）来控制vRouter实现L3***/E***，实现基于软件的Overlay。

d.最近Contrail 4.0版本，扩展Fabric Management模块来实现数据中心交换机的完全管理，通过Netconf/E***来管理Spine/Leaf交换机，实现基于硬件的Overlay控制。Contrail率先支持基于软件和硬件的Overlay SDN。

我们把业界常见的SDN控制器大致分为三类，可能不是很准确，很多控制器有新的进展：

1.关注路由器WAN的控制器

a.控制100+路由器节点

b.采用标准路由协议BGP/PCEP/Segment Routing etc

2.关注数据中心交换机的控制器

a.控制 1000+路由器节点

b.在两个TOR 交换机之间创建VTEP tunnel

c.采用OpenFlow等方式

3.关注Cloud的控制器

a.控制 10，000+虚拟路由器/虚拟交换机，vRouter/vSwitch

b.不再主要管理路由器/交换机。在hypervisor层面管控（vRouter/OVS）采用BGP/XMPP/OVSDB，创建vPE E***/L3*** 网络。

业界最成功的SDN企业就是Google，采用四个不同的SDN控制器来优化网络。

1)B4 DCI数据中心广域网互联控制器。

2)Jupiter数据中心Fabric 控制器。

3)Andromeda虚拟化Overlay 控制器。

4)Espresso基于BGP的广域网Peering控制器 。

Google有强大的研发实力，可以定制化云主机VMM管理软件，定制化DCI交换机，定制化路由协议。但是Google的云计算网络部分不适用于第二家互联网公司，也不适用于运营商和企业客户。Juniper作为厂商来讲，不仅能够提供路由器/交换机/安全产品，同时我们提供两个SDN控制器来帮助管理 Overlay(Contrail)和 Underlay（North Star）网络。

对应Google的四个控制器（DC/Host/WAN/Peering）Juniper也有类似的控制器。不需要更改网络的Host/Switch/Routing Protocol,也能提供类似的功能。比如

• Andromeda---Contrail

• Jupiter--- Contrail/Network Director

• B4--- North Star

• Espresso--- North Star

以Google B4为例，这是个典型的 Hybrid（混合）型SDN，Google自己设计了新的B4控制器，部署在每个site的Server Cluster 上，运行所有的路由协议。每个switch上运行OpenFlow Agent 来补充转发表，提供更好的负载均衡多路径。使得全球 12个站点之间的链路利用率可以达到98%+。

微软SWAN广域网DCI控制器也是一个典型的Hybrid SDN，从最早的静态单层 MPLS Label构造的端到端隧道，到最新的基于BGP-TE SR的全球DCI互联解决方案。可以实现95%的跨数据中心链路利用率。

Google B4/Microsoft SWAN非常类似Juniper的North Star控制器。详细设计会另找时间给大家介绍。

2.Contrail Overlay SDN控制器架构

2.1 SDN演进史

最早采用Openflopw的SDN控制器有以下缺点：

1. 每个flow的第一个packet上送到控制器来识别。

2. 控制器需要被动的在路径上的每台 switch 来下发转发表项。

3. 在中间物理设备上保留了太多的Per Tenant状态（没有 Overlay 的状态隔离），交换机保留太多Flow静态信息，并且要支持OpenFlow，需要全网整体硬件升级。

4. 最早 Hop-by-Hop OpenFlow解决方案，整个网络类似一个大的静态路由协议构造的网络，非常原始。导致高Latency，低扩展性，网络没有很好的鲁棒性。

Contrail在设计之初就采用了不同的技术路线，采用Overlay理念作为架构设计的关键：

1. 报文不需要上送控制器，极大减轻了控制器的压力。

2. 控制器主动下发Virtual Overlay vSwitch/vRouter。

3. 依靠现有的协议来建立IP Fabric的连通性。Underlay拓扑变化不会影响Overlay。

4. Fabric不会保留任何Overlay Per-Tenant状态信息。

5. 低时延，高扩展性，非常鲁棒的系统设计。 针对三种不同的SDN控制器，我们先讲讲最重要的Cloud控制器。

Google采用仙女座（Andromeda）控制器来进行网络虚拟化，管理虚机和 Docker。在数据中心的每一个Server上创建一个虚拟的 VMM（虚机管理系统），通过GRE来构造Overlay网络，虚拟多个不同的***，把VM/Dockers 映射到不同的虚拟网络。每个VMM可以提供 Load balance/DDos/ACL/*** 能力。

2.2 Contrail架构深入解析

Contrail SDN控制器实现跟Google仙女座（Andromeda）同样的功能。Contrail基本设计思想是：把每个数据中心服务器虚拟化出来一vRouter, 通过vRouter来实现类似E***/L3***功能。多个VM/Docker会连接到这个vRouter的不同的Tenent VRF。同时vRouter之间采用GRE/UDP/VXLAN做外层隧道, 采用内层标签来标识不同的 VRF。vRouter相当于传统L3***和E***的一个vPE 功能。vPE用户侧不再接入CE设备，而是为VM/Docker提供连接性。

通过 Orchestrator在Server上部署一个VM或者Docker：

1.首先给 VM/Docker POD分配IP地址，DNS 等等信息。在vRouter上创建 VRF/VSI， RT/RD等信息，上送回传到Contrail控制器。vRouter之间不需要协议通讯，vRouter仅仅跟Contrail 控制器进行控制平面的通信。

2.生成L3***/E***转发表，控制器知道现存的多个vRouter可能要跟新创建的vRouter共享相同的VRF/VSI，并且需要互相通讯，就通过XMPP来下发转发表信息（BGP NLRI内嵌到XMPP消息里）到另一台服务器上vRouter。vRouter之间仅仅建立转发平面的动态隧道。这样Server之间的M/Dockers 就可以通讯了。

3.控制器通过BGP/Netconf来通知GW Router来自动发布VM/Docker的IP prefix。这样Openstack/vCenter创建的VM/Docker就可以被外界来使用了。

简单的来讲，如果客户有一万台Server，部署了Contrail之后：

1.Contrail控制器相当于传统的路由器控制平面，承担计算Overlay拓扑，数据通道Tunnel建立等工作。相当于传统***的RR。

2.数据中心的Leaf/Spine交换机提供IP Clos无阻塞交换，相当于一个虚拟的交换矩阵，为控制器和vRouter之间提供背板交换。

3.vRouter/vSwitch跟Controller建立控制关系，vRouter之间建立数据 tunnel。每个vRouter相当于传统路由器的一个板卡。

4.部署Contrail SDN控制器之后，数据中心服务器里的很多vRouter一起组成了巨大的虚拟路由器系统(Network as a Router)。为数以万计的虚机/Dockers提供多租户隔离的*** 网络连通。

接下来介绍 Contrail 网络服务。

•首先Contrail可以支持非常多的Orchestrator ，包括 Openstack, Kubernets, Marathon/Mesos, VMware vCenter, Amdocs,并且通过 Restful API支持很多定制化的Orchestrator，最近还支持AWS/GCP云服务等等。

•网络部分，Network 业务可以支持，L2/L3, IP Addressing, QOS, FW, Sec, LB, SVC Ch. Router Packet monitor, 实时分析等。

•对于设备控制：Contrail可以支持Juniper自身的交换机，也可以支持第三方的支持BGP/Netconf或者OVSDB的交换机。

•转发器Forwarder：可以支持 ESXI/KVM，Container，VPC GW等vRouter和Router/TOR的BMS。

Orchestrator可以通过RestAPI来自动化部署Contrail，大部分时间都可能不需要 Contrail GUI。对于TOR和BMS服务，Contrail支持OVSDB在TOR 上部署VXLAN。Contrail控制器也可以通过BGP/Netconf去控制MX GW router。

针对XMPP协议通讯，Juniper提出了L3*** End-System draft，来实现从 RS/Controller下发BGP NRLI的转发表信息。比如这张图就可以看到 203.0.113.42/32 地址，分配了标签 10000，tunnel可选UDP/GRE,下一跳是192.0.2.1。基本上涵盖了一个BGP Prefix的所有的NRLI信息。

2.3 Contrail跟OpenStack的结合

典型的OpenStack驱动Contrail Network流程，可以看到通过Contrail WebUI支持Neutron Plugin来取代缺省的Compute Node里面的OVS。

vRouter在Hypervisor内核里面取代Linux Bridge或者OVS。可以提供 E***/L3***，还有Security Policy，NAT，Multicast, Mirroring, LB等功能。不需要Service Node来做L2/L3GW和routing功能。一个 Compute Node 里面可能有多个VRF表，每个VRF表可能连接一个或多个VM/Dockers。

对于Compute Node转发详情请参考下面的两张图：

VM会通过ARP找到VRF的Default GW，在VRF里面可以学习到对端的 Prefix，在两个Server之间跑MPLSoGRE/MPLSoUDP/VXLAN。

接下来请看一个实际的转发案例。如果你在Compute1上创建了VM-A，在另一台Compute2上创建VM-B。Contrail Control Node收到从Compute1上的vRouter Agent发过来的NRLI XMPP 信息,转发给相应的有通讯要求的另外一个Compute2，通过vRouter Agent来program VRF转发表。生成到 10.1.1.1 的路由表项。比如下一跳Server IP地址是 70.10.10.1，并且携带标签 39。

VM-B就使用MPLSoGRE隧道，找到Compute1，Compute1根据标签39来找到 VRF，然后查路由表转发给相应的VM-A。

相应的，你也可以采用E***来实现两个VM/Docker的互联。根据Type2/Type5 Message(XMPP)生成的MAC地址表。

通过Contrail WebUI可以查看路由转发表，上面部分是完整的Control Node的转发表，下半部分是其中的一个vRouter的转发表。

前面提到有了Contrail，DC GW和TOR可以自动通过Contrail 部署，现在版本支持Netconf来配置L3***/E***，并且支持OVSDB来配置TOR Switch（Juniper 或第三方，时间关系不详述）。

典型的配置请参考如上图，注意MX支持动态的MPLSoGRE/MPLSoUDP隧道建立方式。

2.4 Contrail进阶功能

Contrail能够支持Overlay/Underlay相关分析。物理设备拓扑可以通过 SNMP和LLDP发现。虚拟设备拓扑通过Openstack集成。

对于Underlay Path可以通过sFlow或者IPFIX来发现。下半部分可以看到根据每个flow可以映射到相应的Underlay。

Contrail vRouter上可以定义L4 Policy,可以允许/禁止某些主机，某些 App进行通讯。对于L7的业务链也可以支持。

有了Contrail Cloud SDN控制器，也非常容易做NFV的业务编排（Services Chaining），我们给每个VNF的接口分配一个唯一的MPLS标签。如果要访问不同的物理或者虚拟化的VNF，只要找到对端的IP地址，并且携带这个MPLS标签，数据流量就会很容易的按照业务编排在不同的VM和 VNF之间实现业务链的编排。最近我们在讨论基于Segment Routing的业务编排。

Contrail还支持全部的性能增强模式。包括DPDK,SRIOV甚至还支持Smart NIC。

比如跟Affirmed Network和Netronome联合的解决方案中可以看到，我们可以把vRouter的转发部分下放到 Netronome，可以实现40G甚至200G的线速转发，同时释放之前用于转发的vCPU资源以支持更大业务带宽。

前面讲到的部分都是Contrail支持vRouter的转发，最近我们会支持 Contrail通过Device Manager来扩展支持自动配置Leaf/Spine交换机，还增加支持AWS/GCP的vRouter GW实现Hybrid Cloud统一策略，统一网络配置。

最近，Container部署是一个比较热门的话题。Contrail 4.0 所有控制器部分完全 Containerized，更方便于客户的快速部署。

Contrail有很多业务创新，比如最早支持Kubernets, BGPaaService等等。还拿 Google 举个例子。Google网络中大部分MicroService是用 Container部署的，很少有VM的应用。Google在一篇文章里提到，每个用户开始一个浏览器访问Google搜索，Google的后台会有70 个micro-service。每个星期在Google全球数据中心里，大概有 2 Billion 的 Container创建和销毁。Google开发了Kubernets去部署全球的 Container。但是Kubernets的开发者偏向APP应用层，在网络层面使用了 简单的Proxy来做Container的互联，太适用于大规模的Container部署。

Contrail在2014年支持Kubernets，适用我们自己的Contrail vRouter 替代Kubernets里面的Proxy，实现完整的***功能。我们的很多客户已经采用了Kubernets+Contrail来实现，比如LITHIUM用来实现SaaS，提供VM/Container/AWS Hybrid Cloud之间的资源自动调配。相关视频客户已经在2015年7月Post在Youtube上了。还有另一个客户TCP Cloud也用Kubernets+Contrail实现Smart City/IOT，去检测停车场/街灯的各类信息（temp, CO2, humidity, doppler）并且连接标准树莓Pi的IOT GW。

3.Telco Cloud和企业客户介绍

4.总结