作者: Colin Jao 饒康立 – VMware資深技術顧問,主要負責VMware NSX產品線,目前致力於網路虛擬化暨分散式安全防護技術方案的介紹與推廣。
在上篇NSX的介紹文章內我們談了邏輯交換機內VXLAN的基本概念,接下來兩篇文章要與各位說明在VMware NSX內的邏輯交換機運作機制,第一篇要討論在邏輯交換機內如何處理BUM Traffic (Broadcast / Unknown / Multicast)的傳送,第二篇則討論vSphere Host 在底層進行VXLAN封裝時,如何知道要往哪一台目的主機傳送。
先很快複習在實體網路VLAN內,BUM Traffic是如何處理的呢?
- 廣播 Broadcast: Destination MAC會設定成全部為FF,Switch看到廣播目的地址,會送給位於這個VLAN內的所有實體Port。
- 群播 Multicast: Destination MAC的後面23 bit會由Multicast IP Address MAP到MAC位置。Switch藉由IGMP協定內各個Host的註冊,去對應哪些實體Port會對應哪個群播位置。收到Destination MAC是在群播位置內時,由MAC對應要往哪些實體Port送
- 未知封包 Unknown Unicast: 如果不是廣播也不是群播,但在Switch內的mac-address-table內沒有註冊這個Unicast MAC Address的位址,此時Switch會利用廣播的方法把這個封包往所有VLAN內的實體埠送出
但在邏輯交換機的底層要如何處理BUM Traffic呢?此時的核心問題是,當上層的邏輯交換機裡面有廣播或群播的封包傳送,在底層的VXLAN封裝是需要跨越實體網路的L2或甚至L3路徑來把這些封包送到各個目的主機的。此時在底層的處理方法包括
- 於底層網路透過Multicast的方式傳送。這是早期vDS內要求的方法
- 於底層網路透過Unicast的方式傳送。這是NSX方案內可採用的方法
- 於底層網路透過Hybrid的方式,也就是結合L2 Multicast與Unicast的方式傳送。這是NSX方案內可採用的方法
接下來我們對這三種方法進行說明。
用 Multicast方式傳送:
圖說:Multicast方式
這個方式很直接:底層的L2網路要支援IGMP,且如果vSphere Host的VTEP位於不同的網段有跨L3的需求,企業還需要在L3 Engine上設定PIM (Protocol Independent Multicast) 的機制。每個vSphere Host註冊自己有哪些Logical Switch並對應到哪個群播位置。因此當一個邏輯交換器上有BUM封包,如上圖的VM1所示,底層的vSphere Host要由對應此邏輯交換器的群播位置送出VXLAN封包,透過L2 / L3的群播機制,送到各個vSphere Host。
這個機制的優點當然是最節省底層的網路傳輸(群播只要傳送一次)。核心問題是…哪個企業的網路裡有實作PIM協定的呢?從前時代所有客戶一聽到VXLAN需要底層支援PIM就先退三步…這是實際上VXLAN透過L3 Multicast的方式很難普及的主要原因。
用Unicast方式傳送:
圖說:Unicast方式
採用Unicast方式時,針對每個邏輯交換器,每個網段內的多台vSphere Hosts內會被NSX Controller選出一個Host,其上的VTEP介面會被稱為UTEP (Unicast Tunnel Endpoint),負責這個網段內,對應邏輯交換器的封包傳輸與發送。
當同樣上圖的VM1要送出BUM封包,封包於來源vSphere Host VTEP上,
- 分別送一個Unicast給同網段的各個VTEP
- 此網段的UTEP收到此Unicast後,複製並分別送出一個VXLAN Unicast給每一個其他不同網段的UTEP
- 每一個網段內負責此邏輯交換器的UTEP接收到此VXLAN Unicast後,往每一個同網段內的其他Host發送Unicast封包
Unicast方式內,底層的實體網路環境除了基本要設定MTU > 1600之外,完全沒有其他的東西需要設,所以設定超簡單。但問題是這個方式的overhead非常高。小環境也就算了,如果是較大型的環境,比如說上面的圖,總共兩個網段,大家想像左邊網段有十台vSphere Hosts,右邊網段也有十台Hosts,此時左邊的一個VM發出BUM封包
- 來源Host送出共九次Unicast給同網段的VTEP / UTEP
- 來源網段的UTEP要對各個其他不同網段的UTEP各發出一個Unicast,本範例內共一次
- 目的網段的UTEP要對其他同網段的九台Hosts發出九個Unicasts,共九次
所以總共要搞19次Unicast來傳送這一個單一的BUM封包。如果只是小環境或PoC也OK,大型環境這樣搞當然不是有效率的方法。
用Hybrid方式傳送:
圖說:Hybrid方式
採用Hybrid方式時,針對每個邏輯交換器,每個網段內的多台vSphere Hosts內會被NSX Controller選出一個Host,其上的VTEP介面會被稱為MTEP (Multicast Tunnel Endpoint),負責這個網段內,對應邏輯交換器的封包群播。
當同樣上圖的VM1要送出BUM封包,封包於來源vSphere Host上,
- 送一個Multicast給同網段的所有VTEP or MTEP
- 此網段的MTEP收到此Multicast後,複製並分別送出一個VXLAN Unicast給每一個其他不同網段的MTEP
- 每一個網段內負責此邏輯交換器的MTEP接收到此VXLAN Unicast後,往同網段內的其他Host發送Multicast封包
同樣承襲前面20個hosts的例子,
- 來源Host送出一次Multicast給同網段的MTEP / VTEP
- 來源網段的MTEP要對其他不同網段的MTEP各發出一個Unicast,共一次
- 目的網段的MTEP要對其他同網段的九台Hosts發出一個Multicasts,共一次
這邊的重點在群播只發生在L2網路內,跨L3的封包傳送是藉由Unicast傳輸。因此,群播的設定僅僅需要考慮採用IGMP的方式作L2 Multicast,設定非常簡單。而最被一般用戶詬病的採用L3 Multicast (PIM)的需求被移除了,於網路內的傳輸也不會overhead過大。也因此,Hybrid模式是在VMware NSX裡面,最被推薦使用於生產環境的模式。
現在我們要回答一個在之前文章內提出的問題:於vSphere NSX內的VXLAN,與在傳統vDS裡面支援的VXLAN技術,有什麼不同?
VXLAN(或各個對應的底層封裝技術)在網路虛擬化技術裡是非常重要的一環,因為藉由這個技術,
- 上層多個邏輯交換器的設定,都可以透過同樣的VXLAN封裝於底層網路內交換。上層的邏輯交換器新增或異動不會影響到底層實體網路設備的設定
- 邏輯交換器可以跨越底層網路L3的限制,無需要建立一個vSphere Host間的”大二層”
但之前在vDS時,部署這類技術時底層網路需要做兩個大的變更
- 底層網路需要支援L3 Multicast,也就是PIM
- 底層網路需要支援Jumbo Frame,供VXLAN增加的表頭可通過
於目前VMware NSX的架構內,正式解除了前面的第一個變更需求。用戶現在可以使用簡單的L2 Multicast (IGMP)即可達到需求,甚至若不支援IGMP,廣播的方式也可支援。而Jumbo Frame雖然需要進行設定,但幾乎所有的Enterprise-Level Switch都支援此功能,設定也不麻煩。因此,NSX成為一個真正能在不同企業網路上都可輕易部署與架構的網路虛擬化平台,大幅減少了客戶若要使用所碰到的實際環境困難。
下一篇內我們會和各位談論另一個問題:NSX內,每台主機怎麼知道在實體網路上,要把VXLAN封裝的網路封包送到哪台實體主機呢?
Comments
0 Comments have been added so far