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

雲計算的 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 方案主要分成兩個方向：

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

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

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

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

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

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

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

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

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

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

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

下面分别解釋這三點：

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

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

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

拿計算機的術語來講，内部郵件系統就是虛拟快遞公司，真正派件的快遞公司，叫做實體快遞公司。虛拟網絡非常類似，允許使用者通過自己定義的位址，進行傳輸。這個位址使用者随便定義，反正實體網絡看不到這個位址，也就不受任何限制。

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

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

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

1. 隧道連接配接一組實體機。 VXLAN 發包時，可以任意指定目标實體 IP 位址和 ID ，不像 GRE 那樣，要在兩邊配置點對點的連接配接；
2. 使用 UDP 協定。 UDP 協定的特點是有端口。發包時每個連接配接都使用不同的源端口。當資料包交給目标伺服器網卡的時候，網卡根據這個資料的標頭的 IP/端口做 HASH 運算，用于選擇不同的網卡隊列。而每個網卡隊列會綁定到一個 CPU 上面，這樣把包會交給不同的 CPU 處理，提升總體性能；
3. 使用基于多點傳播的 Flood & Learn 模式自動管理虛拟網絡。這個功能會大幅降低元件虛拟網絡的複雜度，因為 VXLAN 的終端，會根據資料包標頭的内容，自動建立，并維護一個轉發表。回包的時候，根據轉發包找到目的實體機的位址。

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

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

1. 發送廣播包時，使用了多點傳播協定，大規模部署會受硬體裝置多點傳播路由限制。它在二層網絡中使用時，沒什麼問題，但是在三層網絡中使用時，實體路由器上會建立大量的多點傳播路由條目，影響路由器性能，并且增加了路由器運維的難度。
2. 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 是 [email protected] 。這樣下次在有到 2pw067 的郵件，他直接給 [email protected] 發郵件，通知他來取件，而不是群發所有人。這個方式最大的問題是，收發室老會群發郵件，而且他每隔一段時間，就要确認下 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 了。然而我們在做雲計算平台時，通過長時間的積累，還發現了很多需求：

1. VPC，并且 VPC 主機直接綁定公網 IP 。
2. 負載均衡器。可在公網網關上對入流量進行分流，轉發到多個負載均衡器節點。
3. VM 使用基礎網絡時，也就是實體網絡的 IP 位址在遷移後不變。
4. 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 這些。

原文連結： https://community.qingcloud.com/topic/336/