在昨天的主題《從二層交換到三層路由》中，我們已經瞭解了Neutron和VMWare NSX虛擬網絡模型中，VXLAN轉發平面的工作方式。那麼，數據包轉發所依賴的MAC和FIB信息是從哪來的呢？
在早期的Neutron版本中，採用了Openflow協議，將MAC，ARP和FIB以流表的方式下發到OVS中。Openflow的出現，是網絡界的一場重大變革，但Openflow也有着一些致命的缺陷。
一方面，Openflow代替泛洪學習的機制導致控制節點負擔過重。Openflow VXLAN網絡中，VTEP之間的BUM報文都將觸發Openflow控制節點代答或下發流表，在網絡較大時，對控制節點是沉重的負擔。
另一方面，如果控制節點意外停機，Openflow流表將無法刷新，新的虛擬機也無法上線。這在生產環境中是難以接受的。
由於Openflow設計的這些固有缺陷，人們需要新的控制平面協議，爲VXLAN網絡同步各個節點的MAC和FIB信息。
一些人注意到了VXLAN和VPLS的相似之處。VPLS有兩種控制平面，CISCO主導的Martini方式是使用LDP作爲控制平面（RFC4762)，而Juniper主導的Kompella方式是使用MP-BGP作爲控制平面（RFC4761）。VPLS的主要問題是需要對所有BUM數據包進行泛洪來實現MAC地址的學習，而浪費了寶貴的骨幹網絡帶寬。爲了解決這一問題，人們提出了EVPN(RFC 7432)，通過BGP協議來交換各個隧道端點之間的MAC/FIB信息。
我們發現了，如果使用VXLAN代替VPLS，也就是將EVPN協議作爲VXLAN的控制平面，在數據中心網絡中也可以實現VXLAN的二層和三層轉發，如下圖：
EVPN的Route Type2，可以實現在各個VTEP之間同步VM的MAC、IP、二層VNI(所在子網)、三層VNI(對稱IRB方式做VXLAN路由時，使用的公用中轉子網VNI)。
EVPN的另一種宣告方式，叫Route Type5：
Route Type5和Route Type2的區別，在於前者可以以子網前綴方式，向網絡中其他VTEP宣告IP地址段，而後者是以主機路由的方式宣告離散的VM（主機）。因此，Route Type5非常適用於連接網絡邊界路由器的VTEP，向其他VTEP宣告出局路由。
那麼，圖中的RR是什麼角色呢？讓我們回憶一下《BGP設計與實現》中提到的，在AS域中，所有iBGP應當建立全連接。這樣，如果網絡中有n個VTEP，總共就需要維護n(n-1)/2個連接。引入RR，則可以將iBGP的連接數從O(n2)精簡爲n。
有了EVPN作爲VXLAN的控制平面，我們發現，前面提到的兩個問題都迎刃而解了。
- EVPN代替了flood-and-learn的機制，VM上線或遷移時，VTEP只要通告更新即可；
- EVPN在配置完畢後，各VTEP會記住相關配置，控制節點只有在添加租戶/子網時，纔會修改EVPN配置，避免了控制節點單點故障帶來的風險。
EVPN可謂是雲網融合的紅娘！
那麼，是否有了EVPN + VXLAN，雲平臺的網絡架構就完美了呢？
讓我們回想一下，虛擬化網絡中，VTEP是在哪裏實現的？
對了，是在OVS上實現的。OVS需要利用每臺物理機的CPU實現VXLAN包頭的封裝/解封裝，以及EVPN通告和地址學習。
我們有沒有辦法利用網絡中的物理交換機代替OVS做這些事情，將寶貴的CPU資源用來計算呢？
請大家關注下一篇——
To Be Contiuned