OpenFlow多级流表是当前的热点话题，但缺少实际应用案例，本文中盛科张卫峰分享了OpenFlow多级流表在实际网络方案中的运用。该方案是基于SDN的性能优化方案，将影响网络性能的工作从服务器Offload到TOR交换机上。
众所周知OpenFlow里面很多行为都是协议无关的，在很多人看来都是脱离实际地要求任意灵活，纯属瞎胡闹。比如要求流规则中至少匹配12元组，比如要求任意数量的多级流表，既难实现又找不到应用。但是事实上，它的要求是否合理，完全取决于你怎么去理解它。在讲正文前，先顺便聊一下这个题外话。如果你对OpenFlow标准的理解是：厂家的实现必须要能同时匹配12元组，必须要能支持任意数量的多级流表，必须要能在流表之间任意跳转，那我可以告诉你，这种要求是做不到的，也是不合理的，这并不是OpenFlow的本意，OpenFlow的本意在于要求你能满足各种实际应用的需求，场景一中需要匹配Mac，那你要能匹配Mac；场景二中需要匹配IP，那你要匹配IP。场景三种需要你先匹配Mac,再匹配IP，你要能做到；而场景四种要求你先匹配IP，再匹配Mac，你也要能做到。换句话说，公司要求你懂中英日韩四国语言，不是要求你同时能讲这四种语言，而是要求你碰到日本人能讲日文，碰到英国人能讲英文，碰到韩国人能讲韩文。
现有的纯软件Tunnel Overlay云计算网络解决方案
题外话说完了，再回头讲正题。尽管如此，就算是理性的人，也还是觉得难以找到OpenFlow多级流表的实际应用案例。今天我就来分享一个在实际生产网络中对OpenFlow多级流表的运用，这个实际生产网络就是IaaS云计算网络，已经在客户那里实际部署。
我们都知道现在最主流的IaaS云计算网络的解决方案就是纯软件的Tunnel Overlay，为什么最主流？因为灵活嘛，而且能解决问题。包括现在最火的OpenStack，使用Tunnel Overlay方式来组网的也很多，它在转发面的大概工作流程就是一个VM发送报文到vSwitch，vSwitch加上Tunnel Header(VxLAN或者NvGRE)后，从服务器网卡发出去，通过中间的物理网络，送到目的服务器上的vSwitch, vSwitch将Tunnel解封装后，原始报文转发到目的VM。如下图所示。
基于硬件的OpenFlow四级流表架构
纯软件Tunnel Overlay方案虽然灵活，但是有不同程度的性能问题（程度取决于每个云平台研发团队对它的优化力度），而且云计算网络中通常都会因为各种各样的原因，有非虚拟化的设备，这些设备如果要接入到tunnel overlay的网络中去，必须借助于硬件TOR交换机作为tunnel gateway。
盛科网络一直都在为各种应用场景进行SDN定制，云计算网络作为SDN的目前最重要的应用领域，自然也不例外。现在盛科基于SDN提出一种性能优化方案，将影响网络性能的一些工作从服务器Offload到TOR交换机上去做，从理念上讲并不是把TOR交换机作为物理网络的一部分，而是作为服务器网卡的一部分。该方案已经在部分客户网络中部署。现在我们来分享一下OpenFlow多级流表在这个方案中的运用。
在该方案中，云平台（如OpenStack）跟SDN TOR交换机紧密集成，通过Controller控制SDN TOR交换机的流表下发，来完成虚拟网络转发路径的建立。VM将报文送到vSwitch，vSwitch直接将报文加上Vlan通过网卡送到TOR交换机，TOR上查流表，去掉VlanTag，识别VM，进而识别Tenant，可选地，可以对VM或者Tenant应用一些策略（如限流，安全过滤），然后查表，如果是跨机架送到别的TOR，则加上Tunnel，经过中间物理网络，送到目的TOR，目的TOR剥去Tunnel Header后查表转发（仍然可以先应用策略），到了服务器上，vSwitch查本地流表（只需要维护本地VM信息）后，转发到目的VM。整个架构和报文流程如下图所示。
为了完成整个过程，盛科专门针对云计算的应用场景，利用交换机芯片内置的N-FlowTM技术，专门研发出一种四级流表的OpenFlow模型。
每张Flow Table完成的具体功能如下：
Table ID为0的功能：
VM识别（基于macSa）;
租户识别（基于macSa or Vlan）;
Tunnel识别（基于Tunnel VniId）;
基于VM或者租户的策略应用
传递metadata到后面
Table ID为1的功能：
全局安全或者QoS策略应用
决定下一级table跳转到2还是3
Table ID为2的功能：
二层流表转发到Port或者Tunnel
Table ID为3的功能：
三层流表转发到Port或者Tunnel
跟云平台的集成
云平台直接通过盛科提供的（或者用户自己写的）插件跟一个集中式的Controller打交道（当然用户也可以出于可扩展性的考虑自己设计分布式Controller），通过这个Controller的标准OpenFlow接口去控制交换机，大量的工作（抽象信息翻译成流表）是在插件里面做的。这种架构的一个好处是可以兼容不同厂商的设备，只要这些设备都能支持云平台所需要的OpenFlow的能力（比如多级流表），支持足够数量的Tenant和VM。
Controller跟TOR交换机之间的消息不仅仅有OpenFlow消息，还需要OVSDB消息，用来创建Tunnel（OpenFlow并不支持创建Tunnel）。
原则上这种架构可以跟任何云平台集成，我们以OpenStack为例来说明如何将多级流表SDN TOR交换机集成到云平台中。
如下图所示，计算节点上的OVS Agent跟盛科 插件之间只有Query消息，是OVS Agent主动发过来查询VlanId/TunnelId的。所有的流表项配置消息都仅仅发生在Controller和SDN TOR之间，将Neutron Server所需要控制的节点数量从Hypervisor的数量级降低到TOR的数量级，可以大大缓解控制面的压力，提高云平台的可扩展性。
总结
SDN时代的网络，不再是以设备为中心，而是以应用为中心，应用驱动网络变革。这就需要很多深度定制的工作，云计算网络尤其如此。OpenFlow协议设计了多级流表，一直以来我们都没看到有什么典型的应用场景。本文所介绍的这个例子，可以算是OpenFlow多级流表的一个绝佳实践，我们能看到这个方案带来的明显的优势。
它基于标准的OpenFlow接口，可以防止厂商锁定，只要厂商支持OpenFlow多级流表，且能支持相应的匹配字段和编辑动作。
让Server专注于计算，将流表查找、Tunnel加解封装、QoS、Security Group等网络处理功能都Offload到TOR，可以大大减轻Server负担，提升网络性能。
分布式L3 Gateway的设计，特别是将L3 Gateway做到TOR上，可以避免集中式L3 Gateway带来的single point failure的风险，并消除它的性能瓶颈。而且是将router功能做在TOR而非hypervisor，可提升路由性能。
将云平台需要控制的网络节点数量从Hypervisor的数量变为TOR的数量，降低了一个数量级，有效减轻云平台的可扩展性压力。特别是在VM迁移的时候，需要去更新的节点数量降低一个数量级。
可以很好地支持非虚拟化环境。
TOR仍然可以对用户数据应用策略，进行监控，极大缓解了纯软件方案带来的网络不可视问题。
原文链接：http://www.csdn.net/article/2014-05-10/2819711-OpenFlow-table
