網路可程式設計與驗證

作者簡介：唐昊，現就職於華為，從事雲網絡研發工作。本文所有觀點僅代表作者個人觀點，與作者現在或者之前所在的公司無關。

管理網路一直以來是一個十分複雜的工作，網路工程師需要負責管理網路裝置、提供使用者許可權、配置網路策略等等工作。根據Gartner的資料顯示，75%的組織仍然通過手動操作來管理他們的網路，很多組織仍然使用最初的命令列介面（CLI）。CLI的缺點也很明顯，因為缺少錯誤特定的返回程式碼，自動化工具還必須處理輸入或輸出文字中的偶爾錯字。CLI通常與手動配置更改有關，這也是造成企業網路中斷的主要原因。

網路業界的發展總是伴隨著新技術的應用，五年前，資料中心是Ethernet Fabrics，後來是SDN，其核心理念是將轉發與控制進行分離，以此提高網路的執行效率和網路的靈活性。目前是SD-WAN，隨著SD-WAN的不斷髮展，網路領域最新的風口是基於意圖的網路IBN（Intent based network）。Verification and Intent-Based Networking: Closing the Control Loop文章中，描述了基於意圖網路的最基本的系統框架，如下圖所示。

簡單的講就是把使用者對網路的意圖翻譯成配置，然後通過網路自動化或網路編排的方式下發到裝置上。最後對實際網路進行週期性的快照，驗證是否符合使用者意圖，形成一個閉環。這裏就不詳細解釋了，因為現在網上有許多文章解釋IBN，大家可以搜一下。

Introduction

上一篇文章Robotron和Ansible如何實現網路可程式設計和自動化中，介紹了Facebook Robotron專案，有興趣的人可以看一下論文作者Xiaozheng Tie在2017年[email protected]會上的演講，其中強調了FBNet物件模型的重要性，在Facebook裡許多其他網路專案都是基於FBNet模型開發的。其中FCR – FBNet Command Runner是Robotron系統的一部分，負責對裝置的進行下命令，目前已經開源。這裏不詳細介紹，有興趣的人可以看這篇文章：Open source command runner for network devices。除此之外上一篇文章還介紹了Red Hat公司推出的Ansible網路自動化方案。本文將介紹幾家巨頭公司的可程式設計網路與驗證專案，其中 Cisco Crosswork Change Automation 使用了Ansible對網路裝置進行自動化部署。本文中還會介紹 Alibaba NetCraft 網路可程式設計專案和 Microsoft CrystalNet 網路模擬驗證專案，筆者期待能通過本文起到拋磚引玉的作用，共同探討與學習。

Cisco Crosswork Change Automation

當前網路運維處在一個拐點的位置上，從網路方面的投資來看，Capex（建網成本）和 Opex（運維成本），隨著網路規模越來越大，網路建網成本會變得越來越低，但是運維成本會越來越高。這是一個很顯著的一個特點。在今天的網路，部署一個新的結點，或者是開通一個新的功能，可能都是以天為單位的。比如在一個大型運營商裏面，要開通一個跨省的線路，都是以月為單位。思科把IT部門的工作分爲了兩大類，如下圖所示：

我們可以看到65%的變更都屬於常規標準的變更。思科借鑑了許多工具，最終將標準化、流程化的日常網路運維工作變成一個自動化工具。思科可程式設計網路架構如下圖所示：

• 從裝置API架構來看思科提供了傳統的CLI以及NETCONF、RESTCONF等協議介面。所支援的編碼格式有：XML、JSON、YAML等。值得注意的是雖然現在大部分的廠商裝置支援netconf協議了，但是在實際網路中，並不是所有的型號都支援netconf的全部功能。

• 從Data model資料模型來看，支援的資料有兩大類Configuration（下發的配置命令）和Operation（裝置的執行狀態）。open model和native model分別是標準模型（例如openconfig）和廠商私有的模型。

• 思科支援使用第三方自動化工具進行部署，例如Ansible、puppet、chef。

在簡單的瞭解思科可程式設計網路架構後，接下來介紹一下思科最近釋出的網路自動化平臺Cisco Crosswork Network Automation。這裏只簡單的介紹其中的一部分—Cisco Crosswork Change Automation，主要使用Ansible作為基礎框架進行對網路裝置管理及部署，流程圖如下。

Cisco Crosswork Change Automation (CCCA) 不同與其他基於指令碼的自動化工具. CCCA 是一個能夠實現閉環的框架，主要由兩部分組成:

• 配置變更管理：對外提供REST APIs，從倉庫中獲取Ansible 劇本（playbook）對其進行編排和初始化。使用裝置可程式設計介面，可提供翻譯成裝置配置的能力。執行流程如下，預檢查（pre-check）-> 執行（execute）-> 驗證（Verify）-> 如果驗證成功則進行Post-Check否則回退Rollback。

• 警告/驗證引擎：監聽訊息通知埠，使用實時遙測（Telemetry）進行收集資料去驗證配置意圖，同時對裝置狀態進行監控報警。在傳統的網路中，往往只是進行簡單地監控（monitor），有許多不足的地方。網路監控廣度和深度不足，所描述的資訊和資料都是直接來自於底層裝置的（low-level），而非使用者期望的以規範化資料模型方式來表達。這對管理員的技能要求高，可用性保障困難。因為故障來源複雜（配置錯誤，軟體故障，鏈路故障等），裝置之間聯絡緊密, 並且存在故障擴散現象，整個系統缺乏有深度的全域性網路資料檢視。所以基於Telemetry這一網路遙測、實時監控的特性，能夠全面地實時瞭解網路狀態。Telemetry遙測的功能不僅僅能夠獲得數據流實時資訊，而且能夠獲得實時的網路配置、流量統計、計數、報錯、表項、環境、快取等一些列資訊。近期Google等雲巨頭推動 OpenConfig 的一個重要原因就是希望能夠以單一標準化資料模型語言（YANG） 來定義資料和實時狀態反饋（state streaming），其實就是資料定義加上 Telemetry 的特性。通過驗證verification最後閉環這一步驟將low-level的裝置資料與high-level的意圖關聯起來。網路的狀態時時變化，執行時的狀態與驗證時的狀態可能存在不一致，此時平臺會主動地根據期望的狀態對策略進行優化補救。

Alibaba NetCraft

作者Hongqiang Harry Liu目前就職於阿里，他所在的團隊最近發表了一篇論文Automatic Life Cycle Management of Network Configurations，使我受益匪淺，所以在這簡單介紹下這篇論文。該作者在網路可程式設計和驗證領域發表過多篇論文，包括本文下一章介紹微軟的網路模擬器，有興趣的可以去他主頁下載論文。

NetCraft是什麼？它是基於網路資料模型對配置進行抽象，用於管理網路配置完整生命週期的一個自動化工具。它的初始版本已經商用，用於管理阿里的全球廣域網。隨著業務需求越來越多，現在網路的規模不斷變大，網路變更也越來越頻繁，尤其是在廣域網。論文中對2016和2017年阿里發生的網路故障進行了分類總結，如下圖所示：

配置導致的事故佔65%，其中包括在變更中導致的佔56%，網路配置bug佔10%。很明顯，配置變更佔了總事故率的一大半。主要的原因有以下三點：

• 配置層面（low-level）更新是由high-level的意圖所推導出來的，這一過程容易出錯。

• 配置更新涉及到許多裝置和協議，因此需要一個平滑的增量式的變更方案，這裏涉及到編排，例如對裝置進行配置變更的先後順序，使得變更不影響到當前網路。

• 在變更中需要對發生的故障進行快速反應，發現問題後能夠立馬對裝置進行平滑的回退。

未來最理想的管理網路方式是網路工程師只需要參與設計和更新網路意圖，其餘的一些底層的事情例如配置生成、增量式的配置更新、平滑的變更操作以及配置診斷及回退，能夠用自動化軟體去完成管理整個配置的生命週期。NetCraft就是為此設計，設計框架如下：

• 網路運維工程師建立一個目標網路模型，可以是描述整個網路的或者是隻對一部分網路，把生成的模型輸入到NetCraft。配置生成器（Configuration Generator）對目標模型進行解析，在這個過程中會結合對應的模板（modular template）生成目標配置。

• 與此同時，如果運維人員是對網路進行變更，那麼變更計劃（Transition Planner）會計算所有網路配置模組的相互依賴圖（dependency graph）。每個配置模組都是簡單和基礎的原子化操作（接下來會具體講）。這樣可以保證增量的網路變更能夠順利平滑的進行。

• 目標配置（Target Configuration）和變更計劃（Transition Planner）最終會放入到配置執行器裏面（Configuration Executer），按照計劃對這些配置模組一步一步的進行下發，同時會檢查網路的狀態，如果執行失敗或者網路出現異常，那麼將裏面進行回退操作。

• 模型生成器（Model Generator）會當前網路配置進行抽象轉譯成網路模型，可用於診斷故障、配置關鍵屬性比較等等。這一過程與開源的Batfish控制面結構有些相似，能夠將各個廠商的配置進行解析最終生成統一的網路模型。

• 上圖灰色所表示的四個模組大該用了10W行程式碼（Java）。

下圖左邊表示的cisco的配置模板，右邊是根據模板生成的對應的網路配置。這一步驟與上篇文章中所講到的Facebook Robotron和一些開源自動化部署工具方式類似，都是基於配置模板生成配置。因為不同裝置廠商的配置命令語法不同，所以配置模板也一定不一樣。可以使用Jinja或者其他語法去寫模板，這取決於配置生成器的能力。

對於網路變更來說，輸入一個最新的網路模型到NetCraft，系統會對當前執行的網路模型與輸入的進行比較，計算每一層的不同。例如有沒有節點或者鏈路被增加或刪除了，有沒有對結點或者鏈路的屬性進行了修改等等。這時候Transition Planner需要準備好對應的配置模板。沒有檢查及回退的操作是極其不安全的。所以針對一些網路操作的配置模板，有以下四種shadow modules：Deactivate、Activate、Undo、Check。下圖是BGP Peering配置模板的例子。

目前NetCraft使用了以下幾種策略實現平滑安全的增量變更方案。

• 目前執行配置模板是序列操作，不支援並行。所以同一時間裏，只能執行一個配置模板。

• 執行配置模板時，會先檢查網路狀態，只有當上一個模板成功執行時，纔會執行下一個模板。

• 變更時當網路發生異常時，NetCraft會馬上使用Undo shadow module進行回退。

完成每次更新有以下四個步驟，以下面的圖為例：

1. 執行所有相關的Deactivate模組。

2. 執行自定義模板（在這個例子裡是Prepending ASN in AS Path）。目前沒有方法找到自動去通過網路模型去推算出這種模板，但是一些常見的用例，例如BGP Peering 更新，這些操作是可以自動化的。對於複雜的變更場景，需要寫個狀態機去指引。

3. 執行所有相關的Activate模組。

4. 執行第二步裡自定義模板的Undo模組，刪除一些舊的配置（例如把link斷掉了）。

上述的每個步驟，配置模組都是從網路模型低層到高層依次執行。這是因為每一層使用下一層提供的服務，並且要向其上層提供服務。可能大家會想為什麼一定要成這麼複雜，可不可以在對裝置進行下發配置之前，先做一個配置快照儲存起來，然後把所更新的配置下發到裝置上。如果失敗了，直接用類似於熱重啟的方式回退到之前的配置。就像Napalm提供的rollback函式，例如思科用rollback running-config file的命令進行回退。這種操作在實際生產環境中，可能會造成短暫的中斷甚至是熱重啟失敗。尤其是對於有著大量配置並且扮演著十分重要的角色的裝置（例如核心路由），一定要保證裝置可以平滑的進行增量式的變更和回退操作。

Microsoft CrystalNet

網路可靠性對於雲服務廠商十分重要。當雲網絡規模變大後，運維變得困難。因為歷史的原因，網路中本來就可能存在許多不確定的bug在裏面，例如當下次變更時觸發了之前網路存在的bug，又或者裝置主備切換後纔會觸發到的bug。由於雲業務不斷的擴充套件，要求開發的速度不斷提升，但是沒有一個可靠的測試和驗證工具。這導致降低了軟體交付和使用者業務變更的速度。那麼如何做到網路驗證呢？微軟在網路驗證這個新興的細分領域，發表了一些學術研究成果的文章，有興趣的可以去Microsoft Network Verification網站檢視。明確地說，網路驗證可以細分成以下三個領域：

• 控制面驗證：網路中路由表是通過路由協議生成的，例如BGP、OSPF等。在上到生成環境前，我們需要對網路控制面層進行驗證。

• 資料面驗證：因為網路中轉發資料包是根據資料面的行為，所以驗證工具需要在部署前和部署之後對網路進行驗證，例如檢查可達性、黑洞路由等等。

• 模擬：通過模擬，網路工程師能夠找到韌體和模型中的bug，可以在上生產環境之前對它們進行測試和檢查。前些天InfoQ寫了篇文章介紹微軟將開源其對抗雲網絡中斷的祕密武器，微軟設計了一款開放網路模擬器（Open Network Emulator，簡稱ONE），可以通過模擬整個Azure網路基礎架構，來查詢最終導致網路中斷的錯誤，故障和其他惡意軟體。在當時，它被稱為「CrystalNet」，現在微軟準備把它開源出來。有興趣想了解細節的朋友可以讀一下CrystalNet: Faithfully Emulating Large Production Networks，第一作者是Hongqiang Harry Liu。下面擷取文章中一部分對比網路模擬與控制面、資料面驗證這兩種思路方式。

網路驗證工具例如batfish，輸入裝置配置和網路拓撲資訊，通過模擬路由協議計算轉發表。分析這些轉發表的行為可以回答例如可達性這類問題。然而，Batfish不能夠找到裝置韌體中存在的bug，另外不同廠商對同一個路由協議行為可能有微妙的差別。在微軟有將近36%的問題是由軟體bug所導致，如下表所示，展示了近兩年網路事故的根因。

從表中可以看出，網路驗證工具並不能解決和發現軟體bug（36%）和人為下發時導致的錯誤（6%），而通過模擬整個網路可以解決下面的問題。

• 軟體bug：這個分類主要包括裝置韌體中的bug、網路管理工具中的bug。就算是同一個廠商同型號的裝置，針對於不同版本的韌體，配置語法以及支援的功能可能會存在細微的差別。舉個例子，對防火牆設定vpn祕鑰時，因為防火牆的系統版本不一樣，可能所支援的祕鑰符號不同。只有通過模擬裝置韌體，才能發現此類的問題。

• 配置bug：網元裝置的配置不僅僅是定義一些路由協議（關於控制面的這些行為)，還包括了例如轉發表容量、裝置cpu、acl等等。把這些全部加起來，纔是一個完整的配置。網路事故中有27%是因為配置錯誤所導致的，例如缺失或者錯誤的ACL策略、重複分配了同一個IP、錯誤的AS號等等。

• 人為導致的錯誤： 主要是一些手動操作失誤所導致的. 例如通過CLI或者某個部署工具，把deny 10.0.0.0/20寫成了deny 10.0.0.0/2。這些人為錯誤佔了網路事故的6%。我們通過對一些有經驗的網路工程師對話中得知，造成這個問題的主要原因是操作人員沒有一個與生存環境同等的測試環境去練習和操作。CrystalNet可以通過模擬提供這樣的環境。

爲了準確地模擬出控制面，CrystalNet執行在容器和虛擬機器，底層使用的是真實的網路裝置韌體。如果能模擬出大規模網路，那麼效能究竟如何？不同廠商裝置相容性如何？需要消耗的主機資源有多少？根據文章中的描述，模擬5000臺的裝置，需要500個VM（4 core, 8GB RAM）。想要通過實踐回答上面的問題，可能要等到微軟開源這個專案後才能知道了。

Conclusion

• 網路模型（network model）是核心競爭力。 我們可以發現無論是Robotron、NetCraft這類網路可程式設計的專案和Batfish這類網路驗證的專案，都需要基於網路模型。構建網路模型需要一個過程去不斷的完善。

• 版本控制（version control）也很重要。 網路拓撲、路由、裝置的版本以及配置會隨著時間的推移，會進行不斷的變更。這要求做到可以對整個網路進行版本管理，例如比對配置不同版本的差異，能夠回退到指定的版本等等。

目前開源的這些專案主要專注於特定的領域。例如Ansible專注於實現網路自動化部署和任務編排；Propane專注於從意圖生成裝置配置這個流程；Batfish專注於網路配置驗證，找出網路中的bug；Napalm專注於實現對網路管理層操作的抽象，遮蔽多廠商差異提供一個統一的API介面。

公司需要思考如何利用好目前開源工具，減少一些重複的工作，構建真正有核心力的產品。想真正實現網路可程式設計，需要把整個流程打通實現閉環，這會涉及到多個部門的合作。當前各大雲廠商都在投入網路可程式設計，試圖打通端到端的網路自動化，進而提高了部署效率、節約了人力成本，還可以有效地避免配置錯誤。相反傳統IT廠商無法在運維成本上和雲廠商抗衡，所以未來越來越多的IT廠商會把大部分的業務放到雲上。從Gartner公佈的雲市場整體情況，能夠看到一個趨勢非常明顯。全球整個IT市場發生了很大的變化，傳統IT幾乎沒有增長，但是雲服務增長40%左右。雲做的業務增長明顯比傳統IT增長要快。對於伺服器廠商來說，如果全球伺服器的出貨量幾乎不變，那麼實際整個收入是下降的。未來伺服器會不會只能賣給幾個大的雲供應商了。另外最近出了幾個傳聞亞馬遜、微軟要決定自己做伺服器了，當天思科等廠商股票立馬跌了不少。從歷史的發展來看，巨頭公司往往不是被同行幹掉的，而是被新的技術所革命。

作為技術從業者，如果能夠處在朝陽行業並且看到自己寫的程式碼有一個實踐和落地的舞臺，可以說是一件幸運的事情。前段時間，我按照開源專案Napalm的接口規範，新增了對華為CE系列的交換機的支援。大家可以去napalm-ce網站中檢視和使用，如果在使用中遇到問題可以提交issue或者Pull Requests。

Reference

• Verification and Intent-Based Networking: Closing the Control Loop

• Facebook Robotron 演講、FBNet Command Runner FCR

• Cisco Crosswork Network Automation、Cisco Crosswork Change Automation

• Automatic Life Cycle Management of Network Configurations

• CrystalNet: Faithfully Emulating Large Production Networks

• Microsoft Network Verification

• 微軟將開源其對抗雲網絡中斷的祕密武器

• Huawei napalm-ce

【投稿】

歡迎SDN、NFV、邊緣計算、SD-WAN、5G 網路切片等網路方向的觀點類、新聞類、技術類稿件。

投稿郵箱：[email protected]

諮詢：2427151142 暱稱 白白

詳情請參考：SDNLAB原創文章獎勵計劃

爲了給各位小哥哥，小姐姐們帶來更好的閱讀感受，現在發起SDNLAB文章選題徵集，如果大家對什麼話題感興趣，可以文末踊躍發言。期待各位的參與！