有些朋友一看這個問題可能會有些不知所云，如果SDN控制器不管物理交換機，那么它管什么呢?答案是只管理虛擬交換機。這里，博主需要插入一個簡短的科普。自從云計算盛行以來，主機虛擬化技術已經深入人心。任何一臺物理主機上都可以同時運行多個虛擬機(docker是另外一個話題)。那么問題來了，一臺虛擬機的網絡接口是如何接入到物理網絡的呢?最初，人們會在物理主機上跑一個軟件hub，所有虛擬機的網口都會接入到這個軟件hub。這個hub會有一些端口和物理主機的網卡相連。隨著主機虛擬化技術的不斷完善，這個軟件hub逐漸被軟件交換機(software switch)所取代，其中最具代表性的是open virtual switch(OVS)。雖然叫交換機，但其實它也可以做三層路由，訪問控制(ACL)甚至是一些動態的路由協議。在SDN和OpenFlow的概念最初被提出時，它的原型系統就是由一個SDN控制器集中控制多個OVS，在OVS之間建立全互聯的隧道(full mesh tunnel)。在這樣的架構下，SDN控制器和OVS都是普通的軟件，不需要任何特殊的硬件支持。于是SDN控制器和OVS都得到了快速的迭代。這種SDN架構也成就了Nicira。時至今日，Nicira的SDN解決方案仍然是用控制器控制所有的OVS。物理網絡仍然采用傳統的二層三層協議。業界往往稱Nicira的SDN架構為overlay方案。這種方案最大的好處有兩點：首先，所有的OVS流表都裝在服務器內存里，理論上可以支持巨大的流表。第二，overlay方案根本不控制物理交換機，部署靈活，就如同在服務器上裝一個軟件，單憑這一點就可以快速贏得客戶。

用SDN控制器管理物理交換機最早出現在2008年的Sigcomm上。與overlay方案對應， 博主把這種方案成為underlay。由于絕大多數硬件交換芯片是為二層和三層交換設計的，而OpenFlow的轉發模型卻是wildcard match + action，導致在很長的一段時間以內人們只能把OpenFlow消息轉化為TCAM表項。即便到了今天，最成熟的商用硬件交換芯片也僅僅支持10^3數量級的TCAM表項，這成為了使用SDN控制器控制物理交換機最大的瓶頸。圍繞這個瓶頸，世界各地的專家們前赴后繼。目前主要分為兩個陣營。Nick McKeown教授作為SDN的發起人之一，主張徹底重新設計硬件交換芯片，目的是讓硬件交換芯片支持多級流表，每一級流表都支持match + action。另外一個陣營則以Rob Sherwood為代表，主張挖掘現有硬件交換芯片的潛力，充分的排列組合OpenFlow協議中的match和action，盡量把match+action在二層和三層的流表中實現。TCAM流表僅僅用來應對一些復雜ACL。無獨有偶，盛科張衛峰總的主張也和這個觀點不謀而合。看來學院派的人士充滿了理想主義情懷，工業界人士傾向于漸進式的創新。

科普完畢，業界有人在采用overlay的方案，也有人在嘗試underlay的方案。那么那個選擇更合理呢?在這里希望大家做個深呼吸，稍微深入的思考一下這個問題。博主的教訓是無論選擇哪個技術流派，你都為自己挖下了一個巨大的坑，這個坑你逃不過。在某一個階段，你一定會或多或少的后悔：如果當初做另外一個選擇就好了。我們不妨先看看業界大佬的觀點是啥。你會突然發現：大佬們原來也在努力從自己挖的坑里爬出來啊。

Scott Shenker, 這位大神就沒必要介紹了，作為著作被引用最多的計算機科學家，作為SDN的發起人之一，ONF的發起人之一，他的觀點犀利且富有前瞻性。關于SDN他有兩次廣為流傳演講，分別在2011年(The Future of Networking, and the Past of Protocols)和2013年(Software-Defined Networking at the Crossroads)。對比這兩次演講，大家不難發現對于用SDN控制器管理整個物理網絡，Scott從堅定的支持派變成了反對派。他轉變的主要原因其實只有一點：不計其數的網絡服務需要靈活部署，不計其數的網絡策略需要快速準確的執行，所有這些從網絡邊緣實施會更加容易高效，邊緣以內的物理網絡僅僅需要扮演一個水管的角色，是否用SDN集中控制不重要。在他描述的世界中，SDN控制器控制OVS給網絡報文打上不同的tag，物理網絡只需要根據tag轉發就好了。

在另一個方面，雖然Nicira是overlay SDN解決方案的旗幟性公司，但Nicira也逐步開始管理物理交換機了，至少是開始管理top-of-rack(ToR)了。這里我們不妨看一下Nicira大神Bruce Davie的兩篇博客。在2011年，用open virtual switch打隧道棒極了，部署靈活，服務多樣，各種流表無限大，性能也號稱沒有明顯的瓶頸[link]。但是在2013年,Bruce忽然話風一轉，開始把隧道放在了ToR上，他把原因主要歸結于支持bare metal服務器[link]。所謂bare metal服務器是指那些沒有采用虛擬化技術的主機，在這些主機上，沒有OVS，overlay方案自然也無計可施。為了在這種環境中部署overlay SDN解決方案，隧道被很自然的打在了ToR上。在Bruce 2013年那篇博客的結尾，他這樣總結了兩種方案的取舍“Our expectation is that software gateways will provide the greatest flexibility, feature-richness, and speed of evolution. Hardware VTEPs will be the preferred choice for deployments requiring greater total throughput and density”。博主我真是太佩服這些大神的說話技巧了。如果我們仔細揣摩它的后半句，不難發現，Bruce在暗指用OVS打隧道可能會成為吞吐量的瓶頸。兄弟這里沒有數據，于是斗膽引用盛科張衛峰總的一篇微博“做VPC網絡性能對比測試的，發現單向打包測試的時候，1G情況下，軟硬件方案性能差異也就10%的差距，而一旦測試雙向打包，發現性能對比一下子明顯了，差不多有40%的差距。另外一個明顯的對比是10G下的時延測試，軟件是毫秒級，硬件方案是微秒級”。博主我猜這里的VPC是指“Virtual Private Cloud”而不是指其他東西，我不了解此項測試的具體內容和方法，在此引用是希望讓廣大的工程獅兄弟們在決定跳入overlay大坑的時候對性能要格外關注，特別是在決定要大規模部署之前。

在博主看來，優秀的解決方案總是會最終趨同的。這種現象有些時候會被人誤解為抄襲。但事實往往是人們通過不同的路徑到達了同一個結論。在SDN的世界里，這個結論已經呼之欲出了：我們需要SDN控制器同時管理overlay和underlay，博主把它稱作fullstack。也許這個名稱并不合適，但大家領會精神就好。在分析這個結論之前，我們看看各個廠家都在做什么。Cisco作為傳統的網絡設備提供商，早已經把觸角伸到了overlay甚至是更上層的各種應用，正在進行的ACI與OpenStack的深度整合就是最好的例證。VMWare在2014年10月份將Guido Appenzeller招致麾下，讓人對VMWare涉足物理網絡產生無盡聯想。Big Switch Networks的overlay和underlay解決方案都已經成熟，目前正致力于將二者結合。各大廠家不約而同的開始向一個方向發力，也印證了fullstack是未來的方向。那么究竟是什么原因讓大家棄overlay和underlay而轉向fullstack呢?

先說說overlay方案的局限。首先，它太!貴!了!這個賬怎么算呢?比如我們要采用overlay的方案建立一個多租戶的數據中心。物理網絡的解決方案本身就需要花一筆錢。服務器虛擬化解決方案是第二筆錢(更高大上的術語是orchestration，比如OpenStack的nova)。這還不夠，我們還需要將overlay SDN解決方案和orchestration系統深度整合，用SDN控制器管理每個服務器上面的OVS，這是第三筆錢。如果采用fullstack，這三筆錢就會變成兩筆。第一筆是用orchestration解決方案管理虛擬機和bare metal服務器，第二筆錢是用fullstack SDN方案管理整個網絡，物理網絡解決方案的開銷就完全省掉了。fullstack SDN控制器可以通過plugin的形式和orchestration系統深度整合，正如OpenStack的Nova和Neutron之間的關系，只是在這里Neutron plugin通過fullstack SDN控制器直接控制整個網絡，而不是像OpenStack Juno release那樣僅僅在OVS上做分布式路由(DVR)。

overlay方案的另外一個致命的問題是它并沒有完全的從物理網絡解耦合，仍然需要服務器管理團隊和網絡管理團隊的密切合作。一種最常用的多租戶解決方案是用vlan區別不同租戶，也就是說，在overlay方案中每增加一個租戶，網絡管理員就需要在物理網絡中人工配置一個vlan，這一個人工參與的環節就可能引發諸如配置錯誤，網絡升級困難等問題。另外一種做法是采用vxlan，問題是vxlan需要物理網絡支持ip multicast，這個協議troubleshooting起來又相當麻煩。在vxlan和非vxlan交界的地方還需要部署vxlan gateway，但這個vxlan gateway又往往成為性能瓶頸，飽受詬病。這里，博主可以舉出更多的例子。但核心觀點是: 本來只有一張網，引入overlay之后就需要維護兩張網，并且兩張網還需要彼此協調，運維成本并不會便宜。

第三個overlay方案可能存在的問題是它的性能，這一點在之前的段落中已經有所涉及。到2014年10月為止，博主并沒有做過overlay方案的性能測試，這一段留個空白，以后補齊。

下面我們來看一下underlay方案的不足。現在市場上underlay的解決方案很多，大概分為兩類，一種是用控制器集中管理配置，交換機之間仍然采用分布式的二層三層協議。另外一種是用控制器直接控制所有的交換機的轉發行為，交換機之間不跑任何分布式協議。不論哪一類，它們離上層的應用都太遠了，正如博主在第二篇文章中舉的例子那樣，每新增一個租戶，每部署一個多級的應用或者每插入一個網絡服務，都需要網絡管理員進行仔細的規劃和手工的配置。其實overlay解決方案的產生以及NFV(network function virtualization，在以后的文章中會詳細討論)的興起本質上都是由于underlay方案的這個不足。

好了，分析完overlay和underlay方案的不足，希望大家也開始理解為什么SDN誕生了那么久，但總給人一種雷聲大雨點兒小的感覺。因為現有的SDN解決方案不是overlay就是underlay，它們都有一些自身難以越過的局限。在經歷了幾年痛苦的學習過程之后，業界終于意識到：如果再在overlay還是underlay這個問題上糾纏，情況不會有任何改觀。于是各大廠家都開始向fullstack轉型，用一個SDN控制器管理所有的物理交換機和OVS。因為只有這樣才能1) 用最經濟的方式部署上層應用和網絡服務，避免一切的box by box的手動配置，2) 沒有overlay方案的性能瓶頸。成熟的fullstack方案已經箭在弦上，對于SDN的大規模部署博主持非常樂觀的態度。