雲端計算的 IT 架構已經在企業應用中表現出明顯優勢，但網路設計理念卻必須是一種推倒重來的思想。為了適應雲端計算的靈活、彈性擴充套件、高效和低成本，網路設計要進化為集中式軟體管理，可程式設計化，控制轉發層面分離等。本次陳海泉分享了關於下一代超大規模軟體定義網路技術實踐。

以下是本次分享的內容整理。

————————————————————————————————————————————

大家好，我是 QingCloud 的工程師陳海泉，今天給大家分享一些 SDN/NFV 2.0 架構的網路技術。我解釋一下什麼是 SDN，SDN 就是軟體定義網路。當然也不是所有網路定製一定要軟體來實現，因為有很多硬體方案也可以做到 SDN 的效果。

青雲QingCloud 用軟體定義來實現虛擬網路，我們 2013 年的時候，在公有云上線了第一代產品。當時 SDN 還是一個比較新鮮的事情，使用者用的還比較少。到了今天，SDN已經開始普及，連私有云使用者也在使用基於SDN的VPC。

隨著使用者量越來越大，第一版的 SDN 提供的私有網路裡面的 VM 超過一定的數量的時候，我們發現效能就有一個比較大的損失，已經無法滿足企業使用者的需求。所以我們在去年下半年的時候，花了很大功夫去做 SDN/NFV 2.0 的事情。

考慮到很多人對計算機網路不熟悉，我先補充下網路基本原理：計算機網路分 7 層。 SDN 相關的主要是二層和三層網路。二層是資料鏈路層，使用 MAC 為地址通訊，二層網路中的成員透過交換機連線起來。成員間的應用軟體雖然以 IP 為地址通訊，但是通訊之前，作業系統會透過 ARP 協議，把目標 IP 轉換成 MAC 地址，然後再傳送資料包。交換機根據資料包的目標 MAC 地址，進行資料包的投遞。二層網路中，會用到單播，廣播和組播三種方式。

三層是網路層，使用 IP 為地址通訊。三層網路就是用路由器將不同的二層網路連線在一起，形成一個可擴充套件的網路。通訊方式可以是單播和組播，但不能是廣播。路由器的作用就是根據路由表，找出目標 IP 對應的 MAC 地址。資料包往往透過多個路由器之間轉發，才會送到目標地址。

基本知識介紹到這裡，現在說一下為什麼需要 SDN 。

首先，虛擬化技術帶來的好處是使用者的 VM 分佈在物理機叢集上面，出於負載均衡，和服務高可用的目的，需要在物理機之間遷移 VM ，並且遷移之後 IP 地址不變。

在早期的虛擬化方案中，物理機叢集比較小，全部是一個二層網路， VM 使用物理裝置分配的 IP 地址時，發生遷移之後， IP 本身就不會變化。但是隨著雲端計算的發展，虛擬化的物理叢集需要被部署在更大的三層網路上，這時候 VM 再使用物理 IP 地址，是不能夠保證 IP 不變的，因為遷移到了別的二層網路，對應的路由器就不認識原來的地址了， VM 要繼續工作，必須更換成當前網路的 IP 地址。

這個時候，就需要網路虛擬化技術，也就是透過 SDN 給 VM 定義虛擬的 IP 段，這個虛擬的網路可以分散在整個三層網路上，使得 VM 遷移後， IP 地址不變。這個IP地址跟物理的路由器，交換機沒什麼關係，可以隨便定義。隨著雲端計算的發展，單靠網路虛擬化技術，仍然滿足不了使用者大規模部署的需求，這時就需要有 VPC 。

VPC 是什麼意思呢？ VPC 是使用者定義的一個專屬的大型三層網路。在 VPC 網路內，使用者可以自定義 IP 地址範圍、建立子網，並在子網內建立主機/資料庫/大資料等各種雲資源。

簡單的說，虛擬網路指的是虛擬二層網路， VPC 指的是虛擬三層網路。在 VPC 裡面，還需要能做到不同 VPC 之間， IP 地址複用。因為私有 IP 段有限制，不同的使用者，可以使用相同的 IP 地址，卻不互相影響。

正是因為雲端計算需要虛擬網路，也需要 VPC 。所以需要一個 SDN 方案解決這兩個需求，現有的 SDN 方案主要分成兩個方向：

用軟體來定義，但是用硬體來實現。比如某些帶 SDN 功能的交換機，把它採購進來，部署到產品裡，用硬體廠商提供的 API ，就能定義虛擬網路，實現 VPC 功能。
NFV，就是網路功能虛擬化，用軟體的方式來實現虛擬的交換機和路由器，把他們組織，並管理起來，讓上層應用能夠定義虛擬網路。其代表有 VMware NSX 、 JuniperOpenContrail、OpenStackDVR 等等。

QingCloud 在 SDN 方案的選型上也做過討論，用軟體還是用硬體方案？其中考慮的問題主要是以下三個方面：

成本。在公有云上面大家拼的是成本，誰的硬體成本低，誰就能把價格降到最低。如果我們採用硬體方案，在網路裝置上面需要增加了很多投資，要替換掉幾乎所有的網路裝置。
裝置依賴。我們的私有云賣的是軟體，客戶可以按照偏好選擇自己的硬體，假如 QingCloud 的 SDN 繫結了某款硬體產品，那我們在面對企業客戶的時候，可能連招標的機會都沒有，因為客戶往往有自己的採購渠道，指定的硬體品牌。
情懷。對於工程師來說，自然是想把產品做得更優秀。參考下優秀的傳統行業，就能明白這一點。

其實，計算機網路跟傳統快遞行業非常的接近，我在後面解釋網路知識時，也會拿快遞打比方。

為什麼說快遞跟計算機網路接近呢？因為網路中的交換機、路由器，其實跟快遞行業裡的快遞員和包裹集散中心非常相似，使用者發包裹給快遞員以後，快遞員會送到快遞集散中心，這裡可以查詢包裹應該被送到哪個地方，然後再將包裹經過多個快遞集散中心層層轉運，才會送到收件人那裡。

順豐在中國應該是最好的快遞公司之一，因為它把轉運環節都做全了，只有方方面面都能夠控制才能實現壓倒性的優勢。

上面的插圖給了順豐航空的一個截圖。我是看到了這張圖，才明白為什麼他們能夠比別家送得快。因為他們不僅有自營的快遞轉運點，連飛機都是自己買的。

因此，我們如果把資料包轉發的每個流程都控制到，就有可能在整體系統上面做到最優，而採用硬體裝置實現這些功能的話，最後帶來的是同質化，跟競爭對手相比不會有任何的優勢。

綜合以上三方面的原因，我們決定開發一套新的 SDN/NFV2.0 方案，取代 1.0 。

開發一套新的SDN/NFV 2.0 方案，也就是自營航空公司。既然定了要自己做一套新的方案，怎麼去實現？我們做了一些總結，新的產品首先需要滿足傳統 SDN 的功能。需要做到三點：

資料封裝。也就是實現一個虛擬網路；
實現控制平面。對二層、三層的網路資料進行轉發和路由規則的同步，然後下發到虛擬的交換機和路由器裡面去，同時需要做到 ARP 泛洪抑制；
實現資料平面。我們使用了叫做 DVR 的linux kernel模組實現的資料平面，同時還提供了虛擬邊界路由器，提供vpn，隧道等高階功能。

下面分別解釋這三點：

首先解釋下虛擬網路。 虛擬網路直接說比較難以理解，但是類比到傳統行業，就好解釋了。

在一些大公司裡會提供一種叫內部郵件的服務給員工，比如要給財務部門某同事發一個報銷單，會查他的工位，比如 2pw067 。然後準備一個信封，把要填的單子放在裡面, 收件人地址就填 2pw067 。我不需要知道這個人是在北京，還是在上海，直接用工位號就能發件。我把這個信封交給公司的收發室。收發室其實不具備郵遞能力，但是他們也能做快遞業務，方法就是對這個信封進行重新封裝，收發室有個地址本，能查到 2pw067 這個工位對應的辦公樓具體地址。

然後用一個大信封，把我原來的信封裝進去，收件人填目標辦公樓的收發室員工名字，收件地址是實際的街道地址，然後把具有新地址的信封交給真正的快遞公司，比如順豐。快遞公司會把信封傳送到對應的辦公樓，然後那邊的收發室把外層信封拆掉，將裡面的信封交給具體的收件人。

拿計算機的術語來講，內部郵件系統就是虛擬快遞公司，真正派件的快遞公司，叫做物理快遞公司。虛擬網路非常類似，允許使用者透過自己定義的地址，進行傳輸。這個地址使用者隨便定義，反正物理網路看不到這個地址，也就不受任何限制。

物理機收到 VM 發的包後，會對資料包做封裝，再套一個信封，也就是加個包頭，寫上目標物理機的地址。物理網路裝置，根據新的包頭把這個資料包傳送到對應的物理機，然後物理機那邊的終端會把資料包拆開，將裡面的資料包轉發到目標 VM 。

這裡的封包，拆包就是 Overlay 技術，也叫資料封裝。聽起來很高大上，其實傳統行業幾百年前就實現了。

下面就是具體的計算機技術細節：實現虛擬網路，比較流行的資料封裝協議是 VXLAN ，因為 VXLAN 相比傳統的 GRE 協議有一系列的優勢。

隧道連線一組物理機。 VXLAN 發包時，可以任意指定目標物理 IP 地址和 ID ，不像 GRE 那樣，要在兩邊配置點對點的連線；
使用 UDP 協議。 UDP 協議的特點是有埠。發包時每個連線都使用不同的源埠。當資料包交給目標伺服器網路卡的時候，網路卡根據這個資料的包頭的 IP/埠做 HASH 運算，用於選擇不同的網路卡佇列。而每個網路卡佇列會繫結到一個 CPU 上面，這樣把包會交給不同的 CPU 處理，提升總體效能；
使用基於組播的 Flood & Learn 模式自動管理虛擬網路。這個功能會大幅降低元件虛擬網路的複雜度，因為 VXLAN 的終端，會根據資料包包頭的內容，自動建立，並維護一個轉發表。回包的時候，根據轉發包找到目的物理機的地址。

這裡的轉發表，拿之前的例子說明，就是企業內部郵件收發室的地址本，把虛擬地址和實體地址對應上。 VXLAN 的這個特殊功能，就是能夠自動建立地址本。

基於以上幾點，我們覺得 VXLAN 不錯，但是仔細的去想，就發現它有兩個非常大的不足：

傳送廣播包時，使用了組播協議，大規模部署會受硬體裝置組播路由限制。它在二層網路中使用時，沒什麼問題，但是在三層網路中使用時，物理路由器上會建立大量的組播路由條目，影響路由器效能，並且增加了路由器運維的難度。
Flood& Learn 的機制，會把原來在二層廣播的 ARP 包擴大到三層網路。

第二點解釋起來比較複雜，先從 ARP 原理講起。 ARP 的作用是把 IP 地址轉換成 MAC 地址。在發包方，如果遇到不認識的 IP 地址，會發個廣播包到當前的二層網路，內容大概是：誰的 IP 是 1.2.3.4 ，請告訴 1.2.3.5 。所有網路成員都會收到這個包，但是隻有 1.2.3.4 會回包給 1.2.3.5 。這樣， 1.2.3.5 就知道了 1.2.3.4 的 MAC 地址，接下來他們就能夠透過 MAC 地址互相通訊。 Flood & Learn 的原理就是學習 ARP 廣播包的行為，建立轉發表。

拿之前的企業內部郵件做例子，收發室收到目標地址是 2pw067 的郵件時，他一開始不知道這個地址在幾樓的哪個辦公室，他會群發 Email 到寫字樓的全體員工，說有 2pw067 的包裹。這樣收件人會到收發室取郵件，同時把自己的 Email 告訴收發室。

此時，收發室的這個人，會默默在自己的小本上加一行： 2pw067 的 Email 是。這樣下次在有到 2pw067 的郵件，他直接給發郵件，通知他來取件，而不是群發所有人。這個方式最大的問題是，收發室老會群發郵件，而且他每隔一段時間，就要確認下 2pw067 的 Email 有沒有發生變化。這樣隨著規模擴大，廣播越來越多，會嚴重的浪費頻寬資源。

雖然物理網路也會使用 ARP 廣播，但是廣播被限制在二層網路裡面。而虛擬網路的載體，實際是三層的物理網路，廣播實際上可能被髮送到整個資料中心的所有物理機。在大規模部署虛擬網路時，ARP 浪費的頻寬可能佔網路流量的一半以上。

要解決這個問題，需要做到兩點：

攔截 ARP 廣播，避免傳送到全域性；
使用控制器同步地址本，代替 Flood & Learn 功能。

所以，需要有 SDN 控制器，透過同步規則，取代 VXLAN 自有的 Flood& Learn 功能。

也就是說，有個 HR ，每當有員工人入職，工位變動時，就把他的工位發到公司所有寫字樓的收發室，不讓他們用廣播的方式學習地址。而且收發室收到群發郵件時，會主動回包，而不是把廣播包轉發到別的收發室。

那麼這個控制器需要多少個呢？我之前曾經瞭解過一些 SDN 方案，通常只有一個。它負責同步整個叢集中所有節點的規則，這麼做帶來一個問題，當 VM 建立、銷燬、遷移的時候，控制器需要把新的規則同步到整個叢集所有的節點中。

而優秀的雲端計算平臺，能夠讓使用者秒級建立資源。 VM 建立、銷燬、遷移這種事情，在叢集中無時無刻都存在，同步規則會變得相當頻繁。所以我們做了一個分散式控制器，不僅把控制器分佈到每個 VPC ，還分佈到每個虛擬網路裡。

剛才說了虛擬網路和控制器，第三點 SDN 需要做的就是控制資料平面，其作用就是把資料包從網路卡複製到 VM 。

傳統的資料平面，比如 OpenStack 通常會用 OVS 。 OVS 會有一個問題，它會把資料包傳到 UserSpace ，因為有個應用程式，根據流表決定資料包如何轉發，這樣會帶來效能的下降。

而我們的方案完全避免了這個問題，使用自己研發的 DVR 取代 OVS ，所有資料轉發都在 LinuxKernel 中完成。 DVR 就是分散式虛擬路由器。它實際上是一個帶路由器的交換機，同時具有二層交換，和三層路由的功能。

DVR 這個概念，幾乎在所有先進的 NFV 方案的 SDN 中都有，比如 OpenStack 的 DVR ， VMware NSX 的邏輯路由器，OpenContrail 的 vRouter 。

他們名字雖然不同，但是本質是相同的，也就是說，讓每個計算節點都擁有虛擬的交換機和路由器。聽起來很簡單，但是實現它有很大困難，其中之一就是：同一個網路的 DVR， MAC，IP 地址都是相同的，這在物理網路裡面是無法想象的，因為打破了網路的基本規律。

但是 DVR 卻是 NFV 方案的一個關鍵。

如上圖所示，我們解釋一下為什麼需要 DVR 。左邊是這張是物理拓撲圖，物理世界中 A 和 B 通訊，需要把資訊傳送到 A 的交換機，然後到路由器，然後路由器轉給 B 的交換機，B 的交換機再傳送給 B ，A 和 B 通常需要 4 跳才能發一個資料包。

我們 1.0 的時候，也是用 NFV 實現的 SDN ，我們會模仿物理世界，發明出虛擬的路由器和交換機提供給使用者。請看中間這張圖，如果 A、B、C、D、E 這五個裝置分別位於五個不同的物理機上，在邏輯上，A-> B 的包經過 C、E、D 才能到 B ，邏輯上是 4 跳。但是虛擬裝置每一跳都要透過物理機去轉發，而物理機之間發包都需要 4 跳，這樣總得轉發量實際上需要 16 跳。

這也就是為什麼我們 SDN 1.0 的效能總是上不去。隨著規模增加，邏輯上每增加 1 跳，物理上就增加 4 跳，效能隨規模衰減得厲害。

為了解決這個問題，我們引入了 DVR 。請看右邊這張圖， A 和 B 的物理機都有 DVR ，從 A 到 B 只在兩個 DVR 之間直接交換一下資料就可以了，這樣在邏輯上只有一跳。所以物理層面上跟左邊的圖一樣， 4 跳完成一個資料包的轉換，這樣就可以非常接近物理機的效能，在大規模部署時，保持高效能。

使用 DVR 的另外一個原因，就是虛擬網路裝置效能弱於物理裝置，在物理裝置部署拓撲上，經常有匯聚節點，成為網路瓶頸。由於物理裝置能力很強，很容易就能達到 40 G ，或更高頻寬，匯聚幾次沒什麼關係；而虛擬裝置作為匯聚節點時，往往就限制了它管理的網路整體能力，因為虛擬匯聚裝置會成為效能瓶頸。使用 DVR 同時意味著不再有匯聚節點，因為所有成員都是點對點直接通訊。

這個在物理裝置上無法實現，因為不可能把所有裝置連成一個大網，而虛擬網路裝置上，是可以實現的，因為他們相連，只是加幾條轉發規則而已，而不是真的需要去點對點地連線網線。

有了上面三個功能，就是通常意義上的 SDN 了。然而我們在做雲端計算平臺時，透過長時間的積累，還發現了很多需求：

VPC，並且 VPC 主機直接繫結公網 IP 。
負載均衡器。可在公網閘道器上對入流量進行分流，轉發到多個負載均衡器節點。
VM 使用基礎網路時，也就是物理網路的 IP 地址在遷移後不變。
VPC 和物理網路高效連線。

下面分別解釋。

首先是 VPC ，青雲QingCloud VPC 功能是 1 月 6 號上線的，我們只上線了一週就賣掉了第一批上線的所有物理資源。因為我們公有云的大使用者已經深深的認識到必須要有一個 VPC 才能支援自己的海量的資源。業務真的到了一千個 VM 以上的時候，就需要有一個高效的三層網路，取代二層網路。

我們 VPC 設計是支援 64000 臺虛擬機器，代表著我們控制器控制規則有可能是 6 萬條，假如我們把跟 6 萬條規則同步到每個 DVR 上去，這同步量非常大。

相信靠我寫的程式碼完全不可能實現。所以設計一開始就給他設計了一個學習的能力。學習不是是基於泛洪的學習，而是根據使用者的行為對他進行學習。

這個學習功能，還是拿快遞打比方。

快遞員通常收到郵件時，會把郵件發到郵件集散中心，那裡有人去查地址本，決定郵件對應的下一個郵件集散中心是哪個。然後會交給郵遞員經行投遞。我們假設每個快遞員都能夠把包裹投遞到任何一個地方，也就是擁有 DVR 的能力。

當發件郵遞員投送發給oc的包裹到北辰購物中心 2 號樓時，他多做一件事情，給收件的快遞員打個電話，告訴他說：哥們，你以後再收到發給 oc 的包，直接交給我，不用送到郵件集散中心。這樣收件快遞員更新自己的地址本，記上： oc 的包，給快遞員老王，讓他直接去派送。下次，再有包給 oc 時，他把包交給老王，老王直接派送給 oc ，不必去郵件集散中心繞路。

這就是 VPC 主動學習功能的基本原理，能夠實現超大規模的三層網路，卻不必同步大量的轉發規則。

請看上面的圖。有兩個虛擬網路，都在同一個 VPC 之間，當他們建立之後，兩個 VM 分別加入兩個網路，它們沒有任何的溝通。最開始通訊的時候，左邊 VM 跟右邊的 VM 發包，透過預設路由線路（郵件集散中心），經過兩個節點中轉，當 DVR 發現這兩個虛擬機器真的要互相訪問的時候，才會把規則同步過去。

雖然一開始的時候效能稍微差一點。但是用著用著就快了，因為 DVR 學習到了規則。這樣，不需要真的同步 6 萬條規則到 6 萬個 DVR 節點，真正的使用者即使有了 6 萬臺虛擬機器，也不可能時時刻刻都進行著點對點互相訪問，一定會按照自己的業務往下擴充，某些 VM 之間才需要互相訪問，大部分 VM 之間其實不需要互相訪問。這樣看來，完全沒必要同步所有 6 萬條規則，只需要學到其中幾千條有用的就行了。

DVR 除了實現 VPC 功能之外，還有許多別功能。請看上面這張圖，除了 VPC ，還有其他四個方向。

第一個就是公網閘道器，為了提高公網訪問效能，DVR 跟公網閘道器可以直連；
第二是 VPC 的虛擬機器要能跟硬體裝置進行高度的互訪，因為我們私有云使用者的機房裡，不止有虛擬機器，還有 Oracle 的資料庫、F5 的路由器等等，假如我們讓使用者把這些業務放到虛擬網路裡，虛擬網路就要跟硬體網路進行高速的互訪，VPC 跟物理網路互訪透過給 VM 繫結物理網路 IP 實現，也就是說一個 VPC 的虛機，除了有自定義的虛擬 IP 地址外，還能有一個對應的物理網路 IP ， DVR 會做地址轉換，把物理 IP 轉換成私有 IP ，實現跟硬體網路高速互聯。
第三是 VPC ，可以讓使用者定義 255 個 C 段，加起來可以有 60000 多個虛擬機器。
第四，我們還提供了一個邊界路由器，可以讓使用者虛擬資源跟遠端的 IDC 之間做一個互通。

除了 VPC ，我們為私有云使用者設計了 VBC 功能。 VBC 的特點是裡面的 VM ，全部可以直接使用物理網路定義的 IP 地址，而且具備 VPC 的所有功能。 VBC 是一個私有網路和物理路由器的混合網路，能夠做到使用物理IP地址的同時，能讓 VM 在叢集中任意遷移，有保持 IP 地址不變。

最後一個就是負載均衡器叢集，設計是這樣，我們有一個閘道器叢集連著因特網。比如我有一個 IP 1.2.3.4 ，入流量傳送到 VG 1 這裡。VG 1 會做第一次的流量轉發，把流量轉發到使用者自己私有的負載均衡器節點裡（LB node1、2、3）。它的特點是，返回流量不需要經過進來的 VG 1，而是經過 LB node 對應的不同物理閘道器傳送到因特網。

因為當 VG1 能力受到限制的時候，假如我們所有流量都從它回去的時候，它自己的網路頻寬實際上就是整個叢集的能力，而我們把它分散之後，就可以做到，出去的流量幾乎是沒有限制，只要我們的 VG 裝置有多少，它的頻寬就會有多少，因為流量不需要從預設的線路回去。同時隨著使用者擴充負載均衡器節點的數量，也擴充套件了 HTTPS 的解除安裝能力。

並且我們做到了 4 層/ 7 層的完全透明，也就是說使用者透過因特網訪問到他們業務的時候，我們在所有轉發過程中，都會保留其原地址，使用者這邊得到的包是直接來自因特網使用者的 IP 地址。

QA

1、問題：有的 SDN 必須更換新的物理伺服器；有的 SDN 不需要。請幫忙分析一下。

必須更換新的物理伺服器的這種 SDN ，屬於硬體方案，軟體定義網路，硬體實現網路。典型的產品是思科N9000 系列交換機。有的 SDN 不需要換裝置，因為程式碼跑在 X86 伺服器上，也就是 NFV 實現。

2、問題：據瞭解你們新的 SDN 裡面 VM 遷移可以保持 IP 不變，你是怎麼實現的？

因為 VM 的 IP 在二層網上，使用了虛擬網路，將分散在不同物理機上的 VM ，都連成了一個二層網，但是路由器使用的是物理路由器，做到了遷移後，IP 不變，也就是虛擬交換機+物理路由器。

3、問題：LB 能否直接連線後端伺服器？

可以，不管是 VPC ，還是基礎網路，都可以，而且 TCP/HTTP/HTTPS 全透明，後端直接獲得客戶端源地址。

4、提問：剛才提到 DVR ，能不能詳細介紹一下。怎麼實現？

具體實現比較複雜，我們改了 LinuxKernel ，讓它能夠適應 DVR、MAC、IP 重複的情況。因為同一個網段的 VM ，閘道器的 MAC、IP 都的是一樣，而這些 VM 又需要有各自的 DVR 。我們改了很多虛擬交換機的邏輯，也發明了一些功能才做到，但是不太容易解釋。而且虛擬網路還能讓使用者使用虛 IP ，這也是 DVR 的一個難點。我之後還看了下 AWS 的 VPC 功能，他們還不能允許使用者定義隨便 VIP 。

5、提問：計算機都是和本地 L3 出去，在兩個網端，那你這個從本地的 L3 到外網那個 L3 這怎麼算？

從本地的 L3 到外網那個 L3 ，在 DVR 層面就是兩個虛擬路由器之間的轉發，邏輯上也是一跳。

6、提問：SDN和NFV有啥區別？

SDN 只要求軟體定義網路，可以是硬體實現， NFV 表示用軟體實現虛擬網路，屬於 SDN 的一種。

7、提問：一個 VPC 對應一個 VXLANID ？可以對應多個嗎？

青雲QingCloud 的 VPC 可以包含 253 個 VXNET ，就是虛擬網路，每個 VXNET 對應一個 VXLAN ID 。 VXLAN 閘道器是分散式，一個 VXLAN 有很多 DVR 。

8、提問：一個 VPC 內閘道器是不是分散式的，同一個 HOST 內的兩臺 VM ，不同網段互訪可以本地 DVR 轉發，還是要到專門的閘道器裝置？

本地 DVR 轉發，透過學習功能建立路由表。

9、提問：VXLAN 控制平面的自動學習是怎麼實現的？

我們自己發明的一個學習方法，要求 DVR 之間能夠互相溝通。之前有講過，就是那個快遞員之間打電話的例子。

10、提問：SDN Controller 是你們自己研發的，還是開源的？

是我們研發的

11、提問：DVR 的配置下發是怎麼實現的，是由 SDN Controller 下發的嘛？南向用了什麼協議？

Controller 下發部分規則，建立預設的路由表，更多是靠 DVR 的學習功能，裡面學習機制的通訊是我們定義的，路由同步是標準的 BGP/OSPF 這些。

原文連結：

下一代超大規模軟體定義網路技術實踐