EVPN，你真的理解了嗎？
作者簡介：李俊武，sina微博北京-小武，著有《雲計算網路珠璣》；三年多交換機研發經歷（熟悉Broadcom、Marvell等公司交換晶元轉發流程和網路協議），兩年多基於Openstack雲計算平台架構設計經驗，現在華為IT產品線的雲計算網路架構與設計組，參與華為公有雲和私有雲的架構設計方面的工作，包括雲平台網路集成華為SDN控制器方面的設計工作等
EVPN（Ethernet VPN）是很早就提出的一種基於轉發麵控制信令同步MAC轉發表項的草案，最近討論比較多，這裡也對其進行更深層次的解讀。
一、什麼是EVPN及SD-WAN
EVPN的需求文檔在RFC 7209中描述，解決問題的場景是客戶在廣域網下通信時各局點MAC地址的動態通知，主要是針對L2VPN（VPLS，Virtual Private LAN Service）的缺陷（比如無法支持MP2MP、無法支持多鏈路全活轉發等）來提出的；其問題範疇包括：多鏈路同時負載、基於流的負載均衡、基於流的多路徑、跨地理域多PE節點冗餘、流量轉發優化、組播優化、廣播抑制、快速收斂（受限於PE的MAC地址數目等）等方面。
EVPN的方案文檔在RFC7432中描述，提出了每EVPN實例有一個唯一的RD（Route Distinguisher，包括一個唯一的MAC-VRF及一個或多個全局唯一的RouteTargets），然後客戶的環境通過CE設備連接多個運營商的PE，並且是可選的單路徑工作的一主多備或全鏈路工作的多活（CE到每個運營商PE的乙太網鏈路稱之為一個Ethernet segment）；每個PE對其他PE設備通過BGP添加新的route type來互相發布自己本地CE所具備的MAC/IP地址給其他PE，並可以通過安全的鑒權控制與其進行互相發布Active的Mac表項。
從RFC7432的文檔描述來看，EVPN的解決方案（以Vlan為Ethernet Tag ID例子）第一個draft版本發布時間是2012年2月，最新一個版本是2015年10月，所解決的問題比較類似於SD-WAN的解決問題領域：通過其使用的術語比如PE/CE等可以看出，是WAN場景下的轉發信息同步：從實現層面來看，做法類似於OSPF/ISIS/BGP等傳統路由協議，在轉發麵通過控制信息，實現網路設備間相互發布自己所具備的網路MAC轉發信息給彼此的目標。SD-WAN提供的還是運營商網路的邊界客戶自己設備處進行控制的能力（這裡的SD-WAN不包括SD-DCI），以實現網路帶寬等資源的最優化調度分配，從而充分且合理的利用首先的網路資源，降低客戶辦公場所或數據中心跨WAN通信的成本。EVPN方案來講，則是通過標準的控制信息，通過在PE之間相互交換轉發表項來實現自動的多地通信；SD-WAN依然無法對運營商的網路進行控制，因為運營商的網路無法隨意對開發者提供控制的API，無論從安全形度還是從工程角度，畢竟多加運營廠商的網路部署短期內還無法融合。
從EVPN的方案角度，並沒有限制其Ethernet Tag ID的類型，所以很多設備商提出了針對Vxlan的EVPN解決方案的實現，畢竟Vxlan在雲計算場景下是廣泛被使用的技術。那如果這樣的話，能否搭建一套基於EVPN的雲環境：虛擬機通過雲平台管理髮放，而網路則是各個網路設備通過EVPN來實現轉發表項同步，類似於傳統的DC?後面就和大家一起來探討下這個問題。
二、EVPN術的本質及相應的技術
EVPN首先作為一種新的轉發麵通過控制信息來發布轉發表項的方案來提出，根本原因是現在的客戶內部DC或辦公組網規模越來越大、轉發規則也越來越複雜，但是對整體網路資源使用率的協調能力要求越來越高。縱觀乙太網的組網歷史，最初小規模L2組網使用STP協議進行防環來擴大組網規模，但是其一方面浪費了太多帶寬，另一方面則是在網路規模稍大時（50-100台交換機設備）收斂時間就會變得異常慢，使得本來帶寬利用率就不高的詬病得到了放大，所以STP的組網限制在本地一個有限的組網規模下使用；後來提出了IP層路由的概念，通過TTL來防環，並提出了ECMP等讓同一個設備的流通過多路徑轉發，來提升鏈路利用率和鏈路冗餘，並提出了RIP/OSPF/BGP等多種路由協議，使得大規模組網時通過設備自身來發布在自己所具有的轉發表項，為互聯網的出現提供了基礎。現在EVPN則是繼續沿著這個思路前行，在新的場景下，越來越多的大量客戶業務（辦公場所或業務所在數據中心）在全世界的不同區域分布，並且需要進行數據通信，尤其是雲計算商業模式的出現。
與這種思路不同的另一種解決方案是SDN的架構，通過將網路設備控制面許可權收回並集中，實現和設備轉發麵的分離，從而實現了網路轉發表項的協同工作；SDN架構下網路更加靈活，並且集中式控制南向需要標準來控制不同設備商的設備，而北向的標準化為不同業務提供控制網路的能力有了可能，從而打破了以前網路分層帶來的網路黑盒概念，讓業務對網路低層能力充分感知，最大化利用網路，帶來網路資源利用率的提升，降低所需的網路成本；這種架構天然的與雲計算網路的架構的需求相匹配，只是雲計算對網路設備南向的控制需要的是兼容能力，倡導通過多種控制能力來管理儘可能多的設備商網路設備，對統一性或標準性並不是苛刻要求的；但是在北向上，由於要對業務提供可演進的平滑過度能力，反而比SDN的北向標準性更加註重（這樣就可以解釋了為什麼SDN的北向API工作一直進展不大，而OpenStack的網路組件Neutron的北向API則是已經基本標準化）。
兩種思路在雲計算下的業務場景進一步相比而言，傳統的通過轉發麵控制信令自主同步轉發表項的做法是無法滿足雲計算要求的；具體體現在雲計算業務的彈性上，因為網路的轉發麵基本是隨計算實例的變動而變化的，包括新建算實例、刪除計算實例以及計算實例的開關機和遷移等，而計算實例的變動在雲計算場景下規模較大且極其頻繁，並且雲平台下租戶業務的一切網路行為都要可預期的可控（比如ARP請求的廣播、位置單播/組播的報文轉發等），否則可能會導致很多不可預期的網路問題，包括租戶間業務帶寬的搶佔、業務轉發行為的一致性等，這幾個方面就要求雲平台的租戶業務網路尤其是VPC內部要能夠在有網路拓撲變化時（基本是租戶計算實例操作引起的），及時的通知到各個相關網路轉髮網元，否則很大可能導致流量的部分誤轉發。
這個要求下，SDN架構則可以在計算實例操作的動作下觸發SDN的控制器進行集中判斷和計算，然後同步所控制網元的轉發表項實現協同；而傳統路由協議等方式，則需要自己通過控制信令感知並計算來處理轉發表項，除了無法最優化利用網路外，更不能及時收斂，因為虛擬網路的計算實例是一直在添刪改，那麼虛擬網路則會一直處於未收斂的狀態，這個情況所帶來的問題對於有大規模組網的人來說是很嚴重的，因為數據中心路由協議大量的BUG是出現在路由協議在網路拓撲變更的處理過程中的轉發路徑更新計算上。另外，SDN架構通過控制面集中處理的思路，還解決了網路設備RIP局部路由的局限和OSPF各個全局路由計算的浪費及苛刻的一致性要求。所以從這個角度而言，雲計算網路的虛擬網路必須是Overlay方式的兩層架構，這個不僅僅是傳統數據中心向雲網路數據中心演進的需要。不然的話，虛擬機的任何操作，都會引起整個數據中心網路設備路由協議棧的重新收斂計算（一個數據中心大規模組網不使用路由協議，完全靠靜態路由的手工配置，搭建起來是不可能的，雲環境下網路彈性和網路自動化也更是無法實現）。
所以，如果一家雲計算公司的網路中，虛擬網路有和物理網路相關組網的耦合，那將天生是個無法實現大規模的侏儒。而OpenStack的Neutron組件對於路由協議的使用也基本限制在網路節點，VPC內部還看不到可能性。
三、再談SDN網路創新及革命
SDN網路架構的概念已經很久了，也衍生了很多新的概念，甚至衍生到了存儲SDS、計算SDC、運維等領域，從而誕生了SDDC的說法。SDN的幾個基本原則（集中式控制、控制和轉發向分離、開放標準的南北向介面等）是很明確的，其核心思想是讓應用能夠來直接和網路打交道，即對網路控制來獲取所需的資源；凡是提「SDN是一千個讀者眼裡有一千個哈姆雷特」說法的人是沒有理解什麼是SDN的託辭。但是SDN的這幾個原則從網路技術歷史上而言卻是又都出現過類似的做法，比如集中控制類似網管軟體Mib等、電信網中智能網的交換功能和業務控制功能相分離、雲平台網路組件的北向標準API和南向對多種網路設備的集中控制等。當然SDN和這些是絕然不同的，這部分概念對於真正做SDN領域的人，應該在2013年基本確定，現在再討論似乎已經感覺有點老生常談了，多討論也沒太多的意義。
類似SDN出現時候一樣，現在網路很多新技術提出後也被炒作較多，主要原因是傳統網路架構太成熟了，承載了現今的各種主要業務，極其難於演進和創新，所以但凡有點改進只能被包裝，不然估計無法推動或體現價值。比如最近的Segment Routing（SR），其實稱呼叫Source Rouing比較合適，但是SR方案提出就比較乖巧，一方面找到了原來MPLS方案下RSVP協議的複雜性帶來的不可部署從而解決了現網中的一些問題，另一方面在控制面則同時兼容SDN思路和傳統路由協議同步的思路，並且方案依賴於MPLS和IPv6的現有壓棧技術，根據頭標籤進行轉發（但是仍然需要轉發能力的提升，MPLS大多可以沿用原有交換晶元能力實現，IPv6場景下則基本需要晶元重新構建）。
從網路創新角度再討論下Vxlan，這個技術從其RFC解決的問題來看主要是解決隔離域數目不夠、交換機表項不足等問題；但是仔細思考下，隔離域傳統網路Vlan只有4K個確實比較少，但是MPLS的Label還是足足有20bit的，這個數目對於一個Region下的規模基本是滿足的，為什麼不使用MPLS來隔離不同租戶哪？而且數據中心或運營商使用BGP+MPLS的組網非常盛行，是極其成熟的技術。交換機表項不足的說法也有點誇張，現在數據中心大量部署萬兆交換機是基於博通提供的萬兆交換晶元Trident系列的，其MAC地址表項有128K之多，而且雲網路下每個交換機並不要求學習所有租戶的所有虛擬機MAC表項，對於一定程度上還是可以滿足租戶甚至是公有雲網路訴求的，現在國內大部分公有雲廠商的一個Region物理伺服器規模都還沒到這個量級。那麼這兩個問題思考後，Vxlan對於雲網路的價值更大的比重在於Overlay的分層，一方面給傳統數據中心向雲數據網路中心演進提供了可能和便利，另一方面則是物理網路的路由協議組網繼續使用，雲網路虛擬網路VPC則無法使用動態路由協議，從而為二者解耦提供了實現的確切方案。其他的比如NvGre/STT等技術依然同樣的效果。
四、隨風去吧，EVPN
技術的事情確切來講很那說那個可以盛行，涉及的不僅僅是技術可行性或優劣，更重要的是很多時候網路設備廠商、互聯網數據中心和運營商對於技術的選擇，而且更多的是基於他們自身的利益，SDN的發展現狀足以說明這些；也可能會類似於MPLS，有心栽花花不開，無疑在柳柳成蔭。EVPN技術對於客戶而言是有價值的，對於運營商而言需要一定的投資，在SDN這種架構的衝擊下，依靠轉發麵控制信令同步轉發表項的做法是否還會被繼續青睞，恕難預料，但是可以看清楚的是，EVPN在雲場景下尤其是針對Vxlan的MAC轉發同步，場景價值基本是設備商的一家說辭。
TAG:SDNLAB |