我想大家现在应该都清楚，基于流量的转发并不适合现有硬件。为大流量设计的交换机，如转发入口(NEC ProgrammableFlow交换机，Entersys 数据中心交换机等)或许是个例外，但即便他们不能应付反应流安装所要求的巨大数据流更新速度，我们当然期望虚拟交换机能运行更好，但遗憾的是，情况并非如此。

　　定义

　　基于流量的转发有时候被定义为单独传输层对话的转发(有时候被称作是微流量)，大量事实表明这种方法不能做扩展，其他人将基于流量的转发定义为所有不是仅限目的地地址的转发，我不了解这些定义欲MPLS Forwarding Equivalence Class (FEC)有何不同，也不知道我们为什么要弄个新的令人费解的词语来定义。

　　在Open vSwitch中的微数据流转发

　　Open vSwitch的原始版本是基于理想微流的典型转发架构：内核转发模块执行微流转发，并将所有未知数据包发给用户模式的后台程序，然后，用户模式的后台程序会执行数据包检查(使用OpenFlow转发条目或其他转发法则),并且为内核模块中心发现的数据流安装微流量条目。

　　如果你还记得Catalyst 5000，或许你会想起Netflow交换机一些令人不愉快的记忆，但这个方案的问题应该是硬件和CPU的性能不佳造成的。事实表明，虚拟交换机也不会好到哪儿去。

　　向Open vSwitch深入挖掘发现一个有意思的事情：流量驱逐，一旦内核模块达到微流量的峰值，它就会抛出之前的流量，直到你意识到默认峰值为2500微流量，这个数值已经足够一个Web服务器使用，而对托管50或100个虚拟机的Hypervisor而言,数量级肯定太低。

　　为什么?

　　微流量缓存非常小，没有很明显的效果，毕竟，Web服务器可以轻易应对10000个对话，而一些基于Linux的负载平衡器为每个服务器控制的对话数可以多出一个数量级，你可以增加默认的缓冲OVS流量，这下会有人好奇为什么默认数值如此低了?

　　我不能说明造成这种情况的潜在原因，但我怀疑和单位流量计数有关——流量计数器必须周期性地从内核模块转到用户模式后台程序。在比较短的间隔期里，在用户-内核槽之间复制成千上万的流量计数器或许会占用很多CPU空间。

　　如何修复?

　　还不够明显吗?放下所有关于基于微流量转发的概念包袱，按传统方式来做，OVS在1.11版本中走的就是这个路子，OVS 1.11在内核模块中部署了兆位流量，再从内核把流量发送到用户模式OpenFlow代理那里(因为内核转发条目几乎可以与用户模式OpenFlow条目做精确匹配，所以效果显著)。

　　不出意外，没有哪个虚拟机使用基于微流量的转发。VMware vSwitch，思科Nexus 1000V和IBM的5000V根据目的地的MAC地址做转发决定，Hyper-V和Contrail根据目的地的IP地址做转发决定，甚至用于vSphere的VMware NSX也使用分布式vSwitch和核内 Layer -3转发模块。