介紹前，首先講一下網絡中underlay和overlay的概念。underlay指的是實體網絡層，overlay是指在實體網絡層之上的邏輯網絡或者又稱為虛拟網絡。overlay是建立在underlay的基礎上，需要實體網絡中的裝置兩兩互聯，overlay的出現突破了underlay的實體局限性，使得網絡的架構更為靈活。以vlan為例，在underlay環境下不同網絡的裝置需要連接配接至不同的交換機下，如果要改變裝置所屬的網絡，則要調整裝置的連線。引入vlan後，調整裝置所屬網絡隻需要将裝置加入目标vlan下，避免了裝置的連線調整。
vlan id數量不足
vlan header由12bit組成，理論上限為4096個，可用vlan數量為1~4094個，無法滿足雲環境下的需求。
vm熱遷移
雲計算場景下，傳統伺服器變成一個個運作在主控端上的vm。vm是運作在主控端的記憶體中，是以可以在不中斷的情況下從主控端A遷移到主控端B，前提是遷移前後vm的ip和mac位址不能發生變化，這就要求vm處在一個二層網絡。畢竟在三層環境下，不同vlan使用不同的ip段，否則路由器就犯難了。
mac表項有限
普通的交換機mac表項有4k或8k等，在小規模場景下不會成為瓶頸，雲計算環境下每台實體伺服器上運作多台vm，每個vm有可能有多張vnic，mac位址會成倍增長，交換機的表項限制則成為必須面對的問題。
以多取勝
vxlan header由24bit組成，是以理論上VNI的數量為16777216個，解決了vid數量不足的問題。
此處需要說明的是：在openstack中，盡管br-tun上的vni數量增多，但br-int上的網絡類型隻能是vlan，所有vm都有一個内外vid（vni）轉換的過程，将使用者層的vni轉換為本地層的vid。
細心的你可能會有這樣的疑問：盡管br-tun上vni的數量為16777216個，但br-int上vid隻有4096個，那引入vxlan是否有意義？答案是肯定的，以目前的實體機計算能力來說，假設每個vm屬于不同的tenant，1台實體機上也不可能運作4094個vm，是以這麼映射是有意義的。
上圖是2計算節點間vm通信的示意圖，圖中所有的vm屬于同一個tenant，盡管在使用者層同一tenant的vni一緻，但在本地層，同一tenant由nova-compute配置設定的vid可以不一緻，同一主控端上同一tenant的相同subnet之間的vm互相通路不需要經過内外vid（vni）轉換，不同主控端上相同tenant的vm之間互相通路則需要經過vid（vni）轉換。如果所有主控端上vid和vni對應關系一緻，整個雲環境最多隻能有4094個tenant，引入vxlan才真的沒有意義。
暗渡陳倉
前面說過，vm的熱遷移需要遷移前後ip和mac位址不能發生管改變，是以需要vm處于一個二層網絡中。vxlan是一種overlay的技術，将原有的封包進行再次封裝，利用udp進行傳輸，是以也稱為mac in udp，表面上傳輸的是封裝後的ip和mac，實際傳播的是封裝前的ip和mac。
銷聲匿迹
在雲環境下，接入交換機的表項大小會成為瓶頸，解決這個問題的方法無外乎兩種：
1.擴大表項 ： 更進階的交換機有着更大的表項，使用進階交換機取代原有接入交換機，此舉會增加成本。
2.隐藏mac位址： 在不增加成本的前提下，使用vxlan也能達到同樣的效果。前文得知，vxlan是對原有的封包再次封裝，實作vxlan功能的vetp角色可以位于交換機或者vm所在的主控端，如果vtep角色位于主控端上，接入交換機隻會學習經過再次封裝後vtep的mac位址，不會學習其上vm的mac位址。
如果vtep角色位于接入交換機上，處理封包的效率更高，但是接入交換機會學習到vm的mac位址，表項的限制依然沒有得到解決，後續對這兩種情況會做詳細說明。
以上就是openstack場景中使用vxlan的原因，下面将會對vxlan的實作原理進行詳細說明。
vxlan封包長什麼樣
vxlan封包是在原有封包的基礎上再次進行封裝，已實作三層傳輸二層的目的。
如上圖所示，原有封裝後的封包成為vxlan的data部分，vxlan header為vni，ip層header為源和目的vtep位址，鍊路層header為源vtep的mac位址和到目的vtep的下一個裝置mac位址。
在筆者所從事的公有雲架構中，vtep角色通過主控端上的ovs實作，主控端上聯至接入交換機的接口類型為trunk，在實體網絡中為vtep專門規劃出一個網絡平面
vm在經過vtep時，通過流表規則，去除vid，添加上vni
vtep平面規劃的vid在vxlan的封裝過程中被打上，原因如下圖所示，vxlan的mac header中可以設定vlan tag
vtep是什麼
vtep全稱vxlan tunnel endpoint，vxlan可以抽象的了解為在三層網絡中打通了一條條隧道，起點和終點的兩端就是vetp。vtep是實作vxlan功能的重要模型，可以部署在接入交換機或者伺服器上，部署在不同的位置除了前文中提到是否學習vm的mac位址外，實作的機制也所有不同，以下内容如無特别說明，預設vtep部署在接入交換機上，vtep部署在伺服器上後面會單獨說明。
vxlan隧道的建立
對于實體交換機而言，vtep是實體交換機上的一個角色，換句話說，vtep隻是交換機上的一部分功能，并非所有的封包都需要走vxlan隧道，封包也可能走普通的二三層轉發。那麼哪些封包需要走vxlan隧道？
如上圖所示，vxlan打造了一個大二層的概念，當連接配接兩個不同vtep的vm需要進行通信時，就需要建立vxlan隧道。每一個大二層域稱為一個bridge-domain，簡稱bd，類似于vlan的vid，不同的bd用vni表示，bd與vni是1:1的關系。
建立bd和設定bd與vni對應關系的配置如下：
vtep會根據以上配置生成bd與vni的映射關系表，該映射表可以通過指令行檢視，如下所示：
有了映射表後，進入vtep的封包就可以根據自己所屬的bd來确定封包封裝時該添加哪個vni。問題就剩下封包根據什麼來确定自己屬于哪個bd。
它可以通過二層子接口接入vxlan隧道和vlan接入vxlan隧道來實作。二層子接口主要做兩件事：一是根據配置來檢查哪些封包需要進入vxlan隧道；二是判斷對檢查通過的封包做怎樣的處理。
如上圖所示，基于二層實體接口10GE 1/0/1，分别建立二層子接口10GE 1/0/1.1和10GE 1/0/1.2，且分别配置其流封裝類型為dot1q和untag。配置如下：
基于二層實體接口10GE 1/0/2，建立二層子接口10GE 1/0/2.1，且流封裝類型為default。配置如下：
至此，所有條件都已具備，就可以通過協定自動建立vxlan隧道隧道，或者手動指定vxlan隧道的源和目的ip位址在本端vtep和對端vtep之間建立靜态vxlan隧道。對于華為CE系列交換機，以上配置是在nve（network virtualization Edge）接口下完成的。配置過程如下：
其中，vni 5000的對端vtep有兩個，ip位址分别為2.2.2.2和2.2.2.3，至此，vxlan隧道建立完成。
VXLAN隧道兩端二層子接口的配置并不一定是完全對等的。正因為這樣，才可能實作屬于同一網段但是不同VLAN的兩個VM通過VXLAN隧道進行通信。
總結一下，vxlan目前支援三種封裝類型，如下表所示：
這種方法當有衆多個vni的時候，需要為每一個vni建立一個子接口，會變得非常麻煩。
此時就應該采用vlan接入vxlan隧道的方法。vlan接入vxlan隧道隻需要在實體接口下允許攜帶這些vlan的封包通過，然後再将vlan與bd綁定，建立bd與vni對應的bd資訊，最後建立vxlan隧道即可。
vlan與bd綁定的配置如下：
同子網vxlan通信流程
如上圖所示，假設vtep是通過接入交換機上的子接口實作，VM_A與VM_C進行首次進行通信。由于是，VM_A上沒有VM_C的MAC位址，是以會發送ARP廣播封包請求VM_C的MAC位址。就以ARP請求封包及ARP應答封包的轉發流程，來說明MAC位址是如何進行學習的。
ARP請求封包的轉發流程如下：
1. VM_A發送源MAC為MAC_A、目的MAC為全F、源IP為IP_A、目的IP為IP_C的ARP廣播封包，請求VM_C的MAC位址。
2. VTEP_1收到這種BUM（Broadcast&Unknown-unicast&Multicast）請求後，會根據頭端複制清單對封包進行複制，并分别進行封裝。根據二層子接口上的配置判斷封包需要進入VXLAN隧道。确定了封包所屬BD後，也就确定了封包所屬的VNI。同時，VTEP_1學習MAC_A、VNI和封包入接口（Port_1，即二層子接口對應的實體接口）的對應關系，并記錄在本地MAC表中。
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應答封包轉發流程如下圖所示：
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。
至此，VM_A和VM_C均已學習到了對方的MAC位址。之後，VM_A和VM_C将采用單點傳播方式進行通信。
不同子網vxlan通信流程
如上圖所示，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和BDIF20的IP位址（BDIF接口的功能與VLANIF接口類似，是基于BD建立的三層邏輯接口，用以實作不同子網VM之間或VXLAN網絡與非VXLAN網絡之間的通信。）。VTEP_3上存在到10.1.10.0/24網段和10.1.20.0/24網段的路由。此時，VM_A想與VM_B進行通信。
由于是首次進行通信，且VM_A和VM_B處于不同網段，VM_A需要先發送ARP廣播封包請求網關（BDIF 10）的MAC，獲得網關的MAC後，VM_A先将資料封包發送給網關；之後網關也将發送ARP廣播封包請求VM_B的MAC，獲得VM_B的MAC後，網關再将資料封包發送給VM_B。以上MAC位址學習的過程與同子網互通中MAC位址學習的流程一緻，不再贅述。現在假設VM_A和VM_B均已學到網關的MAC、網關也已經學到VM_A和VM_B的MAC，不同子網VM互通封包轉發流程如下圖所示：
1. VM_A先将資料封包發送給網關。封包的源MAC為MAC_A，目的MAC為網關BDIF10的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位址。
3. 封包進入VTEP_3，VTEP_3對封包進行解封裝，得到VM_A發送的原始封包。然後，VTEP_3會對封包做如下處理：
（1） VTEP_3發現該封包的目的MAC為本機BDIF 10接口的MAC，而目的IP位址為IP_B（10.1.20.1），是以會根據路由表查找到IP_B的下一跳。
（2） 發現下一跳為10.1.20.10，出接口為BDIF 20。此時VTEP_3查詢ARP表項，并将原始封包的源MAC修改為BDIF 20接口的MAC（MAC_20），将目的MAC修改為VM_B的MAC（MAC_B）。
（3） 封包到BDIF20接口時，識别到需要進入VXLAN隧道（VNI 6000），是以根據MAC表對封包進行封裝。這裡封裝的外層源IP位址為本地VTEP的IP位址（IP_3），外層目的IP位址為對端VTEP的IP位址（IP_2）；外層源MAC位址為本地VTEP的MAC位址（MAC_3），而外層目的MAC位址為去往目的IP的網絡中下一跳裝置的MAC位址。
4. 封包到達VTEP_2後，VTEP_2對封包進行解封裝，得到内層的資料封包，并将其發送給VM_B。VM_B回應VM_A的流程與上述過程類似，不再贅述。
需要說明的是：VXLAN網絡與非VXLAN網絡之間的互通，也需要借助于三層網關。其實作不同點在于封包在VXLAN網絡側會進行封裝，而在非VXLAN網絡側不需要進行封裝。封包從VXLAN側進入網關并解封裝後，就按照普通的單點傳播封包發送方式進行轉發。
ovs如何建立vxlan隧道
從前文得知，vtep部署在接入交換機上時還是會學習到vm的mac位址，并沒有解決表項限制問題，這也是為什麼在公有雲場景下vtep角色都是部署在主控端的ovs中。
不同于在接入交換機上通過手動的方式建立vxlan隧道，openstack中負責網絡的neutron-server啟動後，會自己建立隧道，下面來介紹neutron-server如何自動建立隧道。
如上圖所示，每個主控端上的ovs是由ovs-aget建立，當計算節點1接入網絡中時，他首先會去向neutron-server報告自己的網絡類型和local_ip，neutron-server收到這些資源資訊後（neutron中network、port、subnet都稱為資源）會進行處理，找到相同網絡類型的其他計算節點并為他們之間建立隧道，同時将這個消息同步給其他計算節點上的ovs-agent。
每當neutron資源發生變化時，或者ovs對流量不知該處和處理時，都會像neutron-server彙報或等待它的通知，再加上之前的流表，是不是感覺很熟悉？沒錯，neutron-server除了接受api請求外，他還是一個sdn控制器。
與接入交換機實作vtep的差別
1. 使用ovs實作的vtep接入交換機隻會學習經過vtep封裝後的mac位址，學習不到vm的mac位址，這樣解決了mack位址表項的問題。
2. 實體交換機是通過bd和vni綁定的方法建立不同的隧道，ovs實作時每一個vtep内可以有多個vsi（virtual switch instance），每一個vsi對用一個vni。
以上就是vxlan在openstack中通過實體裝置或者ovs實作的方式。