OpenFlow的局限性

　　OpenFlow是最广为人知的SDN技术，但是并非唯一。而且实践证明，仅仅靠OpenFlow，很多事情做不了，OpenFlow可以应用的场景非常狭窄。

　　关于OpenFlow本身的技术缺陷，很多文章都提过，我之前的书和文章里面也都详细分析过，诸如当前交换芯片支持的流表数量都有限，报文匹配和动作都不够灵活，都无法支持很多级流表等等。这些分析都是对的，但是我要告诉大家的是，这些限制根本不足为惧。为什么这么说?因为这些都是从OpenFlow技术规范出发得出来的结论，而不是从SDN应用的角度得出来的结论，换句话说，SDN的应用，未必真的需要OpenFlow规范里面提到的所有技术，所以就算有限制，问题也不大。OpenFlow真正的限制在别的地方。

　　运维管理的缺失

　　还是以我们给那个互联网大厂做的项目为例，该厂所要求的一个核心技术点别的交换机都做不到，只有盛科的能做到(因为盛科是用自己的芯片，恰好支持该功能)，而且该技术也能按照客户要求使用OpenFlow配置出来，一时皆大欢喜。但是当该产品要转运维的时候，问题来了，运维部门要求所有入网的设备，都要满足他们的运维要求，诸如SNMP管理、能够查看统计、能够ping通该设备、能够telnet该设备、能够通过Radius到远程服务器进行管理员身份认证等，这些对交换机来说是再正常不过的基本需求了，但是所有这些东西在OpenFlow上都没有定义。当然你可以辩论说这属于管理面的，不属于OpenFlow的定义范畴，OpenFlow只定义转发面和控制面功能，但是管理层面的不少功能依赖于转发面，比如管理员想通过带内口ping通交换机以便检验路径的可达。还有运维人员希望交换机能支持基本的LLDP协议来进行邻居发现。另外一个互联网公司也给我们提出过类似的要求。

　　运维管理功能的缺失导致了传统运维人员的抵触是可想而知了。这光靠OpenFlow是无法解决的，需要引入传统的东西。

　　跟传统网络的交互

　　用户网络中通常都是存在很多传统设备的，不太可能为了引入SDN而把这些设备都抛弃，所以这就涉及到一个问题，需要SDN设备跟传统设备互通。比如有一个三层汇聚交换机，该交换机会向下发送ARP获取下联设备的Mac，如果下面是个传统的主机或者三层设备，它会自动回复ARP请求，但是OpenFlow交换机没这能力，它只能把报文发送到控制器，让控制器回复，但是很多用户不想在控制器上进行开发来支持这种非核心业务。而且，实事求是的说，最高效的做法肯定是在交换机上进行回复。

　　还有更复杂的例子。曾经有一个软件开发商，使用盛科的交换机给一个电商开发WAN网的流量调度，它需要跟传统交换机进行路由协议交互，如果不在交换机上运行路由协议，就要在控制器上运行。在控制器上运行路由协议，会让控制器很复杂，而且效率低下，况且，这也并非该软件提供商的核心价值，他们也没这个能力去在控制器上做一个路由协议并把它做稳定，所以他们希望交换机上做。SDN交换机对他们来说，核心价值是让他们可以控制报文的转发路径，从而动态调度流量，至于跟传统网络的交互，他们不希望重复发明轮子，而是希望借用交换机的传统能力。

　　以上两个问题，并非是说靠纯OpenFlow交换机完全无法满足，如果在控制器上做得足够复杂且不考虑效率，也是可以做到的。我们就有一个云计算的客户，使用我们的纯OpenFlow交换机，完全靠自己开发的控制器去进行必要协议报文交互(主要是ARP)和各种其它必要的控制，他们之所以能做到这一点，就是因为他们本身有很强的研发团队。对于大多数人来说，要走这条路是很难的，那解决方案是什么呢?就是同时支持OpenFlow和传统二三层处理的混合型交换机。