你是軟體定義網絡(SDN)的新手嗎?你是不是被困在過去幾年的SDN熱潮?無論你屬于哪一類，都不要擔心。
網絡可程式設計性和自動化系列将帶您通過基礎的主題，開始您的網絡可程式設計性和自動化之旅，從SDN的興起開始。本章提供了圍繞SDN的網絡行業趨勢的洞察，它的相關性，以及它在當今網絡世界的影響。我們将從回顧如何開始軟體定義網絡使其成為主流，并最終導緻了圍繞網絡可程式設計性和自動化的趨勢。
1.軟體定義網絡的興起
如果說有一個人可以為網絡行業正在發生的所有變化做出貢獻的話，那就是馬丁·卡薩多，他目前是安德森·霍洛維茨基金(Andreessen Horowitz)的普通合夥人和風險投資家。之前，Casado是VMware
網絡和安全部門的進階副總裁兼總經理在VMware的業務部門。他對行業産生了深遠的影響，不僅僅是因為他的直接貢獻(包括OpenFlow和Nicira)，還因為他打開了大型網絡公司的眼界，表明網絡營運、靈活性和可管理性必須改變。讓我們更詳細地看看這個。
1.1 OpenFlow
無論好壞，OpenFlow都是軟體定義網絡(SDN)發展的第一個主要協定。OpenFlow是Martin Casado在斯坦福大學攻讀博士學位時在Nick McKeown的指導下研究的協定。OpenFlow隻是一種允許網絡裝置的控制平面與資料平面分離的協定(見圖1-1)。用最簡單的術語來說，控制平面可以被認為是網絡裝置的大腦，資料平面可以被認為是起作用的硬體或特定于應用程式的內建電路(asic)。
圖1-1 使用OpenFlow分離控制平面和資料平面
以混合模式運作openflow
如圖1-1描述沒有控制平面的網元。這代表了純openflow的部署。許多裝置還支援以混合模式運作OpenFlow，這意味着OpenFlow可以部署在給定的端口、虛拟本地網絡(VLAN)，甚至在一個正常的包轉發管道中，如果在OpenFlow表中沒有比對，則使用現有的轉發表(MAC、路由等)，使其更類似于基于政策的路由(Policy Based Routing，政策路由)。
這意味着OpenFlow是一種底層協定，用于直接與硬體表(如轉發資訊庫或FIB)連接配接，訓示網絡裝置如何轉發流量(例如，“到達目的地192.168.0.100的流量應該從48端口出口”)。
Note：
OpenFlow是一種操作流表的底層協定，是以直接影響包轉發。OpenFlow并不打算與管理平面屬性互動，比如身份驗證或SNMP參數。
由于與傳統路由協定相比，OpenFlow使用的表支援更多的目的位址，是以有更多的粒度(比對資料包中的字段)來确定轉發路徑。這與基于政策的路由所提供的粒度沒有什麼不同。就像OpenFlow多年後所做的那樣，政策路由允許網絡管理者基于“非傳統”屬性(如包的源位址)轉發流量。然而，網絡供應商為通過PBR轉發的流量提供等價的性能需要相當長的時間，而且最終結果仍然非常特定于供應商。OpenFlow的出現意味着我們現在可以在流量轉發決策上實作同樣的粒度，但是以一種廠商中立的方式。增強網絡基礎設施的功能成為可能，而無需等待制造商的下一個硬體版本。
可程式設計網絡的曆史
OpenFlow并不是第一個将控制功能和智能與網絡裝置分離的協定或技術。盡管OpenFlow是開啟SDN革命的技術，但技術和研究在OpenFlow之前已經有很長的曆史了。在OpenFlow之前出現的一些技術包括轉發和控制元素分離(ForCES)、主動網絡、路由控制平台(RCP)和路徑計算元素(PCE)。想要更深入地了解這段曆史，請參閱Jen Rexford、Nick Feamster和Ellen Zegura撰寫的論文《SDN之路:可程式設計網絡的思想史》。
雖然了解OpenFlow是什麼很重要，但更重要的是了解最初的OpenFlow規範的研究和開發工作背後的原因，這導緻了軟體定義網絡的興起。
Martin Casado多在斯坦福讀書時曾為國家政府工作。在他為政府工作期間，有必要對IT系統的安全做出反應(畢竟這是美國政府)。Martin Casado多很快意識到，他可以根據需要程式設計和操作計算機和伺服器。實際的用例從未公開過，但正是這種對端點的控制使得在需要時能夠對主機或主機組進行反應、分析和重新程式設計成為可能。
當涉及到網絡時，幾乎不可能以一種幹淨和程式化的方式來實作這一點。畢竟，每個網絡裝置都是關閉的(例如，禁止安裝第三方軟體)，并且隻有一個指令行界面(CLI)。盡管CLI在過去和現在都為網絡管理者所熟知，甚至是他們的首選，但對馬丁·卡薩多來說，它顯然不能提供真正管理、操作和保護網絡所需的靈活性。
實際上，除了為新功能添加了CLI指令外，網絡管理的方式在20多年裡從未改變過。最大的變化是從Telnet遷移到SSH，這是SDN公司Big Switch Networks在他們的幻燈片中經常使用的一個笑話，如圖1-2所示。
玩笑歸玩笑，網絡管理已經大大落後于其他技術，這也是Casado在未來幾年裡最終打算改變的。當檢查其他技術時，通常可以更好地了解這種可管理性的缺乏。其他技術幾乎總是有更現代的方法來管理許多裝置，用于配置管理和資料收集和分析。例如，hypervisor管理器、無線控制器、IP PBX、PowerShell、DevOps工具，等等。其中一些是作為商業軟體從供應商那裡緊密耦合的，但另一些則是松散的，以支援多平台管理、操作和靈活性。
如果我們回到Martin Casado在為政府工作時遇到的場景，在尋找答案時出現了什麼樣的問題?是否可以基于應用程式重定向流量?網絡裝置有API嗎?是否有一個與網絡通信的單一點?答案基本上都是否定的。怎麼可能程式設計網絡來動态控制資料包轉發、政策和配置，就像編寫程式并在終端主機上運作一樣容易呢?
最初的OpenFlow規範是Martin Casado親身經曆這些類型的問題的結果。随着業界最終開始更多地關注用例和解決方案，而不是底層協定，圍繞OpenFlow的炒作已經逐漸平息，這一最初的工作是整個行業重新思考網絡如何建構、管理和運作的催化劑。謝謝你,馬丁。
這也意味着，如果沒有馬丁·卡薩多，這本書可能就不會被寫出來，但我們現在永遠不會知道!
1.2 軟體定義網絡
我們已經介紹了OpenFlow，但什麼是軟體定義網絡(SDN)?它們是相同的東西，不同的東西，還是都不是? 說實話，SDN就像十多年前的雲一樣，當時我們還不知道雲的不同類型，比如基礎設施即服務(IaaS)、平台即服務(PaaS)和軟體即服務(SaaS)。
參考示例和設計簡化了對雲是什麼和現在是什麼的了解，但即使在這些術語存在之前，也可能存在這樣的争論:當你看到雲時，你就知道它。這就是我們軟體定義網絡所處的位置。有一些公開的定義，認為白盒網絡是SDN，或者在網絡裝置上擁有API是SDN。它們真的是SDN嗎?不是真的。
與其試圖提供SDN的定義，我們将涵蓋經常被認為是SDN的技術和趨勢，并包括在SDN對話中。它們包括:
- 開放的轉發平面（Opening up the forwarding plane ）
- 網絡功能虛拟化（Network Functions Virtualization ）
- 虛拟交換（Virtual switching ）
- 網絡虛拟化（Network virtualization ）
- 裝置應用程式接口（Device APIs ）
- 網絡自動化（Network automation ）
- 裸金屬交換（Bare-metal switching ）
- 資料中心網絡矩陣（Data center network fabrics ）
- 軟體定義廣域網（SD-WAN）
- 控制器網絡（Controller networking ）
- 基于意向網絡（Intent-based networking ）
- 基礎設施即代碼（Infrastructure as Code ）
Note：
我們有意不在本書中提供SDN的定義。雖然在本章中提到了SDN，但我們主要關注的是通常被分類為SDN的一般趨勢，以確定您更具體地了解每一個這些趨勢。
在這些趨勢中，本書的其餘部分将專注于網絡自動化、api和外圍技術，這些技術對于了解網絡裝置如何通過現代自動化工具和儀器将程式設計接口暴露在一起至關重要。
1.2.1 開放的轉發平面（Opening up the forwarding plane ）
盡管我們在前面介紹了OpenFlow作為主要颠覆者，開放轉發平面，允許外部軟體控制平面對其進行控制。在控制器和網絡裝置之間使用像OpenFlow這樣的協定的主要好處之一是真正獨立于控制器軟體和底層虛拟和實體網絡裝置的供應商。然而，在OpenFlow開發過程中所看到的現實是，标準的OpenFlow總是落後于供應商的擴充。
此外，OpenFlow的設計受到其自身抽象模組化(沒有覆寫ASIC sdk的所有功能)和ASIC中可用的預定義包處理管道(定義包将周遊的步驟)的限制，使用預定義的資料結構(表)，OpenFlow可以在運作時更改轉發狀态。
Note：
自2017年以來，OpenFlow标準開發沒有任何變化，它的采用僅限于特定的用例。
了解了OpenFlow的一些局限性，新的問題:
- 為什麼這些包處理管道是固定的?
- 為什麼我們不能定義自己的資料結構?
Barefoot Networks公司(現在是英特爾的一部分)響應了這一号召，建立了一個全新的高性能晶片家族(Tofino)，擁有完整的可程式設計執行管道，以及一種新的程式設計語言“獨立于協定的分組處理器(P4)”。
Note：
P4和OpenFlow協定規範是由同一個組織“Open Network Foundation(ONF)”驅動的。
這種颠覆性的新方法挑戰了矽谷市場現狀。遊戲中的最大玩家博通(Broadcom)推出了一種替代可程式設計解決方案(“網絡程式設計語言(NPL)”)(具有有限的可配置選項)，并在2020年通過開放其SDK(“OpenBCM”)，提供了一種更簡單的方式來程式設計他們的晶片。其他玩家也采用了某種程度的可程式設計性。例如，Cisco Silicon One或Juniper Trio/Penta解決方案支援P4可程式設計性。
Note：
傳統上，ASICs是通過晶片供應商的sdk程式設計的(在固定處理管道的限制下)，sdk公開了預先建立的資料結構和方法，以便定義如何執行分組轉發(考慮到轉發狀态資料)。
從幾年前開始，晶片廠商已經開始開放他們的sdk，這些sdk之前是根據請求和保密協定共享的，以便于他們的解決方案的第三方可程式設計性。很可能，這種變化是由業界推動ASICs的低級可程式設計性所引起的。
由于更高的成本和一些技術限制，這些高度可定制的asic今天的市場有限——一些市場預測顯示，在未來幾年，ASICs的采用将顯著增加。時間将告訴我們這個市場将如何發展，以及哪些用例将從這些可程式設計管道提供的靈活性中獲益最大。
在圖1-3中，我們看到了OpenFlow、P4和ASIC SDK的組合場景。這隻是為了說明這些不同解決方案之間的潛在互相作用。每種情況下隻使用其中一個。例如，如果您有一個底層應用程式程式設計SDK，您将公開自己的API。
對轉發平面進行程式設計，有利于更細粒度地了解流量如何穿過網絡，但能力越大，責任越大。如果你有一個開發團隊(如谷歌、亞馬遜等大公司)，或者這是你的核心業務(NOS供應商和內建商)，這是很好的。但是，對于大多數組織來說，OpenFlow、P4或任何其他固定協定的使用都不如一個整體解決方案為所支援的業務提供什麼重要。
1.2.2 網絡功能虛拟化（Network Functions Virtualization）
網絡功能虛拟化(NFV)并不是一個複雜的概念。它指的是采用傳統上作為硬體部署的功能，而不是将它們部署為軟體。最常見的例子是作為路由器、防火牆、負載平衡器、IDS/IPS、VPN、應用程式防火牆和任何其他服務/功能運作的虛拟機。
WARNING:
請不要混淆我們對NFV概念的描述和具體的ETSI NFV規範，用于電信行業。這裡，我們從抽象的角度來處理NFV，沒有具體的實作細節。
使用NFV，可以将可能花費數萬或數十萬美元的單體硬體(具有數百到數千行指令)分解為N個軟體(即虛拟裝置)。從單個裝置的角度來看，這些更小的裝置變得更易于管理。
Note:
上述場景使用虛拟裝置作為支援NFV的裝置的形式因素。這僅僅是一個例子。将網絡功能部署為軟體的形式有很多種，包括嵌入到管理程式(稱為虛拟網絡功能，VNF)、作為容器(稱為容器網絡功能，CNF)或作為運作在x86伺服器上的應用程式。
為了以防萬一，部署三到五年後才會用到的硬體并不罕見，因為逐漸更新太複雜，成本甚至更高。是以，硬體不僅是一項密集的資本成本，它隻用于如果增長發生時的假設場景。部署基于軟體或NFV的解決方案提供了一種更好的方法，可以在使用随增長付費模型時擴充并最小化網絡或特定應用程式的故障域。例如，您可以逐漸部署Cisco ASAv裝置，并随着您的增長支付費用，而不是購買單個大型的Cisco ASA。您還可以使用Avi Networks等公司的新技術輕松擴充負載平衡器，該公司現在是VMware的一部分。
盡管NFV提供了如此多的好處，但行業需要一段時間才能在生産中采用這些解決方案。實際上有幾個不同的原因。首先，它需要重新思考網絡的架構。在一個單一的單體式防火牆中(例如)，所有的東西都要經過這個防火牆——意味着所有的應用程式和所有的使用者，或者如果不是全部，也就是你所知道的一個定義集。在NFV範例中，可以部署許多虛拟防火牆，每個應用程式或租戶都有一個防火牆，而不是單一的大型防火牆。這使得每個防火牆或任何其他服務裝置的故障域相當小，并且如果正在進行更改或正在推出新應用程式，則不需要對其他基于每個應用程式(每個租戶)的防火牆進行更改。
另一方面，在擁有單體裝置的更傳統的世界中，本質上隻有一個管理安全政策的視窗——一個CLI或GUI。這可能使故障域變得巨大，但它确實為管理者提供了簡化的政策管理，因為它隻管理一個裝置。對于一些支援這些裝置的團隊或從業人員來說，這個原因可能會導緻他們保持整體式方法。
然而，在過去的幾年裡，随着IT向基于雲的環境(私有和公共)的加速過渡，客戶對更動态架構的需求促使網絡團隊建構需要使用不同類型NFV解決方案的混合網絡。在這一過程中，消費和管理以軟體為中心的解決方案的新工具的出現，以及對來自傳統和新供應商的呼籲的響應，普及了NFV解決方案的使用。
Note：
在開始階段，延遲采用NFV的一個因素是，一些供應商沒有以與其産品組合的其他部分相同的決心銷售他們的虛拟裝置版本。我們并不是說他們沒有虛拟選項，但它們通常不是許多傳統裝置制造商的首選選擇。如果一個供應商從事硬體業務已經有一段時間了，從銷售和薪酬的角度來看，這是向軟體主導模式的重大轉變。相反，現在，供應商正在投資并行發展他們的硬體和軟體解決方案。
正如将在許多這些技術領域中看到的那樣，NFV的一個主要價值也在于靈活性。消除硬體通過消除機架、堆疊、電纜和內建到現有環境所需的時間，減少了提供新服務的時間。利用軟體方法，它可以像部署新的虛拟機一樣快，這種方法的一個固有好處是能夠克隆和備份虛拟裝置以進行進一步的測試，例如在災難恢複(DR)環境中或模拟虛拟實驗室中，我們将在[即将到來的連結]中看到。此外，這種靈活性在支援新技術方面發揮着關鍵作用，如邊緣計算或5G網絡。
最後，當部署NFV時，它消除了通過特定實體裝置路由流量以獲得所需服務的需要，進而增加了根據特定服務更改網絡架構和建立服務鍊(如分段路由啟用的服務鍊)的靈活性。
1.2.3 虛拟交換（Virtual switching）
目前市場上比較常見的虛拟交換機包括VMware标準交換機(VSS)、VMware分布式交換機(VDS)、Cisco Nexus 1000V和開源的open vSwitch (OVS)。
這些交換機經常被卷入到SDN的讨論中，但實際上它們是基于軟體的交換機，駐留在管理程式核心中，提供虛拟機(以及現在的容器)之間的本地網絡連接配接。它們提供MAC學習等功能，以及鍊路聚合、SPAN和sFlow等特性，就像實體交換機多年來一直在做的那樣。雖然這些虛拟交換機經常出現在更全面的SDN和網絡虛拟化解決方案中，但它們本身隻是碰巧在軟體中運作的交換機。雖然虛拟交換機本身并不是一個解決方案，但在我們作為一個行業向前發展的過程中，它們極其重要。他們在資料中心内建立了一個新的通路層或新邊緣。網絡邊緣不再是實體機架頂部(TOR)交換機，由硬體定義，但靈活性有限(在特性/功能開發方面)。由于新邊緣通過使用虛拟交換機以軟體為基礎，它提供了在軟體中更快地建立新網絡功能的能力，是以可以更容易地在整個網絡中分發政策。以虛拟機或容器為例，在離實際終端最近的虛拟交換機端口上部署安全政策，進一步增強網絡的安全性。
1.2.4 網路虛拟化（Network virtualization）
被歸類為網絡虛拟化的解決方案已經成為SDN解決方案的同義詞。在本節中，網絡虛拟化指的是僅基于軟體的覆寫解決方案。VMware的NSX、諾基亞的Nuage虛拟服務平台(VSP)和Juniper的Contrail都屬于這一類。
這些解決方案的一個關鍵特征是使用一種基于覆寫的協定，如虛拟可擴充區域網路(VxLAN)，在基于管理程式的虛拟交換機之間建立連接配接。這種連接配接和隧道方法在獨立于實體網絡的不同實體主機上的虛拟機之間提供了第2層鄰接，這意味着實體網絡可以是第2層、第3層或兩者的結合。其結果是一個與實體網絡解耦的虛拟網絡，旨在提供選擇和靈活性。
Note：
值得指出的是，ovenlay網絡經常與underlay一起使用。為了清晰起見，underlay是您通過實體電纜連接配接起來的底層實體網絡。overlay網絡采用網絡虛拟化解決方案，在資料中心内的虛拟交換機之間動态建立隧道。同樣，這是基于軟體的網絡虛拟化解決方案。還要注意，許多純硬體解決方案現在都部署了VxLAN作為overlay協定，以便在基于Layer 3資料中心内的機架頂部裝置之間建立第2層隧道。
雖然overlay是網絡虛拟化解決方案的實作細節，但這些解決方案不僅僅是由overlay拼接在一起的虛拟交換機。這些解決方案通常是全面的，提供安全性、負載平衡和內建到實體網絡中，所有這些都是通過單一管理點(即控制器)實作的。通常，這些解決方案還提供了與最好的第4-7層服務內建，提供了可以在網絡虛拟化平台中部署哪種技術的選擇。
靈活性還得益于中央控制器平台，該平台用于動态配置每個虛拟交換機，并按需服務裝置。如果你回憶一下，由于CLI在實體世界中無處不在，網絡在操作上已經落後了。在網絡虛拟化中，不需要手動配置虛拟交換機，因為每個解決方案都提供了一個中央GUI、CLI和一個API，可以通過程式設計方式進行更改，進而簡化了這個過程。
1.2.5 裝置應用程式接口（Device APIs）
在過去的幾年中，供應商已經開始意識到僅僅提供一個标準的CLI已經不能解決問題了，使用CLI已經嚴重阻礙了操作。如果您曾經使用過任何程式設計或腳本語言，您可能會了解這一點。對于那些還沒有的人，我們将在[即将到來的連結]中讨論更多。
主要的痛點是，使用遺留或基于cli的網絡裝置的腳本不能傳回結構化資料。這意味着資料将以原始文本格式(即show版本的輸出)從裝置傳回給腳本，然後編寫腳本的人需要解析該文本以提取諸如正常運作時間或作業系統版本等屬性。當show指令的輸出稍有變化時，腳本就會由于不正确的解析規則而中斷。雖然隻有管理者才使用這種方法，但自動化在技術上是可行的，但現在供應商正在逐漸遷移到api驅動的網絡裝置。
提供API無需解析原始文本，因為網絡裝置傳回結構化資料，大大減少了編寫腳本所需的時間。它不會通過解析文本來查找正常運作時間或任何其他屬性，而是傳回一個對象，提供所需的資訊。它不僅減少了編寫腳本的時間，降低了網絡工程師(和其他非程式員)的入門門檻，而且還提供了一個更幹淨的界面，以便專業軟體開發人員可以快速開發和測試代碼，就像他們在非網絡裝置上使用api一樣。“測試代碼”可以是測試新的拓撲、驗證新的網絡特性、驗證特定的網絡配置，等等。這些都是現在手工完成的事情，非常耗時且容易出錯。
然而，這并不是一個新想法，NETCONF于2006年通過RFC4741釋出，但在一段時間内它仍然是相對較少的選擇之一，Juniper是推廣它的主要供應商。最近，其他供應商也提供了自己的API，如Arista的eAPI，這是一種基于http的API，使用json編碼的資料。思科也在特定平台上提供了API，如Nexus NX-API、NETCONF/RESTCONF和gNMI。值得注意的是，如今幾乎每家供應商都有某種類型的API，消費者需求在一定程度上推動了這種轉變。我們将在[即将到來的連結]中詳細介紹API，并在[即将到來的連結]中介紹它們使用的資料格式。
Note：
盡管使用NETCONF的Juniper或使用eAPI的Arista Networks都是API優先的，但它們還提供了CLI(在這些API之上)，因為網絡營運商仍然習慣于使用這種接口進行操作。
目前的超大規模網絡，就像那些支援大型公共雲提供商的網絡一樣，無法手動操作(仍然比對所需的卓越營運)。是以，用于管理網絡基礎設施的API(即gNMI或NETCONF)的存在一直是這些公司的硬性要求。衆所周知，像這樣的大型網絡營運商可以用這樣的請求來塑造網絡供應商的路線圖:“如果這個模型XYZ不支援接口ABC，我不會考慮它”或“如果這個功能僅通過CLI可用，它不是我們的功能”。當我們談論潛在的大額購買時，你可以想象這些句子的影響力有多大;這就是為什麼供應商近年來加強對可程式設計性的支援的一個重要原因。
1.2.6 網絡自動化（Network automation）
随着API在網絡世界中的不斷發展，更多利用它們的有趣用例也會不斷出現。在短期内，網絡自動化是利用提供API的現代網絡裝置公開的程式設計接口的主要候選者。
從更大的背景來看，網絡自動化不僅僅是自動化網絡裝置的配置。的确，這是網絡自動化最常見的感覺，但使用api和程式設計接口可以自動化，并提供比推送配置參數多得多的功能。
利用API簡化了對存儲在網絡裝置中的所有資料的通路。考慮流級資料、路由表、FIB表、接口統計資料、MAC表、VLAN表、序列号等資料，這個清單可以無窮無盡。使用現代自動化技術(反過來利用API)可以快速幫助管理網絡的日常操作，以進行資料收集以及自動化診斷和修複。最重要的是，由于正在使用傳回結構化資料的API，作為管理者，您将有能力顯示和分析您想要和需要的确切資料集，甚至來自各種show指令，最終減少調試和排除網絡問題所需的時間。你可以使用自動化技術來簡化這個過程，甚至可以在睡眠時定期運作它，而不是連接配接到N個運作BGP的路由器來驗證配置或排除問題。
此外，利用自動化技術可以使整個網絡更加可預測和統一。您可以看到它是通過自動建立配置檔案、自動建立VLAN或自動處理故障。它簡化了特定環境的所有使用者的處理過程，而不是讓每個網絡管理者擁有自己的最佳實踐。
第二章将更深入地介紹各種類型的網絡自動化。
1.2.7 裸金屬交換（Bare-metal switching）
裸金屬交換的話題也經常被認為是SDN，但事實并非如此。真的,不是!也就是說，在我們介紹被認為是SDN的各種技術趨勢的努力中，需要涵蓋它。如果我們回到2014年(甚至更早)，用來描述裸金屬交換的術語是白盒。這個詞變了，而且不是沒有充分的理由。
在我們介紹從白盒到裸金屬的變化之前，重要的是要了解這在高層次上意味着什麼，因為這是人們如何看待網絡裝置的一個巨大變化。在過去的20年裡，網絡裝置總是作為實體裝置購買的，這些實體裝置以硬體裝置、作業系統和可以在系統上使用的功能/應用程式的形式出現。這些元件都來自同一個供應商。
在白盒和裸機網絡裝置中，裝置看起來更像一個x86伺服器(見圖1-4)。它允許使用者分解每個必需的元件，使從一個供應商購買硬體，從另一個供應商購買作業系統，然後從其他供應商甚至開源社群加載功能/應用程式成為可能。
在OpenFlow大肆宣傳的一段時間裡，白盒交換是一個熱門話題，因為其目的是将硬體商品化，并将網絡的大腦集中在OpenFlow控制器(現在也稱為SDN控制器)中。在2013年，谷歌宣布他們已經建構了自己的交換機，并使用OpenFlow來控制它們!這是當時許多行業讨論的主題，但實際上，并不是每個最終使用者都是谷歌，是以并不是每個使用者都會建構自己的硬體和軟體平台。
在這些努力的同時，我們看到了一些公司的出現，它們隻專注于圍繞白盒轉換提供解決方案。它們包括Big Switch Networks(現在是Arista Networks的一部分)、Cumulus Networks(現在是NVIDIA的一部分)和Pica8。它們都提供了純軟體解決方案，是以它們仍然需要運作其軟體的硬體來提供端到端的解決方案。最初，這些白盒硬體平台來自原始直接制造商(ODM)，如Quanta、Super Micro和Accton。如果你從事網絡行業，很可能從未聽說過這些供應商。
直到Cumulus和Big Switch宣布與惠普和戴爾等公司建立合作關系，業界才開始将這一趨勢從白盒(white-box)轉向裸機(bare-metal)，因為現在知名廠商已經開始在自己的硬體平台上支援Big Switch和Cumulus Networks等第三方作業系統。
為什麼裸金屬在技術上不是SDN，這可能仍然是一個困惑，因為像Big Switch這樣的解決方案在兩個世界都可以發揮作用。答案很簡單。如果有一個控制器使用OpenFlow(不一定是OpenFlow)這樣的協定與解決方案內建在一起，并且它以程式設計方式與網絡裝置通信，那麼它就具有軟體定義網絡的特性。這就是Big Switch所做的——他們在裸機/白盒硬體上加載軟體，運作OpenFlow代理，然後作為解決方案的一部分與控制器通信。
另一方面，像NVIDIA Cumulus這樣的NOS提供了專門為網絡交換機建構的Linux發行版。該發行版或作業系統運作傳統協定，如LLDP、OSPF和BGP，不需要任何控制器，使其與基于非sdn的網絡架構更具可比性和相容性。
通過這個描述，可以明顯看出Cumulus是一家網絡作業系統公司，他們的軟體運作在裸金屬交換機上，而Big Switch是一家基于裸金屬的SDN公司，需要使用他們的SDN控制器，但也利用了第三方裸金屬交換基礎設施。
目前，幾乎所有的NOS都以Linux為基礎作業系統。作業系統運作在使用者空間，負責運作控制平面和管理平面協定。由于使用者空間内固有的包轉發性能限制(核心接收到的每個包都會引起軟CPU中斷，網絡裝置将處理大量的包!)，NOS将包轉發轉移到交換矽（switch silicon）通過其特定的驅動程式，繞過核心。
快速資料路徑(xdp)
在Linux中改善網絡性能的另一項重要的新技術是快速資料路徑(XDP)。這是一個架構，允許自定義程式很早就注入到分組處理路徑中，并純粹在核心空間中執行。這些程式由eBPF(從4.8版開始在Linux核心中提供)提供支援，它是已經存在一段時間的伯克利分組過濾器(BPF)的發展(例如，由tcpdump使用)。由于XDP程式涉及處理分組的階段，與流經核心其餘處理步驟和從使用者空間複制記憶體相關的大部分開銷可以避免，進而可能帶來更高的性能。XDP和eBPF将在[即将到來的連結]中詳細介紹。
在所有這些網絡作業系統中，根據與核心互動的方式以及其他應用程式與之互動的方式，可以劃分為三類。
純使用者空間
NOS獨立于核心實作整個網絡堆棧，例如在基于dpdk的網絡作業系統(例如FD.io)和Cisco NX-OS中。
混合Linux核心
NOS和核心網絡資料結構之間使用Netlink進行部分互動，Netlink是Linux核心中用于同步其網絡狀态的套接字族。有不同層次的互動，但在大多數情況下，關鍵的NOS的應用程式(即路由協定棧)保持狀态在使用者空間，隻使用一些來自核心空間的資料，例如，ARP/ND狀态。這個群展現在是最擁擠的:微軟的SONiC /Open Compute Project, Arista Networks的EOS等等。
完整的Linux核心
這類完全依賴Linux的網絡狀态資料結構和API。Cumulus Linux是這一類中的主要例子，它與DentOS等其他例子一起成長。
在圖1-5中，描述了三種不同的方法，顯示了應用程式、NOS堆棧和Linux核心之間的互動級别。
使用核心API為插入做同樣事情的其他Linux應用程式打開了大門，這樣您就可以選擇一個更好地解決您的需求而無需重新發明輪子。例如，如果你需要一個路由守護程序，你可以使用“FRR路由”(來自Quagga項目)。此外，大家可以使用新的核心特性，如XDP或switchdev，這是一個新的裝置抽象模型，用于與交換矽（switch silicon）通信。
TIP
關于這個主題的一個很好的參考是Dinesh G. Dutt的《雲原生資料中心網絡》一書中的“第四章—網絡作業系統選擇”
簡而言之，裸金屬/白盒交換是關于分解和從一個供應商購買網絡硬體和從另一個供應商加載軟體的能力，如果您選擇這樣做的話。在這種情況下，管理者可以靈活地更改設計、體系結構和軟體，而無需更換硬體，隻需要更換底層作業系統。
1.2.8 資料中心網絡矩陣（Data center network fabrics）
你是否曾經遇到過這樣的情況:即使網絡中所有的網絡裝置都運作着标準的協定，例如生成樹或OSPF，你也不能輕易地交換它們?如果你有，你并不孤單。想象一下，有一個資料中心網絡，其中有一個折疊的核心，每個機架頂部都有獨立的交換機。現在想想更新時需要發生的過程。
有很多這樣的方式來更新網絡，但如果隻是需要更新的TOR交換機，并且在對新的TOR交換機進行評估的過程中，決定使用新的供應商或平台，怎麼辦?這是100%正常的，而且已經做了一次又一次。這個過程很簡單——将新交換機連接配接到現有的核心(當然，我們假設核心中有可用的端口)，如果是二層互連，則正确配置802.1Q叢集，如果是三層互連，則配置您喜歡的路由協定。
進入資料中心網絡矩陣。這就是關于資料中心網絡的思考過程必須改變的地方。
資料中心網絡矩陣旨在改變網絡營運商從“一次管理單個盒子”到“整體管理整個系統”的思維方式。如果我們使用前面的場景，就不可能将TOR交換機換為另一個供應商，這隻是資料中心網絡的一個元件。相反，當網絡作為一個系統被部署和管理時，需要将其視為一個系統。這意味着更新過程是從一個系統遷移到另一個系統，或者從一個矩陣遷移到另一個矩陣。在矩陣的世界裡，當需要更新的時候，矩陣是可以更換的，但矩陣中的單個元件不能更換——至少在大多數情況下是這樣。當特定供應商提供遷移或更新路徑以及使用裸金屬交換(僅替換硬體)時，這是可能的。資料中心網絡矩陣的幾個例子是思科的應用中心基礎設施(ACI)、Big Switch的大雲網絡(BCF)(現在是Arista網絡的一部分)，或者Plexxi的Fabric(現在是Aruba的一部分)和超融合網絡。
除了将網絡視為一個系統，資料中心網絡矩陣還有以下幾個共同屬性。
- 它們提供了管理或配置矩陣(包括政策管理)的單一接口。
- 它們在整個架構中提供分布式預設網關。
- 它們提供多路徑功能。
- 他們使用某種形式的SDN控制器來管理系統。
1.2.9 軟體定義廣域網（SD-WAN）
過去幾年軟體定義網絡中最熱門的趨勢之一是軟體定義廣域網絡(SD-WAN)。在過去的幾年裡，越來越多的公司成立來解決廣域網絡的問題。
NOTE
其中很多初創公司都被主流的網絡和安全供應商收購，例如Cisco的Viptela、PaloAlto Networks的CloudGenix、VMWare的VeloCloud、Aruba的Silverpeak以及Juniper的128 Technology，這表明了這些解決方案對所有供應商的投資組合的重要性。
自從從幀中繼遷移到多協定标記交換(MPLS)之後，廣域網還沒有看到技術上的重大轉變。由于寬帶和網際網路的成本隻是相當于專用線路成本的一小部分，近年來利用點對點VPN隧道的成本有所增加，為廣域網的下一個大事件奠定了基礎。
遠端辦公室的常見設計通常包括專用(MPLS)電路和/或公共網際網路連接配接。當兩者都存在時，internet通常隻用于備份(特别是客戶流量)，或通過VPN傳回到企業的一般資料，而MPLS電路用于低延遲應用程式，如語音或視訊通信。當流量開始在電路之間配置設定時，這增加了路由協定配置的複雜性，也限制了如何路由到目的位址的粒度。在選擇最佳路徑時，通常不會考慮網絡的源位址、應用和實時性能。
許多現代解決方案使用的通用SD-WAN架構類似于資料中心中使用的網絡虛拟化，因為overlay協定用于連接配接SD-WAN邊緣裝置。由于使用了overlay層，該解決方案與底層的實體傳輸無關，是以SD-WAN可以在網際網路或專用廣域網上運作。這些解決方案通常在分支站點上通過兩個或多個internet電路，使用IPSec對流量進行完全加密。此外，許多這些解決方案不斷測量每個正在使用的電路的性能，即使在停電期間，也能夠快速地在特定應用的電路之間進行故障轉移。由于應用層可見，管理者也可以輕松地選擇哪個應用程式應該采用特定的路由。這些類型的特性通常在僅依賴于使用傳統路由協定(如OSPF和BGP)的基于目的路由的廣域網架構中是找不到的。
從體系結構的角度來看，前面提到的供應商的SD-WAN解決方案通常還提供某種形式的零接觸供應(ZTP)和集中式管理，其中門戶作為基于saas的應用程式存在于場所或雲中，進而大大簡化了未來WAN的管理和操作。
使用SD-WAN技術的一個有價值的副産品是，它為最終使用者提供了更多的選擇，因為基本上任何營運商或類型的連接配接都可以在WAN上和跨internet使用。這樣做可以簡化營運商網絡的配置和複雜性，進而使營運商簡化其内部設計和架構，有望降低成本。再進一步，從技術角度來看，所有邏輯網絡結構(如虛拟路由和轉發(VRFs))都将通過SD-WAN供應商提供的控制器平台使用者界面(UI)進行管理，這樣當需要更改時，就不需要等待數周才能得到營運商的響應。
1.2.10 控制器網絡（Controller networking）
正如你可能已經意識到的，當涉及到這些趨勢時，有一些重疊。當你試圖了解過去幾年出現的所有新技術和新趨勢時，這是令人困惑的一點。
例如，流行的網絡虛拟化平台使用控制器，屬于資料中心網絡矩陣、SD-WAN和裸金屬交換機類别的幾種解決方案也是如此。困惑嗎? 您可能想知道為什麼基于控制器的網絡被單獨打破。實際上，它通常隻是提供現代解決方案的特征和機制，但從技術角度來看，并非所有之前的趨勢都涵蓋了控制器可以提供的所有内容。
例如，一個非常流行的開源SDN控制器是OpenDaylight (ODL)，如圖1-6所示。與許多其他控制器一樣，ODL是一個平台，而不是産品。這些平台可以提供專門的應用程式，如網絡虛拟化，但它們也可以用于網絡監控、可見性、tap聚合或與位于控制器平台之上的應用程式一起使用的任何其他功能。這就是為什麼了解控制器除了用于更傳統的應用程式(如fabric、網絡虛拟化和SD-WAN)之外還能提供什麼很重要的核心原因。
1.2.11 基于意向網絡（Intent-based Network）
與SDN相關的另一個流行詞是基于意圖的網絡(IBN)，這是一個抽象的概念，不同的人有不同的了解方式。試圖從幾個描述中闡明關鍵的公共方面，我們可以總結:使用業務語言管理網絡的能力(目的)，而不關注低級細節，以及利用這種更高的抽象級别将複雜性從一邊轉移到另一邊。
在幕後，IBN解決方案是由幾個元件(前面提到的一些技術)組成的，用于将使用者意圖轉化為實際的網絡操作任務。在大多數解決方案中可以看到的一個常見模式是遵循以下工作流程(參見圖1-7):閉環編排的自主操作，能夠對事件做出反應(類似于事件驅動的自動化)。
- 将抽象的意圖定義從業務需求轉換為實際的網絡變化。這是最難的部分，因為對于“在應用程式a和應用程式B之間建立安全連接配接”這樣的簡單請求，需要解決許多開放性問題，“這些應用程式在網絡資料(IP位址和端口)方面的細節是什麼?”，“在這種情況下，安全連接配接是什麼意思?”，“哪些是路由路徑中涉及的網絡裝置或VNFs ?””等。最後，這些詳細資料将存儲在一個位置，該位置将定義網絡的預期狀态。這也被稱為真理之源，我們将在後面的連結中談到它。
- 一旦預期的狀态被正确地轉換并存儲到适當的資料模型中，自動化編排過程将利用自動化引擎在網絡中執行所需的狀态。這個階段的主要挑戰是将一個網絡服務分解成多個網絡元素，每個網絡元素具有不同的管理接口和資料模型，執行原子性更改(我們不希望部分部署網絡更改)。
- 在實際/觀察到的網絡狀态與預期的比對之後，工作還沒有結束。網絡是動态的，是以對網絡狀态(包括度量、日志和網絡流)的持續觀察将有助于做出決策，使網絡恢複到預期的狀态。在[即将到來的連結]中，我們将了解一些趨勢，比如流式遙測技術，它可以幫助我們改善狀态資料收集。
- 為了關閉循環，将分析所有收集到的資料(适當地使用相關業務資料)，以确定觀察到的狀态和預期的狀态是否比對，如果不比對，則在步驟2中觸發必要的操作來糾正它。
由于其内在的複雜性，這一領域的大多數解決方案都是封閉的專有平台(通常以控制器的形式)，這些平台在上述循環中執行前面的所有步驟。不幸的是，由于這些解決方案的封閉性質，它們不容易擴充和适應受支援用例之外的定制需求，這使得管理異構環境非常複雜。然而，也可以建構您自己的基于意圖的解決方案，正如我們将在[即将到來的連結]中看到的，了解功能需求并确定正确的元件和互動，根據需要結合開源和專有解決方案。你可以從供應商那裡購買組裝好的個人電腦，也可以購買不同的元件(主機闆、磁盤、記憶體等)并将它們組裝在一起。這個選項并不容易，但它使您有機會根據自己的特定需求對其進行定制。
1.2.12 基礎設施即代碼 （Infrastructure as Code）
在軟體開發和系統基礎設施團隊中，與網絡世界的SDN革命并行的是一種消費IT服務的新方式。在采用配置管理方法(見[即将到來的連結])之後，公共雲服務和容器化的興起導緻了IT基礎設施服務的動态供應，直接來自代碼庫。這種趨勢被稱為代碼式的基礎架構，包括在文本檔案中描述所需的基礎架構狀态，這些文本檔案稍後将被解釋為采取必要的行動使它們成為現實。這種模式與DevOps文化完美比對，在DevOps文化中，開發人員和操作工程師在同一個項目上一起工作，使用相同的代碼庫開發應用程式，并定義這些應用程式将在哪裡運作的基礎設施。在圖1-8中，我們觀察到，在通過API提供基礎設施定義之後，如何傳回結果狀态，并建立動态基礎設施資源的實際辨別符。
TIP
要更全面地了解這個概念，請查閱Kief Morris的《基礎設施作為代碼》一書。
與此同時，這種做法也被習慣于從公共雲提供商、容器運作時環境(即Kubernetes)或其他提供商(如用于多雲環境的Alkira和Aviatrix或用于動态網絡連接配接的PacketFabric)啟動網絡基礎設施服務的網絡工程師所采用。
Note
雲中的網絡已經改變了今天企業網絡的面貌，增加了新的挑戰，如在叢集之間協調覆寫網絡或與本地的雲網絡互連。為了在本地環境和雲環境之間建構一緻的端到端網絡服務，我們需要了解雲網絡服務的組網特征和限制。我們将在[[即将到來的連結]中深入讨論這個話題。
有幾種将文本檔案轉換為動态基礎設施的替代方案，但是Hashicorp開發的Terraform非常受歡迎。它是一個開源工具，由供應商或社群建立的多個提供者(成千上萬個)組成。你将在[即将到來的連結]中了解更多。然而，也有其他的選項，具體到每個提供商(例如AWS的CloudFormation或GCP中的谷歌部署管理器)和其他的，而不是使用DSL(領域特定語言)，允許你直接使用編碼語言，如Python或Go(例如Pulumi)。
采用基礎設施作為代碼給網絡操作帶來了新的挑戰。正如每個人都會了解的那樣，一旦有人在幾秒鐘内準備好了一個服務，就會開始詢問其他服務，比如建立一個簡單的ACL條目或一個新的VLAN，這可能需要幾天的時間，因為這在一些網絡中仍然是常見的事情。這個問題的答案是采用網絡作為服務的思維方式，提供正确的使用者界面和自動化編排，以提供目前業務操作所需的靈活性。
Note
建構網絡即服務的應用程式與建構任何軟體即服務的應用程式類似，“the Twelve-Factor App”是一個很好的參考，它解釋了一個應用程式為了适合在現代雲平台上運作應該堅持的特征。
這些建議中的一個關鍵思想是打包代碼、其依賴項和配置(針對每個運作時環境)。充分利用容器(如Docker, Podman)和不可預知的運作時環境，如Kubernetes項目或由Hashicorp的Nomad。我們将在[[即将到來的連結]中讨論這些話題。
一開始，将傳統網絡服務轉換為這種範式似乎有些吓人，但您可以通過将所有必要的建構塊(我們将在本書中介紹的那些)組合在一起的政策來實作它，并一步一步地改變您的網絡可以如何操作和使用。
2. 總結
現在你有了它:一個關于最常被歸類為軟體定義網絡的趨勢和技術的介紹，通過網絡可程式設計性和自動化為更好的網絡操作鋪平了道路。在過去的7年裡，數十家SDN初創公司誕生了，VC投資了數百萬美元，并花費了數十億美元來收購這些公司。這是不真實的，如果我們進一步分解它，它的共同目标是利用軟體原則和技術，在提高操作效率的同時，為技術使用者提供更強大的功能、控制、靈活性和選擇。
在下個章節中，我們将看一看網絡自動化，并深入研究各種類型的自動化、一些通用協定和API，以及自動化在過去幾年是如何開始發展的。