网络通信 频道

SDN之道Juniper Contrail深入解析

  编者按:本文系SDN私享汇在线技术分享系列,我们希望通过SDNLAB提供的平台传播知识,传递价值,欢迎加入我们的行列。

  --------------------------------------------------------------------------------------------------

  分享嘉宾:马绍文,Juniper亚太区产品总监。领导亚太区产品经理团队管理Routing/Switching/Security/Cloud产品线。跟欧美亚太主流OTT/SP架构师团队共同工作多年,积极参与业界SDN/NFV的发展,多次Apricot和其他亚太盛会上分享SDN/NFV等的主题演讲。最近的关注重点包括:Telco Cloud, MSDC, Automation和OTT 网络架构。对最新热门技术,EVPN/VXLAN,Segment Routing,Contrail/NorthStar SDN控制器, Appformix云运营优化软件均有独到见解。

  --------------------------------------------------------------------------------------------------

  1.介绍

  云计算为了适应业务/APP 的快速开发和部署,会把网络分为两层:Overlay和Underlay网络。对于Underlay网络适用于传统的物理网络的自动化部署,提供基本的物理连通性,不需要经常变化网络拓扑等。对于Overlay网络来说,需要经常性的网络变更以适用于DevOps的要求,必须要引入SDN来控制Overlay网络,对于Overlay网络来说,也分为纯软件的(比如基于 vRouter)方案和软硬混合的方案(比如基于 TOR Switch上的EVPN+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, 或者EVPN/L3VPN等虚拟化技术,构造一层Overlay的网络,提供更灵活的连接性。 更方便的对接Openstack, K8S等云平台。Overlay控制器一般有一个大脑,来构造网络而不仅仅关注创建Tunnel。

  b.基于硬件的Overlay:控制器直接控制交换机路由器,建立一张VXLAN,或者EVPN网络。比如国内某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实现L3VPN/EVPN,实现基于软件的Overlay。

  d.最近Contrail 4.0版本,扩展Fabric Management模块来实现数据中心交换机的完全管理,通过Netconf/EVPN来管理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 EVPN/L3VPN 网络。

  业界最成功的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网络,虚拟多个不同的VPN,把VM/Dockers 映射到不同的虚拟网络。每个VMM可以提供 Load balance/DDos/ACL/VPN 能力。

  2.2 Contrail架构深入解析

  Contrail SDN控制器实现跟Google仙女座(Andromeda)同样的功能。Contrail基本设计思想是:把每个数据中心服务器虚拟化出来一vRouter, 通过vRouter来实现类似EVPN/L3VPN功能。多个VM/Docker会连接到这个vRouter的不同的Tenent VRF。同时vRouter之间采用GRE/UDP/VXLAN做外层隧道, 采用内层标签来标识不同的 VRF。vRouter相当于传统L3VPN和EVPN的一个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.生成L3VPN/EVPN转发表,控制器知道现存的多个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建立等工作。相当于传统VPN的RR。

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

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

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

  接下来介绍 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提出了L3VPN 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。可以提供 EVPN/L3VPN,还有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。

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

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

  前面提到有了Contrail,DC GW和TOR可以自动通过Contrail 部署,现在版本支持Netconf来配置L3VPN/EVPN,并且支持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,实现完整的VPN功能。我们的很多客户已经采用了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和企业客户介绍

  Juniper Contrail 客户大致分三类,企业私有云,运营商电信云,还有 SaaS/IaaS。其中运营商Telco Cloud的应用比如AT&T, DT等等,还有 NTT/Orange 采用Juniper的SDWAN/vCPE解决方案。

  3.1 Contrail电信云解决方案

  运营商转型的一个重点是要实现Telco Cloud,运营商的云化。

  从上图可以看出,运营商网络的Time To Service部署,Operation开销和 Operation复杂性无法跟Cloud Provider相比。

  传统运营商建网思路是以连接性为目的,买路由器,传输设备,提供管道,连通性。网络架构基 本不具备智能。

  为了应对新业务的出现,很多业界Tier1 SP转变思路实现以超小(Micro),Ultra Low Latency数据中心为网络建设的重点。比如为应对 VR/Health Care/自动驾驶等业务的低延时,大数据量应用(自动驾驶汽车需要视频识别,可能每秒钟产生1Gbps的流量),必须要建设全分布式,超小型数据中心更加靠近终端用户。比如在北京的很多街道要部署微小的数据中心以指导自动驾驶汽车。

  Telco Cloud 架构,把分布式的端局(CO)变成数据中心,可以支持虚拟化,网络分片等应用。同时运营商天然有足够的分布式端局CO资源提供 Telco Cloud的机房设施。把传统端局改造为大中小型数据中心,把网络引入智能,能够使得运营商提供跟OTT一样的甚至更好服务IOT/5G的最新应用的云平台。

  Telco Cloud的一个重点就是如何管理全分布式的数据中心,很多Tier1 US/EMEA客户采用我们Juniper的Contrail来部署VNF 实现网络虚拟化。比如Telco Cloud里面实现vPGW,vSGW,vFW,vOLT 等等。

  这是一个vEPC Telco Cloud实例。

  3.2 Contrail私有云解决方案

  首先介绍一下一个有名的英雄联盟LoL游戏公司。2011年被腾讯收入旗下,总交易金额16.79亿元人民币。2016 年营收超过10亿美金。同时每天在线玩家超过3000万人,同时峰值用户超过750万人。

  RIOT游戏公司采用很多新技术,2017 年一月,他们详细介绍了采用 Contrail和Docker来自动化部署北美、欧洲和亚太三个大型数据中心。

  为了在私有云和AWS公有云还有第三方的Partner(腾讯/Garena)网络架构上共同开发游戏,他们自主开发了rCluster编排器,再加上Contrail虚拟网络和Docker助力,极大方便了程序员软件开发。并且集成了防止DDoS攻击的Containerized网络功能。

  详细信息请参考:https://engineering.riotgames.com/news/running-online-services-riot-part-iii

  案例部分最后分享一个商用SDN控制器的排名。

  虽然这个排行榜把大中小型客户,和Underlay/Overlay网络SDN控制器揉在了一起,也可以看出来 Contrail 在市场上的领先地位。

  4.总结

  最后介绍一下Contrail的愿景,Contrail首先聚焦在连通性,通过 EVPN/L3VPN来提供CPE,数据中心虚拟化,Telco Cloud 5G MEC CO,并且支持 Public Cloud Security Connection,提供 Massive IOT 设备接入。

  然后聚焦提升vRouter 的安全性,包括L4和Micro Service隔离的安全性等等。

  最后提供电信云,私有云,公有云统一的管理界面,统一的运营界面,统一的大数据分析界面。 连接公有云,私有云和混合云的 Multi-Cloud策略。

  最早SDN起源于数据中心的OpenFlow,目标是通过动态配置管理上千台 TOR/Server,建立连通性。数据中心基于简单拓扑,物理冗余性,交换机功能简单,网络超配,SDN Controller不大需要关心网络资源,流量状况。Automation(自动化)成为SDN 控制器的最主要特性。

  随着SDN影响越来越大,SDWAN, WAN SDN, Cloud SDN需要SDN/NFV控制器来更好的理解流量和资源分配状况,这时候需要通过Openconfig/gRPC搜集 Telemetry信息,上送控制器。原始的信息很难被控制器理解,越来越多厂家在SDN控制器之上加入机器学习,人工智能部分,更好的指导控制器进行网络自动化。

  举个例子,Juniper最新Appformix解决方案,用来优化Openstack云部署环境,采用了机器学习,当部署新的VM/Docker时,Appformix注意到,尽管某个Server的CPU负载很低(只有 20%)但是那些L3 Cache资源已经不足,Appformix会进行迁移,把现有的VM 移到L3 Cache 充足 Server。当有个新的 VM/Docker部署要求时,最简单的就是给他分配一个新的Server,但是新的VM/Docker也许和现有的一个VM有很多交互,share相同的资源,如果把新的 VM/Docker部署在现有的Server上,而不是每次都分配新的Server,可能整个应用更流畅。

  从上面的例子可以看出来,现有的SDN控制器仅仅是算是机械手,引入人工智能,引入Telemetry更好的理解网络。形成一个闭环的SDN自愈合控制系统。

  从前面的介绍可知:

  •通过 API/Netconf/OpenFlow来做自动化运维仅仅是SDN的初级阶段。

  •发展为管理现有网络设备为主的Underlay SDN架构,一般采用Hybrid SDN在现有设备上构建不同的隧道来做流量工程调度。

  •Overlay SDN控制器,在Fabric IP可达基础之上,Overlay SDN控制器模拟VPN RR功能,引入网络智能大脑,创造了一层虚拟的网络,更灵活的部署云计算业务,从SD-WAN到数据中心云化,引领了SDN发展的浪潮。

  •Juniper Contrail从Overlay SDN入手,逐渐增加Fabric Management 的部分,引领了业界SDN 发展的潮流。

  Juniper的网络远景是打造『自驱动的网络架构』-“Self-Driving Network”

  5.Acronyms

  Q&A

  Q1:如果是一万台server vrouter是full mesh么?如果是 怎么解决这么对连接

  A1:每个server里面的vRouter只跟Controller通讯交换控制信息。转发信息如果属于同一个VPN,vRouter可以动态的发送MPLSoGRE, MPLSoUDP,VXLAN报文

  Q2:怎么从传统网络向Sdn网络迁移,或者说向Sdn网络过渡,我们应该怎么准备

  A2:传统网络向SDN迁移,要考虑为什么,如果是要云化,公有云,私有云,IaaS/PaaS等等,需要考虑Overlay SDN控制器,这时候一般是在server或者TOR上创建Overlay网络。

  如果仅仅做流量工程,类似Google B4,Microsoft SWAN,建议考虑Juniper North Star这种全网视角,创建tunnel来调优流量的Underlay SDN控制器。如果SDWAN,企业网接入,也需要Overlay SDN

  Q3:最直接的,我的企业现在业务变化量不大,那么我向Sdn网络迁移的收益在哪里?

  A:这个问题,可能跟企业目标有关,如果不想提供云服务,也不需要优化网络路径,一般Automation,就能解决很大问题,我们看很多运营商,比如Telstra他们对网络的Audit,自动运维等很有需求。

  Q4:Q:在有限的underlay网络下,overlay网络的qos如何保证?还是传统的diffserv么?大规模网络的admission control 如何实现?

  A4:在Overlay网络中,现在数据中心中部署居多,很少跨越广域网,所以QOS要求不高,但是Telco Cloud要跨越广域网,多个数据中心的时候,需要vRouter支持QoS,juniper Contrail vRouter可以支持MPLSoUDP等的QoS功能。

  Q5:All Juniper device can be controlled by the Contrail controller? or only some Juniper device can be managed by controller?

  A5:现在juniper的contrail Focus在vRouter上,ToR switch QFX5000系列也支持OVSDB的配置管理。MX/vMX支持自动GW部署,比如自动MPLSoUDP tunnel等。我们将很快release Fabric Management,可以管理几乎全部的juniper router/switch..甚至第三方的设备。

  Q6:OpenContrail跟northstar有何区别?刚刚的分享发现Contrail把2层也管了

  A6:Contrail是overlay SDN,Northstar是定位hybrid underlay SDN

  Q7:部署openstack with opencontrail的时候, vrouter是怎么部署的?先用kvm启动 还是用openstack的命令启动的?

  A7:nova创建虚机,neutron创建端口,nova scheduler去找一台physical server,然后通知vrouter agent,启动KVM。很复杂的一个orchestrator流程

  Q8:现在我们的Sdn解决方案国内有没有落地的案例 比如金融行业或者能源行业 ?国外又没有金融和能源行业的案例?

  A8:我们在金融行业,有一些证券交易所,还有一些银行保险公司的案例

  Q9:“原始的信息很难被控制器理解,越来越多厂家在SDN控制器之上加入机器学习,人工智能部分,更好的指导控制器进行网络自动化。”这里引入的机器学习or人工智能部分,是指对策略做的预判吗。打个比方,SD-WAN和DCI的TE在这里controller怎么去对接的

  A9:SDWAN解决的问题,是多个出口,类似于Google Espresso Peering的解决方案,因为是出去internet的流量,比较容易控制,一般基于AppQoS就能解决的很好。前面说的是Egress Peering,另一类问题,ingress peering进到运营商或企业网的流量,需要根据流量情况来预判断,同时控制手段单一,比如仅仅能BGP Prepend AS,这时候需要ML/AI SD-WAN和DCI的对接,这种端到端的保证,只能通过AppQoS/Probe去多选一

  Q10:vRouter的东西向流量怎么采集到分析集群,有什么制约?

  A10:Contrail vRouter做流量镜像非常容易,我们在contrail service里面配置端口的镜像,支持ACL镜像,并且通过MPLSoUDP发送到采集的VM。

  Q11:juniper南向会坚持使用ovsdb,还是会逐步加入对netconf等其他的支持;

  A11:我们还会支持OVSDB,也会增加很多netconf支持。

  Q12:juniper有没有企业用户对边缘CPE设备的低成本解决方案,毕竟很多大型企业的边缘节点往往峰值流量也小于10m,不可能动辄买几万元的设备去部署SDN

  A12:我们有SDWAN解决方案,之前方案有些欠缺,最新的版本有了很大的改进,比如支持APPQoS等。。请联系销售团队进行最新版本的demo

  Q13:求问contrail用的什么协议对网络telemetry的

  A13:现在Contrail支持netflow,我们正在集成Appformix功能来采集Telemtry信息。很快就会支持。

  Q14:这里一直强调的“Overlay”我是不是可以理解为,Contrail和“数据平面”交互区别于传统的:1. 通讯方式是XMPP协议,传统的是ovsdb之类的,2. 通讯内容的是“路由表”(或者是通过BGP传递的VxLAN转发表),传统的是流表(Flow)。所以这是不是Contrail区别于其他Controller的关键?

  A14:选择XMPP而不是BGP的原因我介绍过,XMPP是gtalk选用的大规模通讯机制,XMPP里面携带BGP NLRI就是这种折中,contrail controller跟vrouter agent之间通过XMPP来传递BGP路由表信息, vrouter agent下发转发表到vrouter forwarder,Contrail控制器相当于一个路由反射器,有全网的拓扑大脑。这是一个contrail区别于其他SDN控制器的主要原因。

  Q15:和Cisco的APIC相比 Juniper的方案有什么优势?

  A15:思科的是hardware overlay方式,juniper contrail可以支持Software和Hardware Overlay

  Q16:对于sdwan场景,目前telemetry只在CPE上吧,采集的流级信息不是network-wide的,是否足够支撑故障诊断,contrail在这方面是怎么考虑的

  A16:SDWAN场景,Telemetry可以在CPE上采集端到端SLA,然后做路径选择。。可以通过APP SLA monitor来实现

0
相关文章