SDN实战团分享(二十八):Cisco ACI技术解析

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

分享嘉宾
--------------------------------------------------------------------------------------------------
分享介绍:张晨:目前就读于北京邮电大学FNL实验室,网络与交换国家重点实验室。目前主要研究方向:软件定义网络,网络虚拟化,云数据中心网络。目前任职于Brocade。
--------------------------------------------------------------------------------------------------
在网络厂商的圈子里,其实SDN早就不是什么新概念了。ForCES作为“SDN上古神兽”在2004年就有了第一版RFC,2006年Juniper向IETF提交NETCONF,希望能够对各厂家设备的CLI进行标准化,同时在远端通过开放API对网络进行自动化配置与管理,至于OpenFlow其实也早在2008年就被提出了,不过当时也没有在业界引起太大的波澜。2004年到2012上半年,面对初现“狼子野心”的SDN,Cisco可谓是镇定自若,策略上也没有采取过分的打压,毕竟作为网络厂商的“大哥大”对待新技术要表现出足够包容的姿态。当然,包容的前提是SDN一直是雷声大雨点小,Cisco的利益并没有受到任何实质性的侵害.

事后来看,当时的Cisco显然没有预料到SDN近10年蓄势后的爆发力,导火索就是2012年7月Vmware对Nicira的12.6亿美元的天价收购,这宣布SDN的商用方案正式进军数据中心。上一节中讨论过,对Nicira的收购失败绝对是Cisco始料未及的,于是Cisco开始秘密孵化SDN创业公司Insieme,并派出了Cisco技术扛把子MPLS中的MPL三人帮助打造Insieme的软硬件。2013年4月,Cisco领衔各大厂商成立SDN开源项目OpenDaylight,随即6月Cisco发布ONE战略,Chambers正式公开承认SDN的未来地位。

2013年8月Google发布了基于SDN的广域网解决方案B4,2013年10月前后Awazon放弃与Cisco近10亿美元的设备订单而选择基于SDN的数据中心白盒解决方案。世界上两家Top 5的高科技公司相继投向SDN,抛开技术上的原因不谈,这明显地为市场释放了SDN将加速落地的信号。Cisco再也没办法拖下去了,2013年11月初Cisco正式收购Insieme,并高调发布其数据中心SDN解决方案ACI(Application Centric Infrastructure,以应用为中心的基础设施),围绕Cisco自己的硬件打造SDN,正式宣布与完全基于软件的NSX开战。2014年4月,Cisco部分开源了ACI的南向协议OpFlex,向OpenFlow+白盒发起冲击。

自从ACI推出以来,业界围绕着NSX和ACI的讨论和比较就从来没有停止过。NSX骨子里是更为正宗的SDN学院派,NSX-MH更是将网络设备进行了彻底的开放。而ACI其实是打了SDN的擦边球,其整体方案仍然是围绕Cisco的硬件来展开的,因此有人说ACI算不得是SDN,而是一种HDN(Hardware Defined Networking)。不过从广义SDN的角度来看,ACI仍然开放出来了一定的网络可编程能力,因此笔者认为ACI仍然属于SDN,而且其技术上还是有很多有趣的地方,这一节我们就来对ACI的实现进行探讨。

(一)ACI架构

ACI的架构并不复杂,APIC(Application Policy Infrastructure Controller,应用策略和基础设施控制器)作为控制平面,向上通过GUI/CLI/REST API/Python Scripts向管理员提供配置、管理、策略下发的接口,向下通过OpFlex协议将策略推送给ACI Leaf/vLeaf设备中的PE(Policy Element)模块,PE模块会将策略转换成设备能够理解的配置并部署到设备中。注意,APIC上的策略都将生效于ACI网络的边缘,因此APIC只会向ACI Leaf/vLeaf推送策略,而并不会向ACI Spine推送策略。另外,ACI Leaf/vLeaf/Spine的转发都不受APIC控制。

为了方便后面介绍ACI的控制平面,这里对ACI使用的南向协议OpFlex进行简单的介绍。OpFlex基于声明式(declarative)的配置管理方式,相比于CLI/OVSDB/NETCONF这类命令式(imperative)的配置管理方式,OpFlex将策略实现的的复杂性从控制器中剥离,控制器只负责管理和推送策略,策略的实现交由转发设备来完成。这种声明式的配置管理方式,在一定程度上可以减轻控制平面的压力。OpFlex的通信模型如下所示,ER(Endpoint Registry)存储这工作负载(EP)的信息并根据PR中的策略将EP分类形成EPG(EndPoint Group),PR(Policy Registry)存储着业务策略,PE(Policy Element)负责监测EP并在转发设备本地执行策略,Observer负责监测转发设备的状态信息。PE分布在各个转发设备本地,而ER、PR和Observer则是逻辑上集中的。对于ACI来说,PE分布在各个ACI Leaf/vLeaf上,ER、PR和Observer则分布在APIC集群中。

OpFlex承载与RPC之上,提供了双向的通信能力,其上图中出现的信令如下表所示,OpFlex的全部信令及其具体格式请参考https://tools.ietf.org/html/draft-smith-opflex-03

信令 发起方 接收方 作用
Identity 任意 任意 握手消息
Policy Resolve(图中的Policy Resolution为老版本的名称) PE PR PE向PR请求策略,PR收到后回复Response
Policy Update PR PE 更新PE上已有的策略
Endpoint Declaration PE ER 宣告EP上线或者EP的状态变更
Endpoint Resolve(图中的Endpoint Request为老版本的名称) PE ER 请求EP在ER上的注册信息,ER收到后回复Response
Endpoint Policy Update ER PE 更新已有的EP业务策略
State Report PE Observer 上报PE上的fault/events/statistics

相比于NSX,ACI并没有设计单独的管理平面。不过实际上,与其将APIC称为控制平面,倒还不如称为管理平面来的贴切,因为OpFlex擅长的是对业务策略和设备的管理,却并不具备对转发设备的转发进行直接控制的能力。“以应用为中心”听起来很client-based,但实际上这是Cisco得以继续走封闭设备路线的幌子。不过,Cisco一再强调APIC不仅仅是Super Network Management System(虽然有点欲盖弥彰),那么我们倒不妨可以把APIC看作一套开放了GUI/CLI/REST API的数据中心OSS。

(二)APIC设计

为实现“以应用为中心”,最为关键的技术就是对应用策略的自动管理和部署。APIC使用了“承诺理论”来管理、部署这些应用策略。“承诺理论”是指控制平面只维护应用策略的状态,而不去真正执行策略,策略完全由转发设备来执行,如果转发设备执行失败将会导致应用策略的部署失败。ACI中“承诺理论”的执行依赖于POM(Policy Object Model,策略对象模型)的建立,ACI中基本的POM如下图所示,EPG(Endpoint Group)代表了一组具有相同通信约束的EP,同一个EPG内的EP间可以无障碍通信,不同EGP的EP间的通信规则由合约(Contract)来进行约束。一个应用可以由多个EPG和这些EPG彼此之间的Contract构成,它们共同形成一个应用策略(Application Network Profile)。EPG的分类规则非常灵活,管理员可以根据应用策略的需要来制定EPG的分类规则,如同一VLAN、同一VxLAN Segment、甚至同一DNS后缀,等等。Contract主要包括以下几种:入向/出现ACL,QoS,重定向和服务链。基于这些多样的EPG和Contract,ACI管理员可以通过CLI/GUI/REST API/Python Scripts制定丰富的ANP,APIC维护并分发这些ANP,ANP的执行由转发设备来完成。

APIC的POM中,除了通过EPG来对EP进行应用策略级别的分类外,还可以通过Bridge Domain/Network/Tenant来对EP进行L2/L3/租户的划分。Bridge Domain的概念类似于Vmware的VDS(Virtual Distributed Switch),逻辑上是一个二层的广播域。一个Network可以包含多个Bridge Domain,逻辑上是一个L3的网络。一个Tenant包括多个Network,逻辑上是一个ACI租户的网络。同一EPG下的EP必须属于同一个Bridge Domain,但是不同EPG间的EP可以根据Contract跨越Bridge Domain/Network/Tenant进行通信,也就是说ANP的制定逻辑上是不受任何局限的。

APIC向ACI Leaf/vLeaf推送应用策略的方式有三种:(1)策略预装,即所有的应用策略都由APIC预先推送给ACI Leaf/vLeaf,策略在设备本地即刻编译,编译后在datapath上生效。这类似于OpenFlow控制器以proactive方式预置流表。(2)策略触发式推送,即EP上线时Leaf/vLeaf会通过一条Endpoint Request向APIC请求相关的策略,APIC受到请求后将策略推送给ACI Leaf/vLeaf,策略在本地即刻编译,编译后在datapath上生效。这类似于OpenFlow控制器以reactive方式对PacketIn作出反应并编辑流表。(3)策略预推送,即所有的应用策略都由APIC预先推送给ACI Leaf/vLeaf,但是策略在设备本地不会立刻进行编译,而是等到EP上线时才会开始编译并生效。(1)的优点是APIC的实时开销几乎为零,缺点是设备上的ACL太多,(2)与(1)相反,优点是设备上不存没有用的ACL,但是APIC的实时开销太大,(3)介于前两者之间是一种折中的方案,也是ACI的默认模式。

除了管理、部署应用策略以外,APIC还需要对转发设备进行管理。APIC有以下8个主要的组件:

  • Policy Manager:管理、部署应用策略,作为PR和ER通过OpFlex协议与ACI转发设备中的PE进行交互
  • Topology Manager:通过LLDP维护ACI的物理网络拓扑,通过ISIS维护ACI的L2/L3逻辑拓扑。同时维护设备清单,包括序列号/资产号/port/linecard/switch/chasis等
  • Observer:监测APIC/ACI转发设备/协议/性能等,并提供告警和日志。作为Observer通过OpFlex协议与ACI转发设备中的PE进行交互
  • Boot Director:负责APIC/ACI转发设备的启动,自动发现,IPAM和固件升级
  • Appliance Director:负责APIC Cluster的建立
  • VMM Manager:与虚拟机管理程序(Vmware vCenter/Hype-V SCVMM/libvirt)交互,维护Hypervisor上的网络资源信息,如NIC/vNIC/VM names等,能够感知虚拟机迁移。会将相关信息告知Policy Manager
  • Event Manager:记录APIC/ACI转发设备发生的事件和故障
  • Appliance Element:监控上述组件的运行状态

上述组件所涉及的数据,包括策略和设备的状态信息是十分复杂的,为了能将这些数据有效地组织起来,APIC设计了一棵MIT(Management Information Tree)。无论是北向的REST API还是南向的OpFlex,都数据进行任何的操作都必须依据MIT上的路径,因此APIC是一种数据驱动的控制器架构。OpenDaylight的MD-SAL同样采取了类似的设计。

APIC的高可用建立在APIC Cluster的基础上。APIC间的自动发现依赖于Boot Director组件完成,APIC节点间通过Appliance Director组件维护集群的状态。至少需要3个节点才能形成APIC集群,集群可以根据ACI网络规模进行动态的扩容,集群中节点数上限为31个。不过实际上,由于APIC只做策略不做转发控制,因此即使所有的APIC节点全部挂掉,整个ACI网络的L2/L3转发是不会受到任何影响的。APIC Cluster间的MIT数据管理采用shard database实现,shard database技术将MIT上的一份数据复制成多份备份到不同的Cluster节点中,数据的读写必须发生在原始的节点上,原始节点再向该数据的备份节点进行同步,以保证数据的最终一致性。APIC中需要做shard的组件有4个:Policy Manager、Topology Manager、Observer和Boot Manager,它们的数据在APIC Cluster上都存有3个备份,随机地分布在各个Controller节点中。关于shard database的详细介绍,这里不做信息介绍,感兴趣的读者可自行查阅相关资料。

由于APIC Cluster间的通信以及APIC与ACI转发设备的通信都是通过IP完成的,而ACI网络中的IP连接是不受APIC控制的,因此APIC可采用In-Band的部署在ACI网络中,而且APIC集群不必位于同一机架下。出于商业考虑,Cisco将APIC打包在其UCS刀片服务器进行部署,装有APIC的服务器建议双归到两台冗余的TOR上(N9000 Leaf)。当APIC采用Out-of-Band部署时,应通过至少1G的Ethernet的管理端口与设备进行连接,以保证控制信道足够的带宽。

(三)ACI转发设备设计

这一小节之的标题之所以没有叫做“ACI数据平面设计”是因为ACI的转发设备本地仍然保留了大部分的转发控制逻辑,因此不同于常见意义上的“SDN数据平面”,同理上一小节的标题也没有叫做“ACI控制平面设计”,因为APIC实际上并不具备对ACI转发设备上转发逻辑的控制能力。

ACI转发设备构成的网络成为ACI Fabric,Fabric内部转发设备通过ISIS进行L3互联。ACI Fabric采用leaf-spine的物理拓扑,leaf与spine间建议采用物理全互联,不允许在leaf间以及spine间进行物理直连。Cisco专门为ACI Fabric拓展了其N系列的交换机——N9K,通常以N9300系列作为ACI Leaf,用于服务器/防火墙/路由器等设备的接入,以N9500系列作为ACI Spine,为ACI Leaf间的互联提供高速、无阻塞的连接。

ACI Leaf的软件设计上,基于Nexus OS进行了裁剪,并增加了PE模块来处理OpFlex协议并APIC推送下来的处理应用策略,ACI Leaf的OS有两种工作模式可选:Standalone模式用于兼容之前的Nexus Switch,Fabric模式用于ACI Fabric。ACI Leaf的硬件设计上,要求支持二层桥接(VLAN/VxLAN/NvGRE)和三层路由(OSPF/BGP),并能够基于原始帧的目的MAC或IP封装隧道,并能够在本地执行应用策略。

ACI Spine的软件设计上,并不要求支持OpFlex。ACI Spine的硬件设计上要求提供Fabric模块的热插拔、高密度的40G以太网端口,支持大规模的MAC/IP到VTEP IP间映射的database mapping,以及VxLAN Hardware Proxy。

ACI Fabric是基于VxLAN Overlay在租户网络上进行转发的。为了更好的支持应用策略的部署,Cisco拓展了标准的VxLAN Header形成了VxLAN-GBP(VxLAN Group Based Policy),标准VxLAN Header和VxLAN-GBP Header如下所示。Flags中有两个bit标记源EPG和目的EPG策略是否已经得到了执行,Source Group记录了源EPG的ID,VNI仍然是24bit,但是VNI指代的不再仅仅是标准VxLAN中的Segment ID了,而是根据情况可以指代ACI POM中的Bridge Domain/Network/Tenant。


VxLAN-GBP Overlay上的转发是ACI最核心的技术实现,在本质上体现了Cisco对于SDN的理解。有别于其它众多的SDN控制器直接操作FIB来控制Overlay的转发,APIC只关心应用的策略而并不关心VxLAN-GBP Overlay上的转发,VxLAN-GBP Overlay上的转发完全由ACI Fabric设备来实现。这里要掰开来细说了,也方便后面对于ACI转发过程的分析。

先来看ACI的东西向通信,东西向通信包括L2桥接与L3路由。

  • L2桥接依赖于MAC/VTEP映射关系的学习。一般而言,实现MAC/VTEP映射关系的学习有三种思路,一种是分布式的MAC自学习(标准VxLAN),另一种是由SDN控制器直接从CMS获取映射关系(OpenStack Neutron),第三种是转发设备自学习本地的MAC地址,然后将MAC地址告诉SDN控制器,控制器整理好MAC/VTEP的映射关系再将其反射给其他的转发设备(Vmware NSX)。而ACI对于MAC/VTEP自学习的实现方式均有别于上述,不过在思路上类似于第三种,由ACI Leaf自学习本地EP的MAC地址,但是ACI Leaf不会将该信息告知APIC,而是将该信息告诉给ACI Spine,ACI Spine通过硬件的mapping database存下该(Bridge Domain + MAC)/VTEP的映射关系。

多次反复后,ACI Spine中将存有全局的(Bridge Domain + MAC)/VTEP映射关系,这样就可以将ACI Spine看做是Overlay L2逻辑上的控制平面,而且全局的映射信息将分布在各个ACI Spine中互为备份,保证了控制平面的高可用性。

  • 同样,ACI实现Overlay L3路由也使用了上述L2桥接的控制机制,ACI Spine中的mapping database不仅仅有(Bridge Domain + MAC)/VTEP的映射关系,还有(Network + IP)/VTEP的映射关系,这样就可以将ACI Spine看做是Overlay L3逻辑上的控制平面,以集中地指导东西向L3流量在ACI Leaf上完成分布式路由。ACI Spine在这里扮演的角色,有点像LISP Map-Server。而且,根据(Network + IP)/VTEP的映射关系进行L2的转发也是没有任何问题的。由于采用了分布式路由,因此传统路由的单点瓶颈问题也得到了解决。

下面再来看ACI的南北向通信,南北向通信可分为与物理L2的对接,以及与Internet的L3对接。

  • 由于ACI Leaf支持将任意异构的L2(VLAN、标准VxLAN、NvGRE)连接到ACI VxLAN-GBP,因此与外界的L2互通在一定程度上也可以看做是ACI的东西向流量,物理Host可以部署在任意的ACI Leaf上。与物理VLAN的对接,ACI Leaf会完成VxLAN-GBP与VLAN间的转换,另外整个ACI Fabric将以Transparent Mode接入外界VLAN的STP环境,以避免产生环路,如下图所示。


与标准VxLAN/NvGRE的对接,ACI Leaf会完成VxLAN-GBP与标准VxLAN/NvGRE间的转换,因此ACI是可以作为NSX的Underlay进行部署的。

  • 由于ACI采用了分布式路由,因此与Internet的L3对接的关键就变成了如何将Internet路由分发给ACI Leaf。ACI对此的实现过程如下:在ACI Border Leaf与外界路由器间运行OSPF/BGP以学习Internet路由。经过路由重分布后,ACI Border Leaf将学习到的Internet路由通过MP-BGP告知ACI Spine,ACI Spine将作为BGP-RR通过MP-BGP将Internet路由反射给其它的ACI Leaf。整个过程同样没有APIC参与,完全由ACI的转发设备完成,这与NSX中VM对接Internet流量的实现是截然不同的。


由于采用了动态路由协议,因此这部分流量的高可用性可通过HSRP/VRRP以及ECMP等传统方式来实现,这里不做赘述。

当然,Cisco也支持通过Hypervisor中的vSwitch来将VM接入ACI Fabric。ACI支持的vSwitch主要有以下3种:Open vSwitch、Vmware VDS和Cisco AVS(Application Virtual Switch)。对于OVS,VM的发现是由OpenStack直接告知APIC的。而对于VDS,VM发现是通过在ACI Leaf和VDS之间运行扩展的LLDP协议来实现的,ACI Leaf发现VM后通过OpFlex通知APIC新的EP上线并请求应用策略的下发。下面分别给出了APIC/ACI Fabric和OVS/VDS的整个交互流程,表述的非常清晰这里就不再逐步骤解释了。


对于AVS,因为这是Cisco自家的产品,可以支持OpFlex,所以APIC可以通过OpFlex探测到VM的上线,当然由于APIC和AVS通常属于不同的blade/host,因此中间要经过ACI Leaf做一次中继。

vSwith上的转发模式有以下3种可选:FEX模式,vSwitch收到的流所有量都通过ACI Leaf处理,即使源和目的在同一个vSwitch上;Local Switching模式,同一个EPG内部的流量在vSwitch本地执行应用策略,跨EPG的流量送给ACI Leaf处理;Full Switching模式,vSwitch可以在本地处理处理同一个EPG内部的流量以及跨EPG的流量。后面两种模式只有AVS可以采用,因此本地执行应用策略要求vSwitch支持OpFlex。

(四)转发过程分析

先来看ACI对于ARP的处理。ARP的处理有两种方式,第一种就是泛洪,第二种就通过ACI Spine来做Proxy。第一种自不必说,第二种实现中当ACI Leaf收到ARP后封装VxLAN-GBP送给一个ACI Spine, ACI Spine的hardware database中存有MAC/IP的映射关系,ACI Spine将重新封装VxLAN-GPE的包头将其送给目的所在的ACI Leaf,从而抑制了ARP的泛洪。ACI默认开启的是第二种,第一种常用于默认网关位于ACI Fabric之外的情况下。

对于单播流量,如果ACI Leaf不知道目的地在哪,就封装VxLAN-GBP送给一个ACI Spine做代理,如果ACI Spine也不知道目的地在哪就在EPG内进行泛洪,否则查表后重写VxLAN-GBP进行定向的隧道单播。ACI Leaf的转发表项分为local entry和global entry,local entry存着所有本地VM的转发信息,global entry缓存着一些远端VM的转发信息,而ACI Spine中则记录着完整的global entry。对于L2/L3来说,其转发过程都是这样的,当ACI Leaf收到数据包时,如果目的MAC是否为分布式路由器的任播MAC则进行L3转发,否则进行L2转发。L2的转发参考MAC entry,L3的转发参考IPv4/v6 entry,而且L2的流量实际上也可以通过匹配IP地址来完成转发。需要注意的是,与标准VxLAN中VNI只能指代VxLAN Segment不同,当进行L2转发时VxLAN-GBP中的VNI指代L2对应的Bridge Domain,当进行L3转发时VxLAN-GBP中的VNI则指代L3对应的Network。

对于组播流量,同样是由Spine作为Proxy通过头端复制的形式进行伪广播,这样可以避免在ACI Fabric上使用IGMP和PIM。

当转发需要跨数据中心时,需要在ACI Border Leaf和远端VTEP间运行MP-BGP EVPN作为控制平面来学习转发信息。EVPN是一个标准协议,远端VTEP并不要求是ACI Leaf。

(五)再议ACI与SDN

ACI的技术实现就分析到这里了。概括地说,ACI就是北向GBP + 南向OpFlex,ACI的SDN完全是围绕着应用策略来做。“以应用为中心”,说白了就是一个向上开放API、向下能够自动部署的Policy Profile。其实,这更像是一个被Cisco明确喊出来的口号而已,由于数据中心向来有着自动化管理的诉求,因此绝大多数数据中心网络厂商在其解决方案中都可以提供Policy的编程能力,只不过一般都是针对一个EPG的,并没有向ACI提供ANP这种端到端的Policy Graph。端到端固然吸引人,但是这也必将导致Policy的制定异常复杂。对于网络管理员来说,写好一个ANP不会是件容易的事,甚至可能要比敲设备的CLI还让人头疼。

响亮的口号总是让用户很受用的,但实际上醉翁之意不在酒,这只是Cisco继续保留“网络黑盒”做SDN的幌子罢了。不过,在数据中心的场景中,“网络黑盒”确实也不会是一个大问题,毕竟用户更关心的是虚拟机上的应用负载,从用户的角度来看SDN的最大价值就仅仅是为应用提供更灵活的连接。从SDN界的角度来看,ACI的技术路线确实有点“半吊子”,很多人把ACI看做一个超级网管,或者说是“网管的网管”,关于“ACI究竟属不属于SDN”的讨论不绝于耳。

从我个人的观点来看,ACI仍属于广义上的SDN,只不过其“软件定义”的能力不那么彻底罢了。Cisco作为传统网络厂商中的“大哥大”,又怎么会情愿把设备的控制权开放给别人?技术路线的考量从来都是以商业目的为基点的,Cisco选择走ACI这条路线自然无可厚非。而且,为了将转发的控制权保留在设备本地,又要能在一定程度上体现集中式的控制,ACI在技术上有很多新颖的、值得学习的尝试。为此,Cisco颇费周折地设计了ACI Spine,为了在ACI Spine上支撑大规模的hardware mapping,当初Insieme甚至还为N9K设计了专用的芯片,这也导致ACI不仅仅不能兼容的厂家的设备,甚至连Cisco自家的其他N系列产品都没办法跑在ACI Fabric中。

从ACI发布的时候开始,Cisco就一直在制造舆论要干掉NSX,但实际上两者现在基本上是平分秋色,NSX还要处于稍稍领先的位置。前有NSX后有白牌,ACI未来究竟会发展如何,技术层面的东西都是次要的,最终还要看各方在市场上的博弈,这场战役反过来也可能会为数据中心SDN未来3-5年的技术形态奠定基调。

Q&A

Q1:转换成设备能够理解的配置是cli配置?
A1:不一定是转化为CLI,没有了人机交互,CL本身就也没什么意义了

Q2:请教下,aci里安全组怎么实现的?另外avs支持三层吗?
A2:安全组就是策略,通过Contract实现,可以用服务链串专业的安全设备。AVS没实际用过,个人猜测不支持三层

Q3:ACI下发策略不是要求服务器也用Cisco的吗?
A3:APIC要部署在UCS里。HOST无所谓

Q4:那个部件实施contact?avs还是leaf?
A4:都可以,avs也叫vleaf

Q5:总感觉通过GUI能做到的很少
A5:我都是Python做,不用GUI,很多客户也不用GUI,没必要GUI

Q6:对应aci是通过什么部件实现的?
A6:Neutron ACI driver先送到APIC VMM Manager,VMM转给ACI Policy Manager,PR转成MIT上的语意,通过OpFlex下发给N9000,如果是vleaf,通过N9000代理OpFlex,最后执行在N9000/AVS

Q7:VxLAN-GBP里的LB/LP位是干吗用的?
A7:LB用来做ECMP,LP用于策略

--------------------------------------------------------------------------
SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立,携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛,每周都会组织定向的技术及业界动态分享,欢迎感兴趣的同学加微信:eigenswing,进群参与,您有想听的话题可以给我们留言。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/17538.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于16-08-04
12