VXLAN with EVPN as Control Plane

01-26

本文首發在SDNLAB

EVPN是近幾年最熱門的網路技術之一。如果你還沒聽過EVPN，你的網路技能可能已經落伍了，趕緊看看之前的EVPN簡介吧！EVPN全稱是Ethernet VPN，從名字上看是一個L2 VPN的實現。實際上在最開始提出時，也是用作L2 VPN，號稱是next generation L2 VPN，對原有的VPLS（Virtual Private LAN Service）進行改進。所以最開始的EVPN，是一套跨WAN（Wide Area Network）的L2 VPN的控制層和數據層技術，數據層特指的就是MPLS。所有的這些在EVPN簡介中都有介紹，今天我們來看一個EVPN應用的變化，將EVPN的控制層與VXLAN結合。

EVPN作為控制層，通常可以對接三種數據層，MPLS，PBB和NVO。NVO（Network Virtualization Overlay），這一分類包含了VXLAN（Virtual eXtensible LAN）。

傳統的VXLAN工作方式

VXLAN是一種Overlay網路技術，我相信大家對Overlay和VXLAN已經有一定的了解了，所以，我不在這對Overlay和VXLAN做解釋。我們直接看一下VXLAN網路是如何工作的。

VTEP

首先看看VXLAN網路中的重要組成部分，VTEP（VXLAN Tunnel Endpoint）。VTEP是一個網路設備VXLAN數據是在VTEP之間傳遞。從邏輯上看，VTEP包含了兩個介面：uplink和downlink。Uplink連接Underlay網路，原始數據封裝成VXLAN格式通過uplink在Underlay網路上傳輸；downlink連接Overlay網路，原始數據從downlink傳入傳出。所以，VTEP可以看成是一個連接Overlay和Underlay網路的edge設備。

舉個例子，當Overlay中VLAN100數據包通過downlink發送至VTEP，首先會映射到VXLAN ID 1001。在這之後，VTEP根據原始數據包的目的MAC地址和剛剛轉換獲得的VXLAN ID，在VTEP L2 Table中查找對應的Remote VTEP，如果能找到，就原始的Ethernet Frame封裝成VXLAN數據包，再通過uplink發送出去。

對端VTEP的uplink收到了VXLAN數據包，解封裝獲得原始的Ethernet Frame，再將VXLAN ID與VLAN ID做映射，加入VLAN100的信息，最後數據包再通過downlink發送出去。這樣，兩個VTEP下的VLAN 100網路相當於是連通的。（註：雖然這裡都是VLAN 100，但是實際上兩個VTEP下對同一個VXLAN ID對應的VLAN ID可以不一樣）

原始的Ethernet Frame被封裝成了一個IP/UDP packet，數據的傳輸變成了VTEP之間的IP/UDP packet傳輸，VTEP之間可以是二層網路，三層網路，甚至更複雜，但是這對VLAN100是透明的。

flood-learn

前面的例子中，如果VTEP L2 Table中沒有找到對應的Remote VTEP，那就要通過flood-learn來獲得對端的VTEP。

以Unknown Unicast為例來說明（也可以用Broadcast，例如ARP來說明，但是我就找到了上面這張圖，所以。。。）當最左側虛機想ping最右側虛機，ping包送到VTEP，因為在VTEP中找不到對應的Remote VTEP，VTEP會做如下操作：

原始的Ethernet Frame被封裝成VXLAN格式，VXLAN包的外層目的IP地址為組播地址。
VXLAN數據包被發送給組播內所有其他VTEP。

其實這就是flood過程。因為組播內所有VTEP都是接收方，最右側虛機可以收到組播的ping包。最右側的VTEP首先從ping包中學習到了最左側虛機的MAC地址，VXLAN ID和對應的VTEP。因為有了這些信息，當最右側虛機返回時，會直接發送到最左側VTEP。這樣最左側VTEP也能從返回包中學習到最右側虛機的MAC地址，VXLAN ID和對應的VTEP，並記錄在自己的L2 Table中，這就是learn過程。與交換機中的flood-learn不一樣的是，交換機中記錄的是對應的交換機埠和MAC的關係，這裡記錄的是Remote VTEP(IP Address)和MAC的關係。

下次最左側虛機想訪問最右側虛機，不需要再flood，直接查VTEP L2 Table就能找到對應的remote VTEP。

所以從這裡看出，VXLAN的轉發信息，也是通過數據層的flood-learn獲取，VXLAN不需要一個控制層也能工作，這與VPLS的情況很像啊！

EVPN control plane

VXLAN由RFC7348定義，在RFC中，只定義了數據層的行為，並沒有指定VXLAN控制層。在VXLAN技術早期，通過數據層的來獲取轉發信息，在實現上較為簡單，相應的技術門檻較低，有利於廠商實現VXLAN。但是隨著網路規模的發展，完全依賴數據層做控制會造成網路中廣播組播風暴，因此VXLAN也需要有一個控制層。

SDN controller也可以作為VXLAN的控制層，OpenStack中普遍用SDN controller控制OpenVSwitch，VTEP直接通過OVSDB和OpenFlow流表進行管理。這些內容很有意思，功能也很強大，不過跟本文是兩件事情，本文只討論EVPN作為控制層的情況。

EVPN作為NVO的控制層由IETF草案：draft-ietf-bess-evpn-overlay定義。上一篇講了EVPN的實現是參考了BGP/MPLS L3 VPN，那麼EVPN作為VXLAN的控制層時，仍然採用相同的架構，只是架構的組成元素髮生了改變。

具體的變換包括了：

PE設備變成了VTEP，有的時候也稱為NVE（Network Virtualization Endpoint）。相應的MP-BGP連接也建立在VTEP之間。
數據層變成了VXLAN，VXLAN是在Underlay網路傳輸。
CE設備變成了Server，這裡可以是Virtual Server也可以是Physical Server。

控制層數據傳輸

與傳統的EVPN基本一致，Server到VTEP還是通過local learning，VTEP通過讀取Ethernet Frame獲得本地連接設備的MAC地址和對應的埠。VTEP之間通過MP-BGP傳輸Route Type 2的MAC/IP route。這裡有點不一樣，以MPLS為數據層時，MAC/IP route傳輸的是MPLS Label，而以VXLAN為數據層時，MAC/IP route傳輸的是VXLAN ID。正好VXLAN ID也是3個位元組，能夠匹配原來MPLS Label的空間。相應的NLRI信息如下：

MAC/IP route通過MP-BGP傳輸到對端VTEP。現實中要求BGP連接是full mesh（任意兩兩互連），而為了減輕配置壓力，通常會引入BGP RR（Router Reflector）。BGP RR的作用是將一個BGP Speaker的數據反射給所有其他連接的BGP peer。使用BGP RR可以使得所有的BGP Speaker只需與BGP RR建立連接，否則按照full mesh，任意一個BGP Speaker必須與其他所有的BGP peer建立BGP連接。

所以，在有BGP RR的環境中，網路拓撲如下圖所示，是不是跟Spine-Leaf的網路結構很像？

所有的VTEP學習到本地的MAC地址之後，通過MP-BGP發送給BGP RR。BGP RR再將收到的MAC轉發信息，發送給所有其他的VTEP。經過BGP RR的反射之後，各個VTEP已經有了所有其他VTEP的MAC轉發信息，如下圖所示：

看一看圖中各個VTEP的L2 Table，第一列是MAC地址，第二列是對應的Remote VTEP（遠端MAC）或者當前VTEP連接的埠（本地MAC），第三列是VXLAN ID，這三列在介紹VTEP時說過。第四列是用來做MAC Mobility，也就是MAC遷移用的，這個稍後單獨介紹。

就這樣，控制層數據分發到了各個VTEP。

數據層數據傳輸

有了控制層數據，數據層就簡單多了。Server A想訪問Server B，通過查找本地VTEP L2 Table找到VTEP2，再封裝成VXLAN數據發送到VTEP2，VTEP2將VXLAN解封裝，轉發給本地的Server B。所以可以看出，從數據層面角度來看，有沒有EVPN效果都是一樣的。EVPN只負責VXLAN的控制層面，也就是MAC轉發信息的傳輸，對VXLAN數據層面沒有影響。

EVPN作為VXLAN的控制層面就是這樣了，是不是也不太複雜？接下來看一看MAC Mobility。

MAC Mobility

MAC Mobility在RFC7432中已經定義，也就是說這不是為VXLAN專門定義的。先來看看MAC Mobility解決了什麼問題？

現實中，經常會面臨Server遷移的場景，例如虛機遷移，物理機房的改造造成的遷移。以上圖為例，當Server A從VTEP1遷移到了VTEP3，VTEP3通過本地數據層面的學習（讀取ARP或者DHCP的Ethernet Header），發現了Server A。本來VTEP3上的MP-BGP進程應該將這個新學習的MAC通過Route type 2發送給其他VTEP。但是現在有幾個問題。首先，VTEP3本身已經有了Server A的MAC轉發信息，表明了Server A在VTEP1上，那麼VTEP3本地數據已經有了衝突了。其次，VTEP1和VTEP2中也有Server A的MAC轉發信息，它們將如何處理VTEP3發出來的Server A的轉發信息。你可以說，後來的覆蓋先來的，但是EVPN，或者MP-BGP，這是一個L7的協議，後來的不一定是更新的數據。比如，Server A遷移到VTEP3，VTEP3本地學習到了Server A的MAC，並發送出去，VTEP2收到了這個信息，但是由於網路阻塞，VTEP1關於Server A的信息過了一會也發送到了VTEP2。如果後來的覆蓋前面的，那這時就是舊的信息覆蓋了新的信息。

在說解決方案之前，先回顧一下EVPN新增的MP-BGP Route type和BGP Extended community。

MAC Mobility就是基於圖中標註的Extended community實現。BGP Extended community是跟隨在BGP NLRI信息之後的輔助信息，像RT（Route Target）就是最常用的一種BGP Extended community。MAC Mobility Extended Community的格式定義如下：

所以，具體工作過程是這樣，當VTEP通過本地的數據層學習獲得了一個MAC地址，如果本地的L2 Table中沒有這條MAC地址的記錄，那麼VTEP接下來發布的MAC/IP route會帶上一份MAC Mobility Extended Community，其中的Sequence Number是0。（也可以不帶，這樣默認就是0）這也就是上面示意圖中第四列中的0的意義。

當VTEP通過本地的數據層學習獲得了一個MAC地址，如果本地的L2 Table中已經有這條MAC地址的記錄，那麼VTEP首先會更新自己的L2 Table，將之前的MAC轉發信息覆蓋。之後VTEP發布的MAC/IP route必然會帶上一份MAC Mobility Extended Community，其中的Sequence Number是原有記錄的數值加1。這樣，當其他的VTEP收到了這條MAC/IP route，對比本地記錄，就會發現，這是一條更新的MAC轉發信息，原有記錄會被覆蓋。如果VTEP收到的MAC/IP route中的Sequence Number小於當前記錄的信息，那麼這條MAC/IP route會被丟棄。

MAC Mobility中的Sequence Number可以看成是MAC轉發信息的版本號，高版本可以覆蓋低版本。

從另一個角度看，如果沒有控制層的MAC Mobility機制，那麼Server遷移之後，只能等L2 Table中的表項老化以後，重新flood-learn才能獲得更新之後的MAC轉發信息，這樣的時間相對要長很多。這就是EVPN作為控制層帶來的好處之一。

最後

EVPN的提出是作為下一代L2 VPN。L2 VPN實際上是在WAN上的一個邏輯二層網路。如果將L2 VPN與Overlay技術，例如VXLAN做對比，其實有很多相似的地方。比如都是有Overlay和Underlay，Overlay都是L2網路，都有相應的edge設備等等。正是這些相似之處，才會有將原本是L2 VPN的控制層的EVPN，用作Overlay網路，例如VXLAN網路的控制層。VXLAN網路配合EVPN作為控制層，不僅能減少網路中的廣播與組播數量，而且能帶來EVPN作為控制層的一些優點，例如本文介紹的MAC Mobility。在一個VXLAN Fabric架構中，採用EVPN做控制層，藉助功能完善的BGP（確切說是MP-BGP）協議，能夠高效的連接不同的POD，甚至連接不同的site。所以從這個角度來說，EVPN作為VXLAN的控制層的應用，並不遜色與其作為L2 VPN的應用。