1.背景
VXLAN是爲了解決雲計算時代虛擬化中的一系列問題而產生的一項技術。
雲計算，憑藉其在系統利用率高、人力/管理成本低、靈活性/可擴展性強等方面表現出的優勢，已經成爲目前企業IT建設的新形態；而在雲計算中，大量的採用和部署虛擬化是一個基本的技術模式。
服務器虛擬化技術的廣泛部署，極大地增加了數據中心的計算密度；同時，爲了實現業務的靈活變更，虛擬機VM（Virtual Machine）需要能夠在網絡中不受限遷移（如上圖所示）。實際上，對於數據中心而言，虛擬機遷移已經成爲了一個常態性業務。
2.VXLAN介紹
2.1 VXLAN是什麼
VXLAN（Virtual eXtensible Local Area Network，虛擬擴展局域網），是由IETF定義的NVO3（Network Virtualization over Layer 3）標準技術之一，採用L2 over L4（MAC-in-UDP）的報文封裝模式，將二層報文用三層協議進行封裝，可實現二層網絡在三層範圍內進行擴展，同時滿足數據中心大二層虛擬遷移和多租戶的需求。
注：NVO3是基於三層IP overlay網絡構建虛擬網絡的技術的統稱，VXLAN只是NVO3技術之一。除此之外，比較有代表性的還有NVGRE、STT。
2.2 VXLAN網絡模型
名次解釋：
- VTEP（VXLAN Tunnel Endpoints，VXLAN隧道端點）
VXLAN網絡的邊緣設備，是VXLAN隧道的起點和終點，VXLAN報文的相關處理均在這上面進行。總之，它是VXLAN網絡中絕對的主角。VTEP既可以是一獨立的網絡設備（比如華爲的CE系列交換機），也可以是虛擬機所在的服務器。
- VNI（VXLAN Network Identifier，VXLAN 網絡標識符）
以太網數據幀中VLAN只佔了12比特的空間，這使得VLAN的隔離能力在數據中心網絡中力不從心。而VNI的出現，就是專門解決這個問題的。VNI是一種類似於VLAN ID的用戶標示，一個VNI代表了一個租戶，屬於不同VNI的虛擬機之間不能直接進行二層通信。VXLAN報文封裝時，給VNI分配了足夠的空間使其可以支持海量租戶的隔離。
- VXLAN隧道
說白了就是將原始報文“變身”下，加以“包裝”，好讓它可以在承載網絡（比如IP網絡）上傳輸。從主機的角度看，就好像原始報文的起點和終點之間，有一條直通的鏈路一樣。而這個看起來直通的鏈路，就是“隧道”。顧名思義，“VXLAN隧道”便是用來傳輸經過VXLAN封裝的報文的，它是建立在兩個VTEP之間的一條虛擬通道。
2.3 VXLAN報文
VXLAN報文格式
名次解釋：
- VXLAN Header
增加VXLAN頭（8字節），其中包含24比特的VNI字段，用來定義VXLAN網絡中不同的租戶。此外，還包含VXLAN Flags（8比特，取值爲00001000）和兩個保留字段（分別爲24比特和8比特）。
- UDP Header
VXLAN頭和原始以太幀一起作爲UDP的數據。UDP頭中，目的端口號（VXLAN Port）固定爲4789，源端口號（UDP Src. Port）是原始以太幀通過哈希算法計算後的值。
- Outer IP Header
封裝外層IP頭。其中，源IP地址（Outer Src. IP）爲源VM所屬VTEP的IP地址，目的IP地址（Outer Dst. IP）爲目的VM所屬VTEP的IP地址。
- Outer MAC Header
封裝外層以太頭。其中，源MAC地址（Src. MAC Addr.）爲源VM所屬VTEP的MAC地址，目的MAC地址（Dst. MAC Addr.）爲到達目的VTEP的路徑上下一跳設備的MAC地址。
3.VXLAN報文轉發機制
建立VXLAN隧道示意圖
3.1 同子網VM互通組網圖
- ARP請求報文轉發流程
序號1：VM_A發送源MAC爲MAC_A、目的MAC爲全F、源IP爲IP_A、目的IP爲IP_C的ARP廣播報文，請求VM_C的MAC地址。
序號2：VTEP_1收到ARP請求後，根據二層子接口上的配置判斷報文需要進入VXLAN隧道。確定了報文所屬BD後，也就確定了報文所屬的VNI。同時，VTEP_1學習MAC_A、VNI和報文入接口（Port_1，即二層子接口對應的物理接口）的對應關係，並記錄在本地MAC表中。之後，VTEP_1會根據頭端複製列表對報文進行復制，並分別進行封裝。
可以看到，這裏封裝的外層源IP地址爲本地VTEP（VTEP_1）的IP地址，外層目的IP地址爲對端VTEP（VTEP_2和VTEP_3）的IP地址；外層源MAC地址爲本地VTEP的MAC地址，而外層目的MAC地址爲去往目的IP的網絡中下一跳設備的MAC地址。
封裝後的報文，根據外層MAC和IP信息，在IP網絡中進行傳輸，直至到達對端VTEP。
序號3：報文到達VTEP_2和VTEP_3後，VTEP對報文進行解封裝，得到VM_A發送的原始報文。同時，VTEP_2和VTEP_3學習VM_A的MAC地址、VNI和遠端VTEP的IP地址（IP_1）的對應關係，並記錄在本地MAC表中。之後，VTEP_2和VTEP_3根據二層子接口上的配置對報文進行相應的處理並在對應的二層域內廣播。
VM_B和VM_C接收到ARP請求後，比較報文中的目的IP地址是否爲本機的IP地址。VM_B發現目的IP不是本機IP，故將報文丟棄；VM_C發現目的IP是本機IP，則對ARP請求做出應答。下面，讓我們看下ARP應答報文是如何進行轉發的。
- ARP應答報文轉發流程
序號4： 由於此時VM_C上已經學習到了VM_A的MAC地址，所以ARP應答報文爲單播報文。報文源MAC爲MAC_C，目的MAC爲MAC_A，源IP爲IP_C、目的IP爲IP_A。
序號5： VTEP_3接收到VM_C發送的ARP應答報文後，識別報文所屬的VNI（識別過程與步驟2類似）。同時，VTEP_3學習MAC_C、VNI和報文入接口（Port_3）的對應關係，並記錄在本地MAC表中。之後，VTEP_3對報文進行封裝。
可以看到，這裏封裝的外層源IP地址爲本地VTEP（VTEP_3）的IP地址，外層目的IP地址爲對端VTEP（VTEP_1）的IP地址；外層源MAC地址爲本地VTEP的MAC地址，而外層目的MAC地址爲去往目的IP的網絡中下一跳設備的MAC地址。
封裝後的報文，根據外層MAC和IP信息，在IP網絡中進行傳輸，直至到達對端VTEP。
序號6：報文到達VTEP_1後，VTEP_1對報文進行解封裝，得到VM_C發送的原始報文。同時，VTEP_1學習VM_C的MAC地址、VNI和遠端VTEP的IP地址（IP_3）的對應關係，並記錄在本地MAC表中。之後，VTEP_1將解封裝後的報文發送給VM_A。
3.2 不同子網VM互通組網圖
VM_A和VM_B分別屬於10.1.10.0/24網段和10.1.20.0/24網段，且分別屬於VNI 5000和VNI 6000。VM_A和VM_B對應的三層網關分別是VTEP_3上BDIF 10和BDIF 20的IP地址。VTEP_3上存在到10.1.10.0/24網段和10.1.20.0/24網段的路由。此時，VM_A想與VM_B進行通信。
- 不同子網VM互通報文轉發流程
序號1： VM_A先將數據報文發送給網關。報文的源MAC爲MAC_A，目的MAC爲網關BDIF 10的MAC_10，源IP地址爲IP_A，目的IP爲IP_B。
序號2：VTEP_1收到數據報文後，識別此報文所屬的VNI（VNI 5000），並根據MAC表項對報文進行封裝。可以看到，這裏封裝的外層源IP地址爲本地VTEP的IP地址（IP_1），外層目的IP地址爲對端VTEP的IP地址（IP_3）；外層源MAC地址爲本地VTEP的MAC地址（MAC_1），而外層目的MAC地址爲去往目的IP的網絡中下一跳設備的MAC地址。
封裝後的報文，根據外層MAC和IP信息，在IP網絡中進行傳輸，直至到達對端VTEP。
序號3：報文進入VTEP_3，VTEP_3對報文進行解封裝，得到VM_A發送的原始報文。然後，VTEP_3會對報***如下處理：
l VTEP_3發現該報文的目的MAC爲本機BDIF 10接口的MAC，而目的IP地址爲IP_B（10.1.20.1），所以會根據路由表查找到IP_B的下一跳。
l 發現下一跳爲10.1.20.10，出接口爲BDIF 20。此時VTEP_3查詢ARP表項，並將原始報文的源MAC修改爲BDIF 20接口的MAC（MAC_20），將目的MAC修改爲VM_B的MAC（MAC_B）。
l 報文到BDIF 20接口時，識別到需要進入VXLAN隧道（VNI 6000），所以根據MAC表對報文進行封裝。這裏封裝的外層源IP地址爲本地VTEP的IP地址（IP_3），外層目的IP地址爲對端VTEP的IP地址（IP_2）；外層源MAC地址爲本地VTEP的MAC地址（MAC_3），而外層目的MAC地址爲去往目的IP的網絡中下一跳設備的MAC地址。
封裝後的報文，根據外層MAC和IP信息，在IP網絡中進行傳輸，直至到達對端VTEP。
AC表對報文進行封裝。這裏封裝的外層源IP地址爲本地VTEP的IP地址（IP_3），外層目的IP地址爲對端VTEP的IP地址（IP_2）；外層源MAC地址爲本地VTEP的MAC地址（MAC_3），而外層目的MAC地址爲去往目的IP的網絡中下一跳設備的MAC地址。
封裝後的報文，根據外層MAC和IP信息，在IP網絡中進行傳輸，直至到達對端VTEP。
序號4：報文到達VTEP_2後，VTEP_2對報文進行解封裝，得到內層的數據報文，並將其發送給VM_B。
原文：https://forum.huawei.com/enterprise/zh/thread-334207.html