近期因为工作关系，思科、华为的SDN都有接触，并且思科ACI已经在我们的某个大型客户里运行很长一段时间，但是反馈并没有用好，或者说并没有真正的用起来，在讨论背后原因的时候，我们需要首先了解一下ACI的基本理念和核心价值，在此之前，很多人对开源的Openflow、ODL、ONOS这些标准SDN都能耳熟能详，但是对思科自研的SDN系统和标准SDN差异不慎了解，在我看来，思科的ACI，确实是个异类中的异类。
思科在SDN方面的理念，秉承其创始以来始终如一的网络自治、自愈、无中心化主张：
能分布则不集中
能下沉到设备执行的功能绝不交给集中的控制实体处理
这种理念渗入骨髓，甚至在ACI控制器集群中也只是基于分布式数据库考虑了容错性，并没有真正意义上的负载均衡。这大概是因为负载均衡本身也是集中控制的一种，而控制功能下沉之后，确实也没什么负载会重到足以压垮一台控制器。
谈ACI首先要了解的是，APIC和交换机之间的关系是松耦合的，所谓松耦合类似塔台和飞行员的关系，塔台只告诉飞机从那个跑到落地，飞行员则依靠自己判断进行降落，APIC和交换机之间的南向接口不是标准openflow，而是openFlex（已经提交IETF） 能够管理不同厂家设备 但前提是这些设备要支持OpenFlex，大家的语言口径对齐就能互相操作。而openFlex和openflow之间最大的差别，就是openflow是和交换机紧耦合，openFlex则是和交换机松耦合。controller只发送policy到switch 至于你怎么执行controller不管，塔台是不会管飞行员如何落地的，具体来讲openflex下发的是 策略 参数 可用资源等逻辑化的东西，打包下载到交换机上后，由交换机转换成为芯片可以执行的东西。
整个fabric里面的表项都是/32 的host，出网路由则不是，所有表项存放在spine上，控制器只会monitol这些表项，当然这些表项承载在BGP上，你是无法配置和修改的
在ACI的fabric逻辑模型中，ACI的关键要素分为3个， identity、location （就是vtep IP 一般不变）、policy （指业务主机要进行访问它的policy是什么）
这3个要素的maping在ACI里有专门的数据库来体现 ACI感知业务流 属于那个segment 执行什么policy都会在fabric内部来实现，如何实现就是使用的标准vxlan包头的保留字段（其余厂商无法进入此fabric原因也在此）
在APIC控制器架构中，和其他controllor也没有太多区别 或者没有什么特别有特色的东西，策略管理、拓扑管理、状态管理 更多就是一个策略面，这里不在赘述
在Telemetry：atomic counters 遥测 原子计数器，ACI采用类似P4的方法，fabric具备在leaf节点上给每一个数据包打时间戳，这样fabric将拥有路过设备的状态信息 如拥塞信息，也就是链路可以做到动态负载均衡 ，而这些信息也可以做大数据分析，也就是熟知的思科Tetration
Policy-Based模式，我认为这是ACI的最大创新点，但在此前提首先要解决application是什么，不同角度 不同的人 它对application的定义和认知是有很大区别的，有人认为web服务器是app，当然也有人认为中间件是app，在ACI中指在不同业务逻辑之间的访问关系 叫application，也就是policy， 有了上面的前提，这也就是说控制器下发的就是策略的原因。而policy包含方方面面的关系，ACL 资源使用 业务逻辑划分 等等这些逻辑策略，控制器下发的是抽象后的policy，nexus交换机收到policy后，再由他变更为交换机对应的配置，policy和配置的含义包括
policy：tenant、EPG、全局性交换机资源分配 （包含逻辑和物理信息）
配置：ACL QOS vlan trunk flooding…
policy-based 的本质就是imperative命令式和declarative宣告式的区别，通用SDN集中式控制器采用命令式，强推所有需要做的事情也就是，而声明式只要告诉交换机是什么即可，也就是how。如此控制器处理强度会大量降低，ACI控制器只负责业务策略需求，也就是policy，而policy在硬件网络实现 则由Fabric自身实现，也就是policy的render过程
最后是ACI logical model，其分层结构大致是，最上层为tenant租户---context/vrf---BD/bridge domain---ip subnet子网---物理交换机
这种分层也是一种典型的云化思想 从逻辑到策略再到物理资源 都抽象出来给业务任意调用，EPG就是业务组，通过contract进行policy执行。ANP application network profile，就是一串EPG和contract的组合，形象些就是一个生产业务线
对比传统网络，这种Policy-based抽象后的网络资源，就能按需进行分配和撤销，随时创建测试区域，也可以随时把测试区域转化为生产区域，并且把原来点状独立设备整合为一个整体来运维和监控。
总结来说，思科ACI把策略和执行视为两个完全不相交的维度，并解耦为互相独立的控制回路。策略制定属于长周期行为，影响具有全局性，因此交给控制器深思熟虑谨言慎思，讷于言；而某一个策略的具体执行往往只是产生局部影响，对智能要求不高，讲究敏于行，下沉到网络设备完成再合适不过。策略下发之后，控制器就可以洗洗睡去，哪管他身后洪水滔天，反正网络设备上的分布式控制回路会摆平一切。即使控制器被摧毁，网络仍然能够按照既定的策略向确定的战略目标运动。控制器到底是睡去还是死去，一时半会和网络设备也没有多大的关系。
但是，这个看似闲散的控制系统，对应用却表现出超群的友好性。由于切除了所有看起来智能的器官，ACI控制器完全定位于服务而非控制。为了提供服务，思科甚至自己研发能够支持ACI的交换机芯片，这看起来一点都不闲散。
但交出控制权并不意味着不作为，ACI的核心价值在于成功地将网络中的各种资源抽象为透明的服务和对象，令应用操持网络如左右手，但控制器并不去自作聪明地插手网络内政。
关于SDN是否应该开源的话题，业界多虑，徒靡口舌久矣。站在用户的角度，罗振宇2017跨年演讲中的一句话击中要害：用户需要被粗暴地对待，把菜谱推到他面前来一句你随意是对用户的不尊重。在网络领域，并不缺乏热爱厨艺的用户，但是，他需要你粗暴地把食材、厨具、香料甚至教程准备妥帖。如果你不能为用户提供粗暴而满意的服务，对不起，他就要自己开个馆子和你抢生意。谷歌是这么干的，亚马逊也是这么干的，越来越多的互联网公司正在撸起袖子从头到脚搞自研。到了这步田地，开不开源，白不白牌，还有那么重要吗？
关于ACI，业界存在多种不同的声音，争论也从未停歇，仅就设计理念而言，我只能说老司机毕竟是老司机，思科ACI更胜ODL、ONOS一酬。一个勤快麻利没啥想法的老家奴，用着舒心，让人放心。而那个号称能够替你控制一切的家伙，离它远点。
