云計算環境的一個典型屬性是多租戶共享物理資源。其中每個租戶可以構建自己專屬的虛擬邏輯網絡，而每個邏輯網絡都需要由唯一的標識符來標識。不同的邏輯網絡默認情況下相互隔離。傳統上，網絡工程師一般使用VLAN來隔離不同二層網絡，但VLAN的標識符命名空間只有12位，只能提供4096個標識符，這無法滿足大型云計算環境的需求。

另外，使用VLAN隔離虛擬邏輯網絡，往往需要對底層物理網絡設備進行手動配置，這無法滿足云計算環境的自動化需求。為了解決VLAN在網絡虛擬化環境中應用存在的種種問題，Cisco，VMware等廠商提出了新的網絡協議VXLAN來隔離虛擬邏輯網絡。

VxLAN基本原理

VXLAN的全稱為Virtual eXtensible LAN，從名稱看，它的目標就是擴展VLAN協議。802.1Q的VLAN TAG只占12位，只能提供4096個網絡標識符。而在VXLAN中，標識符擴展到24位，能提供16777216個邏輯網絡標識符，VXLAN的標識符稱為VNI(VXLAN Network Identifier)。另外，VLAN只能應用在一個二層網絡中，而VXLAN通過將原始二層以太網幀封裝在IP協議包中，在IP基礎網絡之上構建overlay的邏輯大二層網絡。

我們來看具體協議包結構。VXLAN將二層數據幀封裝在UDP數據包中，構建隧道在不同節點間通信。包結構如圖:

從包結構上可以看到，VXLAN會額外消耗50字節的空間。為了防止因數據包大小超過網絡設備的MTU值而被丟棄，需要將VM的MTU減少50甚至更多，或者調整中間網絡設備的MTU。

VXLAN協議中將對原始數據包進行封裝和解封裝的設備稱為VTEP(VXLAN Tunnel End Point)，它可以由硬件設備實現，也可以由軟件實現。

VXLAN的整體應用示意拓樸結構如圖:

我們來看VXLAN的通信過程。在上圖的虛擬機VM1和VM2處于邏輯二層網絡中。VM1發出的二層以太網幀由VTEP封裝進IP數據包，之后發送到VM2所在主機。VM2所在主機接收到IP報文后，解封裝出原始的以太網幀再轉發給VM2。

然而，VM1所在主機的VTEP做完數據封裝后，如何知道要將封裝后的數據包發到哪個VTEP呢？實際上，VTEP通過查詢轉發表來確定目標VTEP地址，而轉發表通過泛洪和學習機制來構建。目標MAC地址在轉發表中不存在的流量稱為未知單播(Unknown unicast)。廣播(broadcast)、未知單播(unknown unicast)和組播(multicast)一般統稱為BUM流量。VXLAN規范要求BUM流量使用IP組播進行洪泛，將數據包發送到除源VTEP外的所有VTEP。目標VTEP發送回響應數據包時，源VTEP從中學習MAC地址、VNI和VTEP的映射關系，并添加到轉發表中。后續VTEP再次發送數據包給該MAC地址時，VTEP會從轉發表中直接確定目標VTEP，從而只發送單播數據到目標VTEP。

OpenvSwitch沒有實現IP組播，而是使用多個單播來實現洪泛。洪泛流量本身對性能有一定影響，可以通過由controller收集相應信息來填充轉發表而避免洪泛。

Linux環境中常用的VXLAN實現有兩種:

Linux內核實現

OpenvSwitch實現接下來分別以實例來說明。

Linux 的實現

首先看Linux內核實現實例。我們的測試環境有三臺主機，物理網卡IP分別為192.168.33.12/24, 192.168.33.13/24和192.168.33.14/24。我們在每臺機器上創建一個Linux Bridge, 三臺主機上的Linux Bridge默認接口的IP分別設置為10.1.1.2/24, 10.1.1.3/24和10.1.1.4/24。此時三臺主機的Linux網橋處于同一虛擬二層網絡，但由于沒有相互連接，所以無法互相訪問。我們通過建立VXLAN隧道使其可互相訪問實現虛擬二層網絡10.1.1.0/24。網絡結構如圖:

首先在主機1上創建Linux網橋:

brctl?addbr?br0

給網橋接口設置IP并啟動:

ip?addr?add?10.1.1.2/24?dev?br0
ip?link?set?up?br0

我們從主機1訪問主機2上的虛擬二層網絡IP, 訪問失敗:

[root@localhost?vagrant]#?ping?10.1.1.3
PING?10.1.1.3?(10.1.1.3):?56?data?bytes
^C
---?10.1.1.3?ping?statistics?---
1?packets?transmitted,?0?packets?received,?100.0%?packet?loss

接下來，我們添加VTEP虛擬接口vxlan0, 并加入組播IP:239.1.1.1, 后續發送到該組播IP的數據包，該VTEP都可以接收到:

ip?link?add?vxlan0?type?vxlan?id?1?group?239.1.1.1?dev?eth1?dstport?4789

將虛擬接口vxlan0連接到網橋:

brctl?addif?br0?vxlan0

在另外兩臺主機上也完成相似配置后，我們開始測試。

首先在主機1查看VTEP的轉發表，可以看到此時只有一條組播條目，所有發出流量都將發送給該組播IP:

[root@localhost?vagrant]#?bridge?fdb?show?dev?vxlan0
000000:00?dst?239.1.1.1?via?eth1?self?permanent

我們再次從主機1上訪問主機2上的網橋IP, 此時訪問成功:

[root@localhost?vagrant]#?ping?10.1.1.3
PING?10.1.1.3?(10.1.1.3)?56(84)?bytes?of?data.
64?bytes?from?10.1.1.3:?icmp_seq=1?ttl=64?time=1.58?ms
64?bytes?from?10.1.1.3:?icmp_seq=2?ttl=64?time=0.610?ms
^C
---?10.1.1.3?ping?statistics?---
2?packets?transmitted,?2?received,?0%?packet?loss,?time?1001ms
rtt?min/avg/max/mdev?=?0.610/1.096/1.582/0.486?ms

此時再次在主機1上查看VTEP轉發表，可以看到轉發表中已經學習到10.1.1.3所在主機的VTEP地址:192.168.33.13，下次再發送數據給10.1.13所對應的MAC該直接發送到192.168.33.13:

[root@localhost?vagrant]#?bridge?fdb?show?dev?vxlan0
000000:00?dst?239.1.1.1?via?eth1?self?permanent
2ea27b:31?dst?192.168.33.13?self

我們根據主機2上tcpdump的抓包結果來分析具體過程:

1454.330846?IP?192.168.33.12.38538?>?239.1.1.1.4789:?VXLAN,?flags?[I]?(0x08),?vni?1
ARP,?Request?who-has?10.1.1.3?tell?10.1.1.2,?length?28

10.1.1.2所在主機不知道10.1.1.3對應的MAC地址，因而發送ARP廣播，ARP數據包發送至VTEP，VTEP進行封裝并洪泛給組播IP:239.1.1.1。

1454.330975?IP?192.168.33.13.58823?>?192.168.33.12.4789:?VXLAN,?flags?[I]?(0x08),?vni?1
ARP,?Reply?10.1.1.3?is-at?2ea27b:31,?length?28

主機2收到數據包之后解封裝，VTEP會學習數據包的MAC及VTEP地址，將其添加到轉發表，并將解封后的數據幀發送到網橋接口10.1.1.3。10.1.1.3的接口發送ARP響應。

1454.332055?IP?192.168.33.12.48980?>?192.168.33.13.4789:?VXLAN,?flags?[I]?(0x08),?vni?1
IP?10.1.1.2?>?10.1.1.3:?ICMP?echo?request,?id?4478,?seq?1,?length?64

主機1之后開始發送ICMP數據包，從這里可以看出外層IP地址不再為組播IP，而是學習到的192.168.33.13。

1454.332225?IP?192.168.33.13.55921?>?192.168.33.12.4789:?VXLAN,?flags?[I]?(0x08),?vni?1
IP?10.1.1.3?>?10.1.1.2:?ICMP?echo?reply,?id?4478,?seq?1,?length?64

接著，10.1.1.3發送回ICMP響應包。

OvS 的實現

下面再來說明OpenvSwitch實現實例。

OVS不支持組播，需要為任意兩個主機之間建立VXLAN單播隧道。與上邊示例的拓樸結構相比，我們使用了兩個OVS網橋，將虛擬邏輯網絡的接口接入網橋br-int，將所有VXLAN接口接入br-tun。兩個網橋使用PATCH類型接口進行連接。由于網橋br-tun上有多個VTEP，當BUM數據包從其中某個VTEP流入時，數據包會從其他VTEP接口再流出，這會導致數據包在主機之間無限循環。因而我們需要添加流表使VTEP流入的數據包不再轉發至其他VTEP。若邏輯網絡接口與VTEP連接同一網橋，配置流表將比較繁瑣。單獨將邏輯網絡接口放到獨立的網橋上，可以使流表配置非常簡單，只需要設置VTEP流入的數據包從PATCH接口流出。

拓樸結構如圖:

首先在主機1上創建網橋br-int和br-tun:

ovs-vsctl?add-br?br-int
ovs-vsctl?add-br?br-tun

創建PATCH接口連接br-int和br-tun:

ovs-vsctl?add-port?br-int?patch-int?--?set?interface?patch-int?type=patch?options:peer=patch-tun
ovs-vsctl?add-port?br-tun?patch-tun?--?set?interface?patch-tun?type=patch?options:peer=patch-int

創建單播VTEP連接主機2:

ovs-vsctl?add-port?br-tun?vxlan0?--?set?interface?vxlan0?type=vxlan?options:remote_ip=192.168.33.13

創建單播VTEP連接主機3:

ovs-vsctl?add-port?br-tun?vxlan1?--?set?interface?vxlan1?type=vxlan?options:remote_ip=192.168.33.14

接下來，我們給br-tun添加流表來處理流量。

首先查看br-tun上各接口的PORT ID，從結果看到Patch Port為1，VTEP分別為5和6:

[root@localhost?vagrant]#?ovs-ofctl?show?br-tun
OFPT_FEATURES_REPLY?(xid=0x2):?dpid:00006e12f4fd6949
n_tables:254,?n_buffers:256
capabilities:?FLOW_STATS?TABLE_STATS?PORT_STATS?QUEUE_STATS?ARP_MATCH_IP
actions:?output?enqueue?set_vlan_vid?set_vlan_pcp?strip_vlan?mod_dl_src?mod_dl_dst?mod_nw_src?mod_nw_dst?mod_nw_tos?mod_tp_src?mod_tp_dst
1(patch-tun):?addrfafbbf
?????config:?????0
?????state:??????0
?????speed:?0?Mbps?now,?0?Mbps?max
5(vxlan0):?addr6585ea
?????config:?????0
?????state:??????0
?????speed:?0?Mbps?now,?0?Mbps?max
6(vxlan1):?addr38fa98
?????config:?????0
?????state:??????0
?????speed:?0?Mbps?now,?0?Mbps?max
LOCAL(br-tun):?addr12fd49
?????config:?????PORT_DOWN
?????state:??????LINK_DOWN
?????speed:?0?Mbps?now,?0?Mbps?max
OFPT_GET_CONFIG_REPLY?(xid=0x4):?frags=normal?miss_send_len=0

清空br-tun流表:

ovs-ofctl?del-flows?br-tun

數據包進入br-tun后開始匹配table 0的流。我們使用table 0區分流量來源。來源于br-int的數據包由table 1處理，VTEP流入的數據交由table 2處理, 并丟棄其他PORT進入的數據包:

ovs-ofctl?add-flow?br-tun?"table=0,priority=1,in_port=1?actions=resubmit(,1)”
ovs-ofctl?add-flow?br-tun?"table=0,priority=1,in_port=5?actions=resubmit(,2)"?
ovs-ofctl?add-flow?br-tun?"table=0,priority=1,in_port=6?actions=resubmit(,2)”
ovs-ofctl?add-flow?br-tun?"table=0,priority=0,actions=drop”

接著添加table 1的流, table 1用于處理來自br-int的流量，單播數據包交由table 20處理，多播或廣播數據包交由table 21處理:

ovs-ofctl?add-flow?br-tun?"table=1,priority=0,dl_dst=000000:00/010000:00,actions=resubmit(,20)”
ovs-ofctl?add-flow?br-tun?"table=1,priority=0,dl_dst=010000:00/010000:00,actions=resubmit(,21)”

table 21處理廣播流量，將數據包從所有VTEP的PORT口發出:

ovs-ofctl?add-flow?br-tun?"table=21,priority=0,actions=output:5,output:6”

table 2處理VTEP流入的數據包，在這里我們實現學習機制。來自VTEP的數據包到達后，table 2從中學習MAC地址，VNI、PORT信息，并將學習到的流寫入table 20中，并將流量由PATCH口發送到br-int上, 并將學習到的流優先級設為1:

ovs-ofctl?add-flow?br-tun?"table=2,priority=0,actions=learn(table=20,hard_timeout=300,priority=1,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),?output:1”

table 20處理單播流量，我們將默認流優先級設置為0。因為學習到的流優先級設置為1，因而只有匹配不到目標MAC的未知單播交由table 21處理，table 21將流量廣播到所有VTEP:

ovs-ofctl?add-flow?br-tun?"table=20,priority=0,actions=resubmit(,21)"

整體處理邏輯如圖:

我們查看流表, 發現table 20中只有一條默認添加的流:

[root@localhost?vagrant]#?ovs-ofctl?dump-flows?br-tun?table=20
NXST_FLOW?reply?(xid=0x4):
cookie=0x0,?duration=1.832s,?table=20,?n_packets=0,?n_bytes=0,?idle_age=1,?priority=0?actions=resubmit(,21)

我們從主機1訪問主機3上的虛擬網絡IP，訪問成功:

[root@localhost?vagrant]#?ping?10.1.1.4?-c?2
PING?10.1.1.4?(10.1.1.4)?56(84)?bytes?of?data.
64?bytes?from?10.1.1.4:?icmp_seq=1?ttl=64?time=1.45?ms
64?bytes?from?10.1.1.4:?icmp_seq=2?ttl=64?time=0.538?ms

---?10.1.1.4?ping?statistics?---
2?packets?transmitted,?2?received,?0%?packet?loss,?time?1002ms
rtt?min/avg/max/mdev?=?0.538/0.994/1.451/0.457?ms

我們再次查看流表, 發現table 20中已經多了一條學習到的流，下次再向該MAC發送數據包，數據將直接從PORT 6中發出:

[root@localhost?vagrant]#?ovs-ofctl?dump-flows?br-tun?table=20
NXST_FLOW?reply?(xid=0x4):
cookie=0x0,?duration=164.902s,?table=20,?n_packets=36,?n_bytes=3360,?hard_timeout=300,?idle_age=19,?hard_age=19,?priority=1,dl_dst=ee090e:46?actions=load:0->NXM_NX_TUN_ID[],output:6
cookie=0x0,?duration=223.811s,?table=20,?n_packets=1,?n_bytes=98,?idle_age=164,?priority=0?actions=resubmit(,21)

本文簡要介紹了VXLAN的原理和實例。

編輯：黃飛