从ACI和OpFlex解读思科的SDN战略

（作者简介：张卫峰，《深度解析sdn》一书作者，盛科网络软件总监，数据通信和芯片设计领域资深专家，有十几年的网络实践经验，对SDN、传统二三层交换机、数据传输设备，从管理面到协议控制面一直到芯片转发面，都有着深刻的理解。）

去年下半年，思科隆重推出了他们的秘密武器ACI（Application Centric Infrastructure），你说他是用ACI来对抗SDN也好，或者是拥抱SDN也好，反正他们自己宣称是既不同于VMware NSX，又不同于ONF OpenFlow的有思科特色的SDN。一时之间ACI成了一个大热的话题，众说纷纭，吸引了足够的眼球。

最近思科又联合IBM、Citrix、微软等向IETF提交了一个新的draft，名字叫OpFlex，号称是要取代OpenFlow（不知道是第三方的人这么讲的还是思科自己讲的）。但是跟ACI相比，算是低调多了，国内外讨论的人都比较少。甚至都看不到一篇正儿八经分析的文章。去年大张旗鼓推出硬的ACI，今年低调地推出软的OpFlex，两者之间有什么关系吗？

OpFlex这个draft篇幅不长，一共只有21页，去掉一些标题，引用之类的之后，有效页数不超过16页。如果你之前从来都不了解ACI，来读这篇draft的话，我相信就算你是个资深网络技术人员也会觉得不知所云，不是看不明白每一句话，而是不明白它的目的是什么，要解决什么问题。但是如果之前比较深入地了解过ACI，再看这个draft就会明白了，OpFlex其实就是ACI内部的策略控制协议，现在思科把它给标准化了。所谓的用OpFlex替代OpenFlow云云，本质上还是用ACI这种SDN去跟OpenFlow以及Vmware的NSX之类架构去竞争。这里要顺便吐槽一下，OpFlex这个draft写得真是坑爹，一般RFC都会把背景情况，来龙去脉交代的一清二楚，而OpFlex这个draft很多背景都直接省略掉了，因为它是基于一个已经存在的东西，作者潜意识里面觉得背景已经很清楚了。

这里简单分析一下ACI和OpFlex，我们先看看ACI的架构。

ACI是把数据中心中的物理网络视为一个封闭的Fabric系统，对用户来说是个黑盒，用户不需要关心里面是运行了什么协议，如何连接。这个封闭的Fabric系统就是ACI（Application Centric Infrastructure）。那如何对这个封闭系统进行控制呢？这里的控制分为两部分，一部分是配置传统路由交换功能，使得ACI中的各个物理设备彼此可达，这个时候是靠传统方式去配置的，而且这种配置通常是一次性的，配好之后就不用再动了。另外一部分则是用户业务的策略控制（比如基于ACI部署云计算网络），这部分不是靠传统网管，而是靠一个SDN控制器，这个控制器也有个名字，叫APIC（Application Policy Infrastructure Controller）。

APIC向上通过开放的Restful API跟各个第三方的系统或者工具进行集成，这些工具可以通过APIC来控制整个物理网络，应用策略，进而达到控制所有接入到该网络中的其它设备的目的。向下，APIC可以去控制整个ACI中的物理交换机（Spine/Leaf节点），不包括连接到这个物理网络中的其它设备（计算、存储、安全或者其它ACI之外的交换路由设备）。如上图中最下面那部分，外围的那一圈设备就不属于ACI的范畴，在APIC的架构中，这些接入到该Fabric中的用户设备，称为Endpoint(EP)，相同类型的Endpoint组成一个Endpoint Group(EPG)，比如所有的计算节点可以是一个EPG，或者所有具有相同Vlan的设备也可以是一个EPG，APIC并不规定EPG如何定义。

APIC如何来控制ACI中的设备呢？它所采用的协议就是OpFlex（当然，不清楚思科是否把ACI所用到的所有细则都写到OpFlex标准中去了）。那接下来我们就分析一下OpFlex，看它如何应用于ACI。

OpFlex协议中有AD(administrative Domain)、PR(Policy Repository）、PE(Policy Element)、EP(Endpoint)和 EPR(Endpoint Registry)这几个概念。它提到AD就是一个所有支持OpFlex的设备组成的管理域（该draft举例说，比如一个数据中心的物理Fabric网络就是一个AD）；PR是在一个全局集中的地方，负责存放Policy；EPR也是在一个全局集中的地方，负责管理Endpoint的注册，PE则位于ACI中每一台需要管理的设备上（是一个逻辑功能组件），它负责向上通告Endpoint的注册、变更，并应用来自APIC的Policy。而EP就是接入到该管理域的用户设备。显而易见，PR和EPR都（逻辑的或物理的）位于APIC上。

上面这段文字可能比较抽象，我们换个更直白的说法，它的工作原理大概是这样的：用户在APIC上配置了一堆的Policy，比如“如果某个用户设备的Mac是位于某地址段，就把它们划分到Compute Node EPG，统一应用策略A”；“如果某用户设备发出来的报文Vlan是10，就把它划分到Tenant1，统一应用策略B”等等。当ACI中的边界节点检测到某台用户设备接入的时候（具体检测方式并没有提到，估计是用户自定义，由APIC通过策略告知所有的边界设备），就把这个EP的信息主动上报，注意它并不是直接报给APIC，而是先报给上一级设备（Spine节点），如此层层上报，最终到达APIC。之所以要层层上报而不是直接报给APIC，是因为中间的设备也需要了解这些信息。举个例子说，如果检测到Vlan 10接入了，那就需要通知上联设备把相应的端口上使能Vlan 10。报给APIC之后，APIC分析接入的设备信息，决定它属于哪个策略组（EPG），然后把该EPG所对应的Policy下发给所有的相关设备，这些设备就在本地应用这些Policy。当然，也可能是APIC预先把这些Policy下发给这些设备了，这取决于应用场景。

ACI带来的好处就是业务的自动化部署，设备即插即用。你可以想象成你买了一个USB的设备，插到电脑上之后自动安装驱动和应用程序。当然ACI要做到这一点并不是那么容易，以上都是理论分析，实际网络要复杂得多，未必都能做到。

OpFlex详细定义了各种消息格式（都是基于JSON），以及每种消息的通信主体。它试图把OpFlex尽量定义得更通用，不仅仅局限于数据中心云计算网络，而是任何适合需要自动化网络业务部署的场所。

ACI和OpFlex技术本身的分析到此结束了，下面我们来分析一下思科的SDN思路。

首先，ACI和OpFlex算不算是SDN？绝对算。当然我知道有人不同意，说明明他们的设备上都运行了传统协议，怎么能算SDN呢？但是你要明白，交换机上不运行路由协议，只是OpenFlow的要求（甚至就算是OpenFlow，都定义了output to normal这种动作，也就是说走完OpenFlow流程后再走传统转发流程），不是SDN的要求，SDN只是说软件参与到网络控制中。在ACI的这个架构中，最上层的应用和各种工具通过开放的Restful API来控制Controller，Controller则通过开放的OpFlex API来控制转发设备，用户通过Policy几乎可以控制一切。有人说，ACI设备之间的数据报文通信，还是要靠路由协议，用户无法直接控制。但问题是，用户为什么需要控制这个？能带来什么价值？SDN并不意味着用户需要控制一切，而是让用户可以控制他需要控制的东西。所以，尽管我不是思科的粉丝，但是我这个SDN的坚定支持者也必须承认ACI是SDN。

其次，思科为什么要将OpFlex标准化？很显然，这是它整个战略中重要的一步。我不清楚他们是不是开始的时候就已经想好了这一步，但是很显然，ACI被很多人批评的一点就是它是一个完全私有、完全封闭的东西，不仅跟其他厂商设备不兼容，连跟自己之前的设备都不兼容，这是它最大的一个弊端。现在它希望通过开放并标准化它的控制协议来规避这个问题。虽然OpFlex这个draft上列了好几个公司的作者，但是明眼人很容易看出来，那几个公司的作者都是打酱油的，都属于思科的战友，来帮思科撑场子的，表示这个协议不是思科一家支持。

最后，最关键的问题，思科的意图能达到吗？

一方面，它感受到了SDN的威胁，想反击。但是另外一方面，它没办法阻挡这个潮流，只能也宣称拥抱SDN，但是拥抱的是最有利于自己的一种SDN实现方式。我个人的观点是，这个技术确实有很多亮点，但是要让其它设备商都跟进很难。第一，这个标准跟硬件设备能力强相关，思科为了这个ACI，专门开发了自己的芯片，别的厂商如果直接用商业芯片，某些功能做不到，所以就算支持OpFlex，功能上也不如思科强大。

第二，OpFlex代表思科的利益，其他设备商都看得很清楚，谁会愿意跟进？OpFlex作者列表中的那些公司，都是搞软件的。

第三，OpFlex这个协议从网络框架来说，相比较OpenFlow过于复杂了一些，小公司很难玩得转。而我们知道，技术从来都不是商业胜出的唯一要素，实现和部署的复杂性会影响它的推广，ATM与Ethernet（以太网）的战争就是一个很好的例子。当然OpenFlow也未必就会赢，OpenFlow的问题也很多。

归根结底一句话，ACI/OpFlex也许会叫好，但是极有可能不叫座……就像失败的FabricPath和QFabric一样？