NVo3（Network Virtualization over Layer 3），是IETF 2014年十月份提出的資料中心虛擬化技術框架。NVo3基於IP/MPLS作為傳輸網，在其上通過隧道連線的方式，構建大規模的二層租戶網路。NVo3的技術模型如下所示，PE裝置稱為NVE（Network Virtualization Element），VN Context作為Tag標識租戶網路，P裝置即為普通的IP/MPLS路由器。NVo3在設計之初，VxLAN與SDN的聯合部署已經成為了資料中心的大趨勢，因此NVo3的模型中專門畫出了NVA（Network Virtualization Authority）作為NVE裝置的控制器負責隧道建立、地址學習等控制邏輯。

NVo3的思想起源於VxLAN，結合NVGRE和STT的發展，目前收斂為Geneve。上述技術都是端到端的隧道，CE為虛擬機器或物理伺服器，其實單純地從NVo3的模型角度來看，後面要介紹的OTV/EVN/EVI這些DC間互聯的隧道技術都屬於NVo3的框架中。本專題將對端到端的NVo3技術進行深入的介紹。

1)VxLAN

VxLAN（Virtual eXtensible LAN，RFC 7348），是Vmware和Cisco聯合提出的一種大二層技術，突破了VLAN ID只有4k的限制，允許通過現有的IP網路進行隧道的傳輸。別看VxLAN名字聽起來和VLAN挺像，但是兩者技術上可沒什麼必然聯絡。VxLAN是一種MACinUDP的隧道，下面是VxLAN的報頭。

VxLAN封裝的是乙太網幀，外層的報頭可以為IPv4也可以為IPv6。UDP Src Port是外層UDP的源埠號，它的值通過hash得到，常用來實現ECMP；Dst Port為VxLAN從IANA申請的埠4789；UDP checksum如果不為0，出口VTEP（VxLAN的NVE）必須進行計算，計算結果必須與該欄位一致才能進行解封裝，不一致則進行丟棄，checksum如果為0，則出口VTEP無條件解封裝；VNI是VxLAN的VN Context，長度為24位，支援16 million的租戶；後面是CE送出來的Ethernet原始幀，VxLAN GW對其中的VLAN tag有所要求。

NVo3技術中，NVE上的地址學習包括兩類：第一類是學習本地VM的MAC與port的對映關係，第二類是學習遠端VM的MAC地址與該VM所在NVE的IP地址的對映關係。標準VxLAN的地址學習仍為二層的自學習演算法，通過組播在VTEP間泛洪。標準VxLAN的通訊流程如下例所示。

首先，VTEP通過IGMP加入VNI 1的組播組，VNI 1中的BUM流量都將通過該組播組傳輸。虛擬機器A與B間通訊具體轉發流程如下：VM A傳送ARP請求，VTEP 1學習VM A的本地連線埠，然後將該ARP請求進行封裝，標記好VNI後進行組播，VTEP 2收到後學習VNI 1中A的MAC地址與VTEP 1 的IP地址的對映關係，然後本地泛洪。B收到該ARP請求後進行回覆，由於VTEP 2已經完成了自學習，因此VTEP 2封裝報頭後將向VTEP 1進行單播，同時VTEP 2學習VM B的本地連線埠。同理，VTEP 1收到ARP回覆後，學習該VNI中MAC B與VTEP 2 IP地址的對映關係，然後再交給A。之後A和B間的資料流將通過單播在VETP 1和VTEP 2間傳輸。

上述為單播的過程，二層的組播過程與之類似，只不過外層的目的IP地址被封裝為相應VNI的組播地址。可見，標準VxLAN的轉發十分依賴於IP的組播（VxLAN不支援頭端複製的偽廣播），這對底層的IP網提出了相當的要求。而且將二層的ARP泛洪到底層的IP網上也不是很令人滿意，因此目前VxLAN常常與SDN控制器配合——控制器集中地學習VM與VTEP的對映關係，以幫助VxLAN建立隧道，減少了絕大部分在IP網路上的組播。

一個VxLAN網路連線的主機都在一個網段中，如果租戶需要多個網段則需要開通多個VxLAN網路，每個VxLAN網路都有自己的VNI。這些網端間的3層互通依賴於VxLAN GW，VxLAN GW作為閘道器將終結源主機所在的VxLAN然後進入目的主機的VxLAN。另外VxLAN閘道器還負責VxLAN與VLAN網路的連線，資料包從VxLAN網路進入VLAN網路時，VxLAN閘道器去掉VxLAN頭並根據VNI標記原始幀中的VLAN，反之同理。

VxLAN核心的東西就這麼多了。值得注意的是，VxLAN不允許VTEP接收IP分片，因此如果ingress VTEP封裝隧道後超過了IP Router的MTU就會被分片，Egress VTEP收到分片後將直接丟棄，而VxLAN本身並沒有MTU探測機制。

VxLAN用來建立虛擬機器間端到端的隧道，常常被部署在物理伺服器的HyperVisor中。考慮到軟體效能的=問題，現在也有一些硬體交換機也可以支援VxLAN了。這幾年VxLAN基本上已經成為了新一代資料中心技術的代名詞，再配合SDN的集中式控制，VxLAN當下當仁不讓地扛起了網路虛擬化的大旗。從目前來看，VxLAN在資料中心已經取得了對其他技術的壓倒性優勢，很多廠商都在擔心會被VxLAN鎖定，迫切地尋找著其他的替代方案。

大炮一響，黃金萬兩，NvGRE和STT相繼登場。

2)NvGRE

NvGRE（Network virtualization GRE，RFC draft）是微軟搞出來的資料中心虛擬化技術，是一種MACinGRE隧道。它對傳統的GRE報頭進行了改造，增加了24位的VSID欄位標識租戶，而FlowID可用來做ECMP。由於去掉了GRE報頭中的Checksum欄位，因此NvGRE不支援校驗和檢驗。NvGRE封裝乙太網幀，外層的報頭可以為IPv4也可以為IPv6。

NvGRE與VxLAN並沒有什麼核心的區別。雖然是在VxLAN之後提出的技術，但NvGRE變得更簡單了，完全沒有規定什麼地址學習機制，就是靠NVA來指揮，看來是鐵了心站到SDN這一隊了。細節上NvGRE與VxLAN還是有一定區別的，比如：不支援與VLAN網路的互通；使用Outer SRC IP+VSID+FlowID做ECMP，不過這要求IP Router的硬體支援；支援頭端複製的偽廣播；同樣不支援IP Router上的分片，但在RFC中探討了MTU發現機制，等等。

微軟又不是專門做網路的，有必要包裝一個Vmware搞一個基本一樣的技術嗎？有，原因很簡單，因為微軟的Hyper-V跟Vmware 的vCloud可是死對頭，有了VxLAN人家Vmware計算、儲存、網路的虛擬化可都齊活兒了，微軟要賣Hyper-V，總不可能拿死對頭現成的技術過來吧，這樣就有了NvGRE。

3)STT

STT（Stateless Transport Tunnel，RFC draft）是Nicira提出的資料中心虛擬化技術，是一種MACinTCP的隧道。之所以設計STT，是因為希望利用網絡卡的TSO（TCP Segment Offload）功能在隧道兩端進行分片以支援巨型幀的傳輸，提高階到端的通訊效率。Nicira被VMware收購後STT技術也自然易主，被用在NSX中做HyperVisor to HyperVisor的隧道技術。

雖然用到了TCP頭，但是STT修改了裡面的Seq欄位和Ack欄位的含義，不再用於重傳和滑動視窗，是一種無狀態的隧道。準確地說，STT使用的是一種TCP like的包頭，只是為了偽裝成TCP段來進行TSO。Src Port可用來做ECMP，DST Port為7471（正在向IANA申請）；Ack用來標識STT frame，Seq的upper 16 bits用於標識STT frame的長度，lower 16 bits用於標識current frame的偏移量。STT frame被分片後，各片的Ack和Seq的upper 16 bits均相同，而Seq的lower 16 bits各不相同，隧道出口裝置上的網絡卡用之進行分片重組；TCP Flag和Urgent Pointer都不再具有意義；Version現為0；Flags標識了內層資料的型別與相關資訊；L4 Offset標識了STT frame的末位到內層資料Layer 4（TCP/UDP）的偏移量；MSS為最大的分片長度；PCP為傳輸優先順序；VLAN ID用於與VLAN網路互通；Context ID為64位的VN Context。STT的外層的報頭可以為IPv4或者IPv6。

STT也沒有規定地址學習機制，同樣要配合SDN控制器完成轉發。不過相比於NvGRE，STT還算比較有特色，起碼首創地支援了分片的機制，不過STT也沒有內生的MTU發現機制。另外，STT不支援偽廣播；RFC建議支援DSCP和ECN；支援與VLAN網路的互通。

從某種角度來講，STT的分片機制能夠在一定程度上提高通訊的效率，不過STT有一個致命的缺陷——它的TCP是無連線的，不會進行三次握手，也沒有狀態維護。雖然網絡卡做TSO時不關心這個問題，但防火牆、負載均衡器這些Middle Box可就不買賬了。因此STT在實際部署時受到了很大的限制，在NSX中只被用來做Hyper-Hyper的隧道，想穿越過物理網路還得看VxLAN。STT的RFC也明確地提到了這個問題，希望將來Middle Box能做到STT aware——談何容易啊！

4)Geneve

Geneve（Generic Network Virtualization Encapsulation，RFC Draft）是NVo3工作組總結VxLAN、NvGRE和STT提出的一種網路虛擬化技術，希望形成一種通用的封裝格式，以便支援資料中心中隧道機制的後續演化。Geneve是今年5月份提出的，目前還處於草案階段，不過從它的內容來看，確實是博採眾長，未來具備相當的潛力。

Geneve採用了VxLAN的思路，是一種MACinUDP的隧道。之所以沒用MACinGRE或者MACinTCP，作者估計是工作組考慮到GRE頭部的可擴充套件性比較差，不具備可演進的能力。而用TCP頭的話，如果仍保持TCP的特性，則維護有連線的隧道開銷過大，如果像STT一樣處理為無狀態的，那麼又會存在Middle Box的穿越問題。相比之下，UDP頭就沒有那麼多問題，Geneve作為一種應用層協議不存在可擴充套件性的問題，而UDP本身的無連線特性又不會帶來開銷和相容的問題。至於分片，Geneve建議使用Path MTU Discovery(RFC 1191)來探測傳輸路徑上的MTU。

Geneve封裝的是乙太網幀，外層的報頭可以為IPv4也可以為IPv6。UDP Src Port常通過hash獲得，可用於ECMP，Dst Port為IANA分配給Geneve的6081；對於UDP Checksum，Geneve與VxLAN的處理辦法相同，並建議使用NIC去Offload；Geneve頭部採用了TLV格式，以支援隧道機制的演化，Opt Len為TLV的長度；O位為OAM標識，當O位置1的時候Geneve攜帶的為控制信令而非Ethernet payload；VNI為24位的VN Context；TLV的具體內容，目前Geneve還在制定草案；對Inner VLAN的處理，Geneve可選地支援VLAN Trunking與VLAN混合組網。

下面再來談談一些Geneve草案中除了封裝格式以外的內容，藉以簡單地分析一下端到端NVo3隧道的演化思路。Geneve希望IP Router可選地支援對Geneve的理解，也就是說希望底層IP Fabric的傳輸能夠考慮到隧道傳輸的需求，這在NvGRE和STT的草案中也都提到過，換句話說為了保障端到端的傳輸質量，隧道應該放開一些欄位給傳輸網路去參考，而不是死守著透明的原則不放，其實Outer IP的DSCP和ECN欄位就很適合做QoS，預計未來會有專門的機制去在NVE上做對映；Geneve參考了NvGRE的設計，希望可以將VNI作為ECMP的一個參考欄位，未來估計TLV中的一些Option也會被用來標識細粒度的業務流，以支援精細化的虛網定製；Geneve可採用頭端複製的偽廣播，不再要求IP Fabric具備組播的能力，降低要求的同時簡化了網管的配置工作；Geneve專門討論了分片的NIC Offload問題，以降低新增隧道包頭對傳輸效能造成的影響；Geneve也沒有規定地址學習機制，說明端到端隧道+SDN已經成為當下業界的共識。

目前Geneve只提交了一版草案，到今年的11月過期，估計下一版很快就要出來了，讓我們拭目以待，看看未來走勢如何。

最後畫幾張表作為總結吧，方便讀者直觀地對這幾種技術做個對比。