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