SDN实战团分享（二十七）：Cisco ACI技术解析

在网络厂商的圈子里，其实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。

相比于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 EV**作为控制平面来学习转发信息。EV**是一个标准协议，远端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用于策略