VXLAN 基礎教程：VXLAN 協議原理介紹

VXLAN（Virtual eXtensible Local Area Network，虛擬可擴展局域網），是一種虛擬化隧道通信技術，它是一種 Overlay（覆寫網路）技術，通過三層的網路來搭建虛擬的二層網路，

簡單來講，VXLAN 是在底層物理網路（underlay）之上使用隧道技術，借助 UDP 層構建的 Overlay 的邏輯網路，使邏輯網路與物理網路解耦，實作靈活的組網需求，它對原有的網路架構幾乎沒有影響，不需要對原網路做任何改動，即可架設一層新的網路，也正是因為這個特性，很多 CNI 插件（Kubernetes 集群中的容器網路介面，這個大家應該都知道了吧，如果你不知道，現在你知道了）才會選擇 VXLAN 作為通信網路，

VXLAN 不僅支持一對一，也支持一對多，一個 VXLAN 設備能通過像網橋一樣的學習方式學習到其他對端的 IP 地址，還可以直接配置靜態轉發表，

一個典型的資料中心 VXLAN 網路拓撲圖如圖所示：

其中 VM 指的是虛擬機，Hypervisor 指的是虛擬化管理器，

1. 為什么需要 VXLAN？

與 VLAN 相比，VXLAN 很明顯要復雜很多，再加上 VLAN 的先發優勢，已經得到了廣泛的支持，那還要 VXLAN 干啥？

VLAN ID 數量限制

VLAN tag 總共有 4 個位元組，其中有 12 bit 用來標識不同的二層網路（即 LAN ID），故而最多只能支持 \(2^{12}\)，即 4096 個子網的劃分，而虛擬化（虛擬機和容器）的興起使得一個資料中心會有成千上萬的機器需要通信，這時候 VLAN 就無法滿足需求了，而 VXLAN 的報文 Header 預留了 24 bit 來標識不同的二層網路（即 VNI，VXLAN Network Identifier），即 3 個位元組，可以支持 \(2^{24}\) 個子網，

交換機 MAC 地址表限制

對于同網段主機的通信而言，報文到底交換機后都會查詢 MAC 地址表進行二層轉發，資料中心虛擬化之后，VM 的數量與原有的物理機相比呈數量級增長，而應用容器化之后，容器與 VM 相比也是呈數量級增長，，，而交換機的記憶體是有限的，因而 MAC 地址表也是有限的，隨著虛擬機（或容器）網卡 MAC 地址數量的空前增加，交換機表示壓力山大啊！

而 VXLAN 就厲害了，它用 VTEP（后面會解釋）將二層以太網幀封裝在 UDP 中，一個 VTEP 可以被一個物理機上的所有 VM（或容器）共用，一個物理機對應一個 VTEP，從交換機的角度來看，只是不同的 VTEP 之間在傳遞 UDP 資料，只需要記錄與物理機數量相當的 MAC 地址表條目就可以了，一切又回到了和從前一樣，

虛機或容器遷移范圍受限

VLAN 與物理網路融合在一起，不存在 Overlay 網路，帶來的問題就是虛擬網路不能打破物理網路的限制，舉個例子，如果要在 VLAN 100 部署虛擬機（或容器），那只能在支持 VLAN 100 的物理設備上部署，

VLAN 其實也有解決辦法，就是將所有的交換機 Trunk 連接起來，產生一個大的二層，這樣帶來的問題就是廣播域過分擴大，也包括更多未知的單播和多播，即 BUM（Broadcast，Unknown Unicast，Multicast），同時交換機 MAC 地址表也會有承受不住的問題，

而 VXLAN 將二層以太網幀封裝在 UDP 中（上面說過了），相當于在三層網路上構建了二層網路，這樣不管你物理網路是二層還是三層，都不影響虛擬機（或容器）的網路通信，也就無所謂部署在哪臺物理設備上了，可以隨意遷移，

總的來說，傳統二層和三層的網路在應對這些需求時變得力不從心，雖然很多改進型的技術比如堆疊、SVF、TRILL 等能夠增加二層的范圍，努力改進經典網路，但是要做到對網路改動盡可能小的同時保證靈活性卻非常困難，為了解決這些問題，有很多方案被提出來，Overlay 就是其中之一，而 VXLAN 是 Overlay 的一種典型的技術方案，下面就對 Overlay 做一個簡要的介紹，

2. Overlay 是個啥？

Overlay 在網路技術領域，指的是一種網路架構上疊加的虛擬化技術模式，其大體框架是對基礎網路不進行大規模修改的條件下，實作應用在網路上的承載，并能與其它網路業務分離，并且以基于 IP 的基礎網路技術為主，

IETF 在 Overlay 技術領域提出 VXLAN、NVGRE、STT 三大技術方案，大體思路均是將以太網報文承載到某種隧道層面，差異性在于選擇和構造隧道的不同，而底層均是 IP 轉發，VXLAN 和 STT 對于現網設備而言對流量均衡要求較低，即負載鏈路負載分擔適應性好，一般的網路設備都能對 L2-L4 的資料內容引數進行鏈路聚合或等價路由的流量均衡，而 NVGRE 則需要網路設備對 GRE 擴展頭感知并對 flow ID 進行 HASH，需要硬體升級；STT 對于 TCP 有較大修改，隧道模式接近 UDP 性質，隧道構造技術屬于革新性，且復雜度較高，而 VXLAN 利用了現有通用的 UDP 傳輸，成熟性極高，

總體比較，VLXAN 技術具有更大優勢，而且當前 VLXAN 也得到了更多廠家和客戶的支持，已經成為 Overlay 技術的主流標準，

3. VXLAN 協議原理

VXLAN 有幾個常見的術語：

• VTEP（VXLAN Tunnel Endpoints，VXLAN 隧道端點）

  VXLAN 網路的邊緣設備，用來進行 VXLAN 報文的處理（封包和解包），VTEP 可以是網路設備（比如交換機），也可以是一臺機器（比如虛擬化集群中的宿主機），

• VNI（VXLAN Network Identifier，VXLAN 網路識別符號）

  VNI 是每個 VXLAN 段的標識，是個 24 位整數，一共有 \(2^{24} = 16777216\)（一千多萬），一般每個 VNI 對應一個租戶，也就是說使用 VXLAN 搭建的公有云可以理論上可以支撐千萬級別的租戶，

• Tunnel（VXLAN 隧道）

  隧道是一個邏輯上的概念，在 VXLAN 模型中并沒有具體的物理物體向對應，隧道可以看做是一種虛擬通道，VXLAN 通信雙方認為自己是在直接通信，并不知道底層網路的存在，從整體來說，每個 VXLAN 網路像是為通信的虛擬機搭建了一個單獨的通信通道，也就是隧道，

上圖所示為 VXLAN 的作業模型，它創建在原來的 IP 網路（三層）上，只要是三層可達（能夠通過 IP 相互通信）的網路就能部署 VXLAN，在 VXLAN 網路的每個端點都有一個 VTEP 設備，負責 VXLAN 協議報文的解包和封包，也就是在虛擬報文上封裝 VTEP 通信的報文頭部，

物理網路上可以創建多個 VXLAN 網路，可以將這些 VXLAN 網路看成一個隧道，不同節點上的虛擬機/容器能夠通過隧道直連，通過 VNI 標識不同的 VXLAN 網路，使得不同的 VXLAN 可以相互隔離，

VXLAN 的報文結構如下圖所示：

• VXLAN Header : 在原始二層幀的前面增加 8 位元組的 VXLAN 的頭部，其中最主要的是 VNID，占用 3 個位元組（即 24 bit），類似 VLAN ID，可以具有 \(2^{24}\) 個網段，

• UDP Header : 在 VXLAN 和原始二層幀的前面使用 8 位元組 UDP 頭部進行封裝（MAC IN UDP），目的埠號預設使用 4789，源埠按流隨機分配（通過 MAC，IP，四層埠號進行 hash 操作）， 這樣可以更好的做 ECMP，

  IANA（Internet As-signed Numbers Autority）分配了 4789 作為 VXLAN 的默認目的埠號，

在上面添加的二層封裝之后，再添加底層網路的 IP 頭部（20 位元組）和 MAC 頭部（14 位元組），這里的 IP 和 MAC 是宿主機的 IP 地址和 MAC 地址，

同時，這里需要注意 MTU 的問題，傳統網路 MTU 一般為 1500，這里加上 VXLAN 的封裝多出的（36+14/18，對于 14 的情況為 access 口，省去了 4 位元組的 VLAN Tag）50 或 54 位元組，需要調整 MTU 為 1550 或 1554，防止頻繁分包，

VXLAN 的 Flood 與 Learn

總的來說，VXLAN 報文的轉發程序就是：原始報文經過 VTEP，被 Linux 內核添加上 VXLAN 頭部以及外層的 UDP 頭部，再發送出去，對端 VTEP 接收到 VXLAN 報文后拆除外層 UDP 頭部，并根據 VXLAN 頭部的 VNI 把原始報文發送到目的服務器，但這里有一個問題，第一次通信前雙方如何知道所有的通信資訊？這些資訊包括：

• 哪些 VTEP 需要加到一個相同的 VNI 組？
• 發送方如何知道對方的 MAC 地址？
• 如何知道目的服務器在哪個節點上（即目的 VTEP 的地址）？

第一個問題簡單，VTEP 通常由網路管理員來配置，要回答后面兩個問題，還得回到 VXLAN 協議的報文上，看看一個完整的 VXLAN 報文需要哪些資訊：

• 內層報文 : 通信雙方的 IP 地址已經明確，只需要 VXLAN 填充對方的 MAC 地址，因此需要一個機制來實作 ARP 功能，

• VXLAN 頭部 : 只需要知道 VNI，一般直接配置在 VTEP 上，要么提前規劃，要么根據內層報文自動生成，

• UDP 頭部 : 需要知道源埠和目的埠，源埠由系統自動生成，目的埠默認是 4789，

• IP 頭部 : 需要知道對端 VTEP 的 IP 地址，這個是最關鍵的部分，

  實際上，VTEP 也會有自己的轉發表，轉發表通過泛洪和學習機制來維護，對于目標 MAC 地址在轉發表中不存在的未知單播，廣播流量，都會被泛洪給除源 VTEP 外所有的 VTEP，目標 VTEP 回應資料包后，源 VTEP 會從資料包中學習到 MAC，VNI 和 VTEP 的映射關系，并添加到轉發表中，后續當再有資料包轉發到這個 MAC 地址時，VTEP 會從轉發表中直接獲取到目標 VTEP 地址，從而發送單播資料到目標 VTEP，

  

  VTEP 轉發表的學習可以通過以下兩種方式：

  • 多播
  • 外部控制中心（如 Flannel、Cilium 等 CNI 插件）

• MAC 頭部 : 確定了 VTEP 的 IP 地址，后面就好辦了，MAC 地址可以通過經典的 ARP 方式獲取，

4. Linux 的 VXLAN

Linux 對 VXLAN 協議的支持時間并不久，2012 年 Stephen Hemminger 才把相關的作業合并到 kernel 中，并最終出現在 kernel 3.7.0 版本，為了穩定性和很多的功能，可能會看到某些軟體推薦在 3.9.0 或者 3.10.0 以后版本的 kernel 上使用 VXLAN，

到了 kernel 3.12 版本，Linux 對 VXLAN 的支持已經完備，支持單播和組播，IPv4 和 IPv6，利用 man 查看 ip 的 link 子命令，可以查看是否有 VXLAN type：

$ man ip-link

搜索 VXLAN，可以看到如下描述：

管理 VXLAN 介面

Linux VXLAN 介面的基本管理如下：

1. 創建點對點的 VXLAN 介面：

   $ ip link add vxlan0 type vxlan id 4100 remote 192.168.1.101 local 192.168.1.100 dstport 4789 dev eth0
   

   其中 id 為 VNI，remote 為遠端主機的 IP，local 為你本地主機的 IP，dev 代表 VXLAN 資料從哪個介面傳輸，

   在 VXLAN 中，一般將 VXLAN 介面（本例中即 vxlan0）叫做 VTEP，

2. 創建多播模式的 VXLAN 介面：

   $ ip link add vxlan0 type vxlan id 4100 group 224.1.1.1 dstport 4789 dev eth0
   

   多播組主要通過 ARP 泛洪來學習 MAC 地址，即在 VXLAN 子網內廣播 ARP 請求，然后對應節點進行回應，group 指定多播組的地址，

3. 查看 VXLAN 介面詳細資訊：

   $ ip -d link show vxlan0
   

FDB 表

FDB（Forwarding Database entry，即轉發表）是 Linux 網橋維護的一個二層轉發表，用于保存遠端虛擬機/容器的 MAC地址，遠端 VTEP IP，以及 VNI 的映射關系，可以通過 bridge fdb 命令來對 FDB 表進行操作：

• 條目添加：

  $ bridge fdb add <remote_host_mac> dev <vxlan_interface> dst <remote_host_ip>
  

• 條目洗掉：

  $ bridge fdb del <remote_host_mac> dev <vxlan_interface>
  

• 條目更新：

  $ bridge fdb replace <remote_host_mac> dev <vxlan_interface> dst <remote_host_ip>
  

• 條目查詢：

  $ bridge fdb show
  

5. 總結

本文通過介紹 VXLAN 出現的時代背景、VXLAN 的概念和網路模型、VXLAN 報文結構，讓你對 VXLAN 有了初步的認識；通過介紹 VXLAN 轉發表的泛洪和學習，讓你知道了通信雙方如何感知對方；最后介紹了 Linux 中 VXLAN 的基本配置，讓你進一步了解如何在 Linux 中玩轉 VXLAN，下一篇文章將會通過實戰來說明如何搭建基于 VXLAN 的 Overlay 網路，順便展開解讀上文提到的多播和外部控制中心的作業原理，

6. 參考資料

• vxlan 協議原理簡介
• VXLAN vs VLAN

微信公眾號

掃一掃下面的二維碼關注微信公眾號，在公眾號中回復?加群?即可加入我們的云原生交流群，和孫宏亮、張館長、陽明等大佬一起探討云原生技術

標籤：其他

上一篇：公司使用的軟體的小問題求助

下一篇：Kubernetes Logs 如何獲取kube-system pod的日志