云計算的 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 是 [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 了。然而我們在做云計算平臺時，通過長時間的積累，還發現了很多需求：
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 地址。
Q&A
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 這些。
京公網安備 11010502049343號