NVo3（Network Virtualization over Layer 3），是IETF 2014年十月份提出的數(shù)據(jù)中心虛擬化技術(shù)框架。NVo3基于IP/MPLS作為傳輸網(wǎng)，在其上通過隧道連接的方式，構(gòu)建大規(guī)模的二層租戶網(wǎng)絡(luò)。NVo3的技術(shù)模型如下所示，PE設(shè)備稱為NVE（Network Virtualization Element），VN Context作為Tag標識租戶網(wǎng)絡(luò)，P設(shè)備即為普通的IP/MPLS路由器。NVo3在設(shè)計之初，VxLAN與SDN的聯(lián)合部署已經(jīng)成為了數(shù)據(jù)中心的大趨勢，因此NVo3的模型中專門畫出了NVA（Network Virtualization Authority）作為NVE設(shè)備的控制器負責(zé)隧道建立、地址學(xué)習(xí)等控制邏輯。
NVo3的思想起源于VxLAN，結(jié)合NVGRE和STT的發(fā)展，目前收斂為Geneve。上述技術(shù)都是端到端的隧道，CE為虛擬機或物理服務(wù)器，其實單純地從NVo3的模型角度來看，后面要介紹的OTV/EVN/EVI這些DC間互聯(lián)的隧道技術(shù)都屬于NVo3的框架中。本專題將對端到端的NVo3技術(shù)進行深入的介紹。
1)VxLAN
VxLAN（Virtual eXtensible LAN，RFC 7348），是Vmware和Cisco聯(lián)合提出的一種大二層技術(shù)，突破了VLAN ID只有4k的限制，允許通過現(xiàn)有的IP網(wǎng)絡(luò)進行隧道的傳輸。別看VxLAN名字聽起來和VLAN挺像，但是兩者技術(shù)上可沒什么必然聯(lián)系。VxLAN是一種MACinUDP的隧道，下面是VxLAN的報頭。
VxLAN封裝的是以太網(wǎng)幀，外層的報頭可以為IPv4也可以為IPv6。UDP Src Port是外層UDP的源端口號，它的值通過hash得到，常用來實現(xiàn)ECMP；Dst Port為VxLAN從IANA申請的端口4789；UDP checksum如果不為0，出口VTEP（VxLAN的NVE）必須進行計算，計算結(jié)果必須與該字段一致才能進行解封裝，不一致則進行丟棄，checksum如果為0，則出口VTEP無條件解封裝；VNI是VxLAN的VN Context，長度為24位，支持16 million的租戶；后面是CE送出來的Ethernet原始幀，VxLAN GW對其中的VLAN tag有所要求。
NVo3技術(shù)中，NVE上的地址學(xué)習(xí)包括兩類：第一類是學(xué)習(xí)本地VM的MAC與port的映射關(guān)系，第二類是學(xué)習(xí)遠端VM的MAC地址與該VM所在NVE的IP地址的映射關(guān)系。標準VxLAN的地址學(xué)習(xí)仍為二層的自學(xué)習(xí)算法，通過組播在VTEP間泛洪。標準VxLAN的通信流程如下例所示。
首先，VTEP通過IGMP加入VNI 1的組播組，VNI 1中的BUM流量都將通過該組播組傳輸。虛擬機A與B間通信具體轉(zhuǎn)發(fā)流程如下：VM A發(fā)送ARP請求，VTEP 1學(xué)習(xí)VM A的本地連接端口，然后將該ARP請求進行封裝，標記好VNI后進行組播，VTEP 2收到后學(xué)習(xí)VNI 1中A的MAC地址與VTEP 1 的IP地址的映射關(guān)系，然后本地泛洪。B收到該ARP請求后進行回復(fù)，由于VTEP 2已經(jīng)完成了自學(xué)習(xí)，因此VTEP 2封裝報頭后將向VTEP 1進行單播，同時VTEP 2學(xué)習(xí)VM B的本地連接端口。同理，VTEP 1收到ARP回復(fù)后，學(xué)習(xí)該VNI中MAC B與VTEP 2 IP地址的映射關(guān)系，然后再交給A。之后A和B間的數(shù)據(jù)流將通過單播在VETP 1和VTEP 2間傳輸。
上述為單播的過程，二層的組播過程與之類似，只不過外層的目的IP地址被封裝為相應(yīng)VNI的組播地址?？梢?，標準VxLAN的轉(zhuǎn)發(fā)十分依賴于IP的組播（VxLAN不支持頭端復(fù)制的偽廣播），這對底層的IP網(wǎng)提出了相當?shù)囊?。而且將二層的ARP泛洪到底層的IP網(wǎng)上也不是很令人滿意，因此目前VxLAN常常與SDN控制器配合——控制器集中地學(xué)習(xí)VM與VTEP的映射關(guān)系，以幫助VxLAN建立隧道，減少了絕大部分在IP網(wǎng)絡(luò)上的組播。
一個VxLAN網(wǎng)絡(luò)連接的主機都在一個網(wǎng)段中，如果租戶需要多個網(wǎng)段則需要開通多個VxLAN網(wǎng)絡(luò)，每個VxLAN網(wǎng)絡(luò)都有自己的VNI。這些網(wǎng)端間的3層互通依賴于VxLAN GW，VxLAN GW作為網(wǎng)關(guān)將終結(jié)源主機所在的VxLAN然后進入目的主機的VxLAN。另外VxLAN網(wǎng)關(guān)還負責(zé)VxLAN與VLAN網(wǎng)絡(luò)的連接，數(shù)據(jù)包從VxLAN網(wǎng)絡(luò)進入VLAN網(wǎng)絡(luò)時，VxLAN網(wǎng)關(guān)去掉VxLAN頭并根據(jù)VNI標記原始幀中的VLAN，反之同理。
VxLAN核心的東西就這么多了。值得注意的是，VxLAN不允許VTEP接收IP分片，因此如果ingress VTEP封裝隧道后超過了IP Router的MTU就會被分片，Egress VTEP收到分片后將直接丟棄，而VxLAN本身并沒有MTU探測機制。
VxLAN用來建立虛擬機間端到端的隧道，常常被部署在物理服務(wù)器的HyperVisor中?？紤]到軟件性能的=問題，現(xiàn)在也有一些硬件交換機也可以支持VxLAN了。這幾年VxLAN基本上已經(jīng)成為了新一代數(shù)據(jù)中心技術(shù)的代名詞，再配合SDN的集中式控制，VxLAN當下當仁不讓地扛起了網(wǎng)絡(luò)虛擬化的大旗。從目前來看，VxLAN在數(shù)據(jù)中心已經(jīng)取得了對其他技術(shù)的壓倒性優(yōu)勢，很多廠商都在擔心會被VxLAN鎖定，迫切地尋找著其他的替代方案。
大炮一響，黃金萬兩，NvGRE和STT相繼登場。
2)NvGRE
NvGRE（Network virtualization GRE，RFC draft）是微軟搞出來的數(shù)據(jù)中心虛擬化技術(shù)，是一種MACinGRE隧道。它對傳統(tǒng)的GRE報頭進行了改造，增加了24位的VSID字段標識租戶，而FlowID可用來做ECMP。由于去掉了GRE報頭中的Checksum字段，因此NvGRE不支持校驗和檢驗。NvGRE封裝以太網(wǎng)幀，外層的報頭可以為IPv4也可以為IPv6。
NvGRE與VxLAN并沒有什么核心的區(qū)別。雖然是在VxLAN之后提出的技術(shù)，但NvGRE變得更簡單了，完全沒有規(guī)定什么地址學(xué)習(xí)機制，就是靠NVA來指揮，看來是鐵了心站到SDN這一隊了。細節(jié)上NvGRE與VxLAN還是有一定區(qū)別的，比如：不支持與VLAN網(wǎng)絡(luò)的互通；使用Outer SRC IP VSID FlowID做ECMP，不過這要求IP Router的硬件支持；支持頭端復(fù)制的偽廣播；同樣不支持IP Router上的分片，但在RFC中探討了MTU發(fā)現(xiàn)機制，等等。
微軟又不是專門做網(wǎng)絡(luò)的，有必要包裝一個Vmware搞一個基本一樣的技術(shù)嗎？有，原因很簡單，因為微軟的Hyper-V跟Vmware 的vCloud可是死對頭，有了VxLAN人家Vmware計算、存儲、網(wǎng)絡(luò)的虛擬化可都齊活兒了，微軟要賣Hyper-V，總不可能拿死對頭現(xiàn)成的技術(shù)過來吧，這樣就有了NvGRE。
3)STT
STT（Stateless Transport Tunnel，RFC draft）是Nicira提出的數(shù)據(jù)中心虛擬化技術(shù)，是一種MACinTCP的隧道。之所以設(shè)計STT，是因為希望利用網(wǎng)卡的TSO（TCP Segment Offload）功能在隧道兩端進行分片以支持巨型幀的傳輸，提高端到端的通信效率。Nicira被VMware收購后STT技術(shù)也自然易主，被用在NSX中做HyperVisor to HyperVisor的隧道技術(shù)。
雖然用到了TCP頭，但是STT修改了里面的Seq字段和Ack字段的含義，不再用于重傳和滑動窗口，是一種無狀態(tài)的隧道。準確地說，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各不相同，隧道出口設(shè)備上的網(wǎng)卡用之進行分片重組；TCP Flag和Urgent Pointer都不再具有意義；Version現(xiàn)為0；Flags標識了內(nèi)層數(shù)據(jù)的類型與相關(guān)信息；L4 Offset標識了STT frame的末位到內(nèi)層數(shù)據(jù)Layer 4（TCP/UDP）的偏移量；MSS為最大的分片長度；PCP為傳輸優(yōu)先級；VLAN ID用于與VLAN網(wǎng)絡(luò)互通；Context ID為64位的VN Context。STT的外層的報頭可以為IPv4或者IPv6。
STT也沒有規(guī)定地址學(xué)習(xí)機制，同樣要配合SDN控制器完成轉(zhuǎn)發(fā)。不過相比于NvGRE，STT還算比較有特色，起碼首創(chuàng)地支持了分片的機制，不過STT也沒有內(nèi)生的MTU發(fā)現(xiàn)機制。另外，STT不支持偽廣播；RFC建議支持DSCP和ECN；支持與VLAN網(wǎng)絡(luò)的互通。
從某種角度來講，STT的分片機制能夠在一定程度上提高通信的效率，不過STT有一個致命的缺陷——它的TCP是無連接的，不會進行三次握手，也沒有狀態(tài)維護。雖然網(wǎng)卡做TSO時不關(guān)心這個問題，但防火墻、負載均衡器這些Middle Box可就不買賬了。因此STT在實際部署時受到了很大的限制，在NSX中只被用來做Hyper-Hyper的隧道，想穿越過物理網(wǎng)絡(luò)還得看VxLAN。STT的RFC也明確地提到了這個問題，希望將來Middle Box能做到STT aware——談何容易?。?/p>
4)Geneve
Geneve（Generic Network Virtualization Encapsulation，RFC Draft）是NVo3工作組總結(jié)VxLAN、NvGRE和STT提出的一種網(wǎng)絡(luò)虛擬化技術(shù)，希望形成一種通用的封裝格式，以便支持數(shù)據(jù)中心中隧道機制的后續(xù)演化。Geneve是今年5月份提出的，目前還處于草案階段，不過從它的內(nèi)容來看，確實是博采眾長，未來具備相當?shù)臐摿Α?/p>
Geneve采用了VxLAN的思路，是一種MACinUDP的隧道。之所以沒用MACinGRE或者MACinTCP，作者估計是工作組考慮到GRE頭部的可擴展性比較差，不具備可演進的能力。而用TCP頭的話，如果仍保持TCP的特性，則維護有連接的隧道開銷過大，如果像STT一樣處理為無狀態(tài)的，那么又會存在Middle Box的穿越問題。相比之下，UDP頭就沒有那么多問題，Geneve作為一種應(yīng)用層協(xié)議不存在可擴展性的問題，而UDP本身的無連接特性又不會帶來開銷和兼容的問題。至于分片，Geneve建議使用Path MTU Discovery(RFC 1191)來探測傳輸路徑上的MTU。
Geneve封裝的是以太網(wǎng)幀，外層的報頭可以為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的具體內(nèi)容，目前Geneve還在制定草案；對Inner VLAN的處理，Geneve可選地支持VLAN Trunking與VLAN混合組網(wǎng)。
下面再來談?wù)勔恍〨eneve草案中除了封裝格式以外的內(nèi)容，借以簡單地分析一下端到端NVo3隧道的演化思路。Geneve希望IP Router可選地支持對Geneve的理解，也就是說希望底層IP Fabric的傳輸能夠考慮到隧道傳輸?shù)男枨?，這在NvGRE和STT的草案中也都提到過，換句話說為了保障端到端的傳輸質(zhì)量，隧道應(yīng)該放開一些字段給傳輸網(wǎng)絡(luò)去參考，而不是死守著透明的原則不放，其實Outer IP的DSCP和ECN字段就很適合做QoS，預(yù)計未來會有專門的機制去在NVE上做映射；Geneve參考了NvGRE的設(shè)計，希望可以將VNI作為ECMP的一個參考字段，未來估計TLV中的一些Option也會被用來標識細粒度的業(yè)務(wù)流，以支持精細化的虛網(wǎng)定制；Geneve可采用頭端復(fù)制的偽廣播，不再要求IP Fabric具備組播的能力，降低要求的同時簡化了網(wǎng)管的配置工作；Geneve專門討論了分片的NIC Offload問題，以降低新增隧道包頭對傳輸性能造成的影響；Geneve也沒有規(guī)定地址學(xué)習(xí)機制，說明端到端隧道 SDN已經(jīng)成為當下業(yè)界的共識。
目前Geneve只提交了一版草案，到今年的11月過期，估計下一版很快就要出來了，讓我們拭目以待，看看未來走勢如何。
最后畫幾張表作為總結(jié)吧，方便讀者直觀地對這幾種技術(shù)做個對比。
