《云数据中心网络与SDN：技术架构与实现》——2.3.2　FIB可编程

2.3.2　FIB可编程

FIB可编程就是提供直接对转发表进行控制的能力。FIB可编程的代表技术就是大家所熟知的OpenFlow了，这里指的OpenFlow还是OpenFlow 1.X。从2016年下半年开始，ONF已经在尝试把P4的思路融入OpenFlow里面去了。实际上，OpenFlow是不止于FIB可编程的，但它主要是围绕FIB可编程来做的。

OpenFlow在圈子内毁誉参半：学术界对OpenFlow有着同根同源的情怀，IT出身的人认为OpenFlow使用简单可以满足复杂的需求，运营商对OpenFlow将信将疑，大部分厂商则对OpenFlow嗤之以鼻。不同方面对OpenFlow的说法各执一词，也导致了圈子内出现了很多对OpenFlow片面的批评或者过度的赞誉。下面是笔者经常被问到的一些问题或者曾经听到的一些表述，这些说法某种程度上来说都有一定的道理，但是如果不予进一步的思考，很容易导致技术思维出现混乱。下面就把它们整理在一起集中做一些分析，希望还给读者一个真实的OpenFlow。

先来看看负面的说法。

好久没更版本了，OpenFlow要不行了。OpenFlow 1.5之后确实很久没出新版了（OpenFlow 1.6只对ONF会员开放），但很大程度上是因为前期推进得太快了，很多不错的增强都还没有落实到硬件交换机上。再追求速度出新的版本也没有意义，而且ONF也在考虑P4和OpenFlow的关系。测试和一致性认证是一致在推动的。

OpenFlow是为了学术圈发论文用的。学术圈确实靠着OpenFlow出了不少论文，这是件好事，因为OpenFlow把网络的门槛降低了。而且基于这些论文，也有很多思路变为了产品。

OpenFlow只能在数据中心落地。大网上推OpenFlow遇到的问题确实远远多于数据中心，不过通过对OpenFlow进行一些扩展和定制后，还是可以在大网上找到应用场景的。传输领域的OpenFlow已经得到了不错的扩展，包括PTN和OTN。

OpenFlow只搭VxLAN。SDN不等于OpenFlow，SDN也不等于Overlay。OpenFlow是集中式实现Overlay的一种方式，但OpenFlow最擅长的不是Overlay而是策略。OpenFlow和VxLAN容易被联系在一起，很大程度上是因为OVS在云里面火了，而OVS恰好对这两个都支持。

OpenFlow就是ACL。从设备角度来看，可以这样简单地理解，因为OpenFlow流表里两个核心概念match和action，和ACL都能对得上。不过OpenFlow规范中match和action的丰富度要高得多，但是交换机上实现了哪些要看具体的产品。

OpenFlow只能基于流进行编程。OpenFlow的确具备对细粒度的流进行编程的能力，但没有强制要求必须基于流进行编程。

OpenFlow就是静态路由。只match目的IP+前缀的流表可以看作类比于由控制器下发的静态路由，这只是OpenFlow很多用法当中的一种。

OpenFlow在妄想着干掉IGP和BGP。没有任何官方表述有类似意思的表露，OpenFlow控制器向来把IGP和BGP看作与传统网络互通的东西向协议。在设备数量较少、设备自主可控的情况下，OpenFlow具备代替IGP/BGP的潜力。

OpenFlow交换机只能实现二层功能。控制器可以模拟网关的逻辑，流表可以完成基于IP的转发并改写TTL和MAC，实现路由没有问题。

控制器必须集中式、端到端控制。OpenFlow控制器可以部署在OpenFlow交换机本地，只负责这一台交换机的流表。虽然损失了集中式控制的一些好处，但是仍然可以获得转发控制分离的所有好处，可用性也有很大的提高。

控制器挂了，转发就挂了。OpenFlow协议明确要求交换机支持standalone模式，即便控制器挂了，原来的流表仍然可以继续保留在数据通道上。

首包都要PacketIn，流量大了控制器就崩了。PacketIn只是为控制器提供了一种触发式Reactive编程的可能，控制器知道的信息可以在首包产生之前就预置到交换机中。使用OpenFlow的生产环境中，对于大部分流量采用预置流表的Proactive方式，可以有效地减少流量对控制器的冲击。

PacketOut和Statistics类的消息，对控制器消耗太大。ARP/LLDP/LACP/ICMP可以卸载到交换机本地，OpenFlow规范没提，不代表OpenFlow交换机不能做。Statistics过于密集地上报控制器确实是有问题的，OpenFlow本身也不是为了这个设计的，如果实在需要，可以通过auxiliary connection来进行优化。

FlowMod数量太多，交换机资源不够。当FlowMod的粒度比较细的时候，确实面临着这个问题，但是有很多办法可以解决，比如流表分级、流表聚合等。

传统的ASIC支持不了OpenFlow。ASIC可以支持OpenFlow，只要另外加适配即可，比如OF-DPA。ONF也在积极推动TTP和NDM。目前的OpenFlow交换机大部分是基于ASIC做适配的，不过基于传统ASIC实现OpenFlow肯定是有很多限制的。

OpenFlow必须依赖TCAM。TACM是OpenFlow需要的硬件资源中的一种，CAM、LPM、RAM在实际的OpenFlow交换机中都扮演着不可或缺的角色。

OpenFlow没有网管能力。OpenFlow不是专门为网管设计的，不过可以实现网管的一些功能。如通过收集Statistics可以做一些流量统计，通过配合使用PacketIn/PacketOut/FlowMod可以发一些探针的包来监测路径。

OpenFlow多控制器机制做得不好。OpenFlow只是南向协议，只木能规范交换机看待多控制器的视角，没有权利规范多控制器间的控制。OpenFlow交换机可以连接多个控制器做主备，但是目前协议中没有对负载均衡进行规范。商用OpenFlow可以自己扩展负载均衡机制，比如把不同的消息送给不同的控制器。

OpenFlow协议扩展性差。厂商可以自己定义Experimenter。而且OpenFlow 1.3就已经有40多个字段了，现有的OpenFlow交换机支持到20个左右的字段是也没有问题的。怎么用这些字段是控制器可以自定义的，对于不需要互通的私有场景，控制器好好规划20个字段基本足够用了，再增加新的字段是否真的有必要？

OpenFlow无法实现带状态的控制。通过PacketIn，控制器可以实现一些带状态的控制，比如NAPT，但是性能上会有很大问题，如果把OpenFlow控制器拉到交换机本地会有所缓解。另外，OVS已经基于Conntrack扩展了match和action，在内核中即可实现带状态的处理。

下面再来看一些浮夸的说法。

Nicira、Google用的就是OpenFlow。Nicira和Google确实用了OpenFlow，不过都发现了OpenFlow的一些问题，都基于OpenFlow做了私有的扩展。

Neutron OVS用的就是OpenFlow。Neutron OVS没有用OpenFlow，虽然数据库是集中式的，但转发的控制逻辑还是分布式的（不考虑l2_pop及其他扩展）。

OpenFlow能实现所有网络功能。控制器理论上来说确实是万能的，流表不能处理的事情PacketIn和PacketOut控制器都是可以做的，不过这有两个前提条件——为OpenFlow控制器集成其他的协议收集状态；可以忍受时延与性能下降。

集中式控制就是OpenFlow控制器包办一切。这个说法早期短暂地出现过，不过大家很快意识到这种做法的不合理性。就像前面说过的，部分功能可以卸载到交换机上。

Counter可以搞定一切运维。Counter只能记录和流相关的参数，不能覆盖和设备本身的状态和配置信息，需要配合使用SNMP/OF-CONFIG/OVSDB。不是所有交换机厂家都支持Counter，号称支持的可能支持得不全面。

有了Barrier就可以搞定事务。Barrier只是能够保证交换机上执行控制器命令的顺序，做一些简单的状态同步是可以的，但是Barrier远远搞不定事务，比如post-commit和roll-back。

所有功能都可以通过流表卸载。流表通常只能match到传输层，应用层是无法处理的，因此HTTP、DHCP和DNS流表都是没办法实现的。

可以进行任意粒度的QoS保障。配合OVSDB在控制器上虽然可以端到端地开通QoS路径，但是控制层面通了不代表数据平面能够正常干活。QoS最后是要落到端口队列上的，而硬件交换机单端口的队列数量是非常有限的，做到为每条流都分配一个队列几乎是不可能的。

OVS就是专用于OpenFlow。OVS是“原生支持OpenFlow的虚拟交换机”，而不是“专用于OpenFlow的虚拟交换机”。在很多云计算环境中使用了OVS，但没有使用OpenFlow。

不想用OpenFlow干的事情，Normal掉就可以了。协议中Normal不是必选而是可选，OVS实现Normal没问题，不代表硬件交换机实现Normal就没问题。硬件上支持OpenFlow和传统协议双栈的互通是很困难的，所谓的Hybrid OpenFlow交换机，一般都是基于物理端口或者VLAN把双栈隔离开的。

OpenFlow适合做安全。没错，OpenFlow适合做安全策略，但是OpenFlow自身又引入了很多新的安全问题。

OpenFlow是幸运的，又是不幸的。幸运的是借“软件定义一切”的东风着实火了一把，不幸的是初出茅庐就被给予了过高的期待，面对着NETCONF、BGP这些“SDN原住民”，多少显得有些稚嫩。不过每种协议都有自己的问题，不应该一棒子打死，用在该用的地方，OpenFlow还是可以所有作为的。