我想大家現在應該都清楚，基于流量的轉發并不適合現有硬件。為大流量設計的交換機，如轉發入口(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轉發模塊。