應該選用哪種 API 來實現網路自動化？

首先，讓我們假想一個場景：

由於業務發生變更，需要為一個 POD 裡面的幾十台交換機修改 QoS 配置。作為網路運維人員，應該怎樣處理這項工作呢？

如果需要變更的對象是整個數據中心幾百台甚至幾千台交換機，又該怎樣處理這項工作呢？

當下，互聯網行業已經普遍採用 DevOps 的體系流程。靠人力去一台設備一台設備的更改配置，已經不再是正確的思維方式。原因不僅僅是浪費時間 —— 要知道，人如果要長時間保持注意力集中，大腦需要耗費大量的能量，很難保證不出現遺漏或者錯誤。而機器卻不會。

因此，正確的方法是利用 DevOps 的流程，讓機器來完成這項工作。例如採用基於 Python 的 SSH 庫 或 ，以及 Ansible 或 SaltStack 等自動化工具編寫運維腳本。

Netmiko 庫和 Ansible 等運維工具雖然可以通過程序化的腳本對網路設備實現批量管理，但仍然需要運維工程師對網路設備的CLI很熟悉，預先在腳本中建立需要被執行的 Command 列表。

CLI

CLI 最大的問題就是在不同廠商的設備之間，甚至在不同版本之間存在較大差異。比如在思科的 3750 交換機上配置邊緣埠，不同的 OS 版本命令並不相同：

(如果您正在使用手機瀏覽，請左右滑動代碼塊)

而對於另一些廠商，配置命令則差異更大。例如在 Extreme 交換機上配置邊緣埠的命令為：

這意味著：如果設備版本升級，就可能需要更改運維腳本的代碼。為了避免廠商綁定，網路內通常也會同時存在多個廠商的設備，相應地，也可能需要準備多種運維腳本或者讓運維腳本變得很複雜 —— 先判斷設備型號和版本號，再運行相應的 Command-list。

所以 CLI 並不適合用來作為一種 API。雖然採用自動化工具處理 Commands 可以節省網路運維人員的工作量，但是技術門檻和維護成本都比較高。SNMP似乎是一種更好的選擇。

SNMP

SNMP 的歷史很悠久，第 1 個與之相關的 RFC 1065 發佈於 1988 年，距今已有 30 年。在 SNMP 架構中，一個網路設備以守護進程的方式運行 SNMP Agent，而 NMS（網路管理系統）和網路運維人員所使用的各種 SNMP 管理工具則稱為 SNMP Manager。SNMP Agent 能夠響應來自 SNMP Manager 的各種請求信息。

SNMP Agent 會維護一個 MIB（管理信息庫），裡面保存著大量的 OID （對象標識符）。一個 OID 是一對唯一的 Key-Value，SNMP Manager 向 SNMP Agent 查詢或修改若干 所對應的 ，就可以實現信息採集或者網路設備的配置修改。

上圖是一個 MIB 示例，請注意標黃色的部分。OID 用來以 為單位評估介面流量，它屬於 RFC 1213 標準 MIB，名稱為 ，只讀。因為這個 MIB 並不是我從正在運行的設備上取下來的，所以當前的 Value 為空。

需要注意的是，SNMP Manager 側的 MIB 並不是必需的。如果使用數字 OID ，SNMP Manager 可以直接從 SNMP Agent 介面流量帶寬，而不需要安裝完整的 MIB。

現在 SNMP 在網路監控領域已經被廣泛使用，利用 Zabbix、Nagios、Cacti 等開源的 SNMP 管理工具採集網路設備介面流量帶寬和其他設備信息，同時也有大量的基於 Python 的 SNMP 庫用來實現運維開發，例如 、 、 等等，並且它們都可以集成到 Ansible 和 SaltStack 等自動化運維工具上。

看上去還不錯，但實際上 SNMP 仍然不是一個合適的 API，因為它存在幾個問題：

太古老，並發性能不好

基於 UDP 協議傳輸，比較不可靠。雖然在應用層有 Response 機制保證丟包之後的重複 / ，但代價就是性能和運行時間都受到影響

最致命的問題是，各廠商都大量的使用私有 MIB，卻不存在一個可以自動發現網路設備當前所採用的 MIB 的機制。網路運維人員必須分別向設備廠商索取網路設備的 MIB，耗費大量的時間整理自己需要的 OID，再手工導入到自動化運維平台或者腳本當中

所以 SNMP 仍然只適合用來做信息採集，提供告警和可視化報表，但自動化運維的 API 則需要考慮其他的選項。站在網路運維人員的角度，這個 API 應該滿足以下要求：

容易使用 —— Usability 是所有產品的核心價值

需要能夠清晰地區分「配置數據」，「設備運行狀態數據」和「統計數據」

需要能夠分別從各個網路設備獲取上述 3 種數據，並且可以方便地對比不同設備的數據

可以讓網路運維人員統一的管理整個網路的所有設備，而不是一台一台的單獨管理

對不同廠商的設備都能夠使用同一種配置方法

配置變更對網路業務的影響要儘可能的小

能夠提供一個標準化的，對設備 Pulling 和 Pushing 配置文件的流程，以滿足對設備配置的備份和恢復的業務需求

能夠很方便地，持續地，檢查設備配置文件的一致性

能夠提供基於文本的配置方式，並且不會導致配置的亂序，例如不能攪亂 ACL 規則的順序

能夠滿足這些要求的網路設備的北向 API 介面就是Netconf。

Netconf

Netconf 是 IETF 發布的標準協議，它的全稱是Network Configuration Protocal。從名字就可以看出來，Netconf 的作用是基於網路來安裝、操作和刪除設備的配置。在 Netconf 的架構中，網路設備充當 Netconf Server 的角色，而運維人員的這一側則是 Netconf Client。此外，和 OSI 標準模型一樣，Netconf 也是分層結構。

它有 4 個層次，從下到上依次為：

安全傳輸層

安全傳輸層在 Netconf Client 和 Netconf Server 之間提供安全的端到端連接。與 SNMP 採用非面向連接的 UDP 協議不同，Netconf 採用面向連接的 TCP 協議，通常是 SSH 協議，保證連接的可靠性和安全性。

消息層

消息層也稱為 RPC（遠程過程調用）層。Netconf Server（網路設備）上面部署了 Netconf 應用，Netconf Client 需要調用 Server 上的應用所提供的函數/方法，但由於 Client 和 Server 不在同一個內存空間，無法直接調用，所以需要通過網路來表達調用的語義，並傳達調用的數據。這個過程，稱為 RPC。它提供了一個簡單的，與安全傳輸層無關的機制來封裝操作層和內容層的數據：

RPC 調用： 元素所封裝的消息

RPC 結果： 元素所封裝的消息

事件通知： 元素所封裝的消息

操作層

操作層定義了如圖所示的 9 種基礎操作集，其中：

、 用來對設備進行取值操作

、 、 用於配置設備參數

和 是在對設備進行操作時，為防止並發產生混亂的鎖行為

和 用於結束一個會話操作

內容層

顧名思義，內容層就是用來表達配置數據和狀態數據，網路運維人員只需要關注數據本身，而不需要去關注設備的相關命令。基礎網路設備在內容層所採用的數據格式通常是 XML，但也有廠商的數據格式採用了 JSON。例如 Arista 的數據格式是 JSON，而 Cisco 則同時支持 XML 和 JSON。

雖然網路運維人員不再需要關注設備的相關命令了，但仍然無法直接使用 Netconf 配置設備，還需要考慮配置結構。

什麼叫「配置結構」呢？

假如我們現在要將交換機的 10# 埠劃入 VLAN 20。銳捷交換機需要在物理埠模式下配置：

而 HP Procurve 交換機卻需要在 VLAN邏輯埠模式下配置：

從上面兩個配置示例可以發現銳捷交換機和 Procurve 交換機的配置結構有明顯差異，所以無法直接使用 XML 或者 JSON 修改它們的設備配置。

為了解決配置結構的問題，需要將 XML 和 JSON 數據格式抽象成一個統一的標準的模型，這就是 。YANG 的全稱是 Yet Another Next Generation，沒有恰當的中文來翻譯它。通俗的講，YANG 是表達 Netconf 所操作的配置數據和狀態數據的模板，它描述什麼才是符合設備期望的數據。有了 YANG Model，配置結構就交給它去處理，網路運維人員就只需要做一個完形填空即可。

填空的題目大概是這樣子的：

填空題的答案大概是這樣子的：

這個過程在邏輯上，與向 SNMP 的 OID 填充/讀取 Value 差不多。

Netconf 和 YANG Model 的出現，為網路自動化帶來了極大的便利。配合自動化的程序，可以實現動態向網路設備下發配置，將數據面和控制面分離，組成軟體定義的網路。事實上，Netconf 也是 OpenDayLight 等開源 SDN Controller 所廣泛使用的南向介面之一。 此外，Ansible 也集成了 Netconf 的 Module，並且可以通過 Python 來擴展 和 等庫，實現功能擴展。

但 Netconf 就是我們在尋找的理想的 API 嗎？

站在網路運維者的角度，答案卻是否定的。

原因在於很多廠商雖然支持 Netconf，但有一些 Key-Value 卻存在差異。比如為了表達「埠」，有些廠商用 作為 Key，但另外一些廠商卻用 作為 Key。另一個例子就是 Uptime，設備運行時間，各家廠商的設備返回的時間格式更是五花八門。這為網路運維人員處理數據的工作造成了很大的麻煩，不得不耗費大量的時間和精力去閱讀設備廠商的 Netconf 文檔，去編寫大量的正則表達式。

還有，雖然主流的 SDN Controller 的南向介面都支持 Netconf，但是在實際部署時，卻無法用單一的 Controller 去控制多廠商的網路設備。通常都是各個廠商使用自己的 SDN Controller 控制自己的設備，然後再用 REST API 與用戶的 SDN Controller 對接。

上文所提到的網路運維人員所關心的 9 大問題，Netconf幾乎都能滿足，但距離完全滿足還有一些差距。

有一個解決辦法，就是利用 。

NAPALM

NAPALM 是一個 Python 庫，它的全稱是NetworkAutomation andProgrammabilityAbstractionLayer withMultivendor support，多廠商支持的網路自動化和可編程抽象層。

目前 Ansible 集成了 3 個 NAPALM 模塊，分別是：

：用於從設備或文件中解析配置/狀態數據

：用於比較 2 個 YANG 對象的差異

：用於將 YANG 對象轉譯成設備原始的配置

從設備取出原始配置數據/狀態數據之後，可以使用 NAPALM 將其翻譯成標準格式的 NAPALM 數據。反之，也可以將標準格式的 NAPALM 數據翻譯成設備原始配置數據，並 Push 到網路設備裡面，以修改設備的配置文件。

讀到這裡，也許您已經猜到我將要說什麼了……

是的，NAPALM 還是不能徹底解決網路自動化所面臨的問題。

因為各廠商 Netconf 的數據表達存在很多差異，所以 NAPALM 必須要依賴第三方的 Module 來完成原始數據的解析和翻譯。如果要解析廠商 A 的某個 OS 系統的配置，就需要一個OSA_Module；如果要解析廠商 B 的某個 OS 系統的配置，則需要OSB_Module。所以目前 NAPALM 支持的 OS 類型還比較少，僅限於某幾個國外品牌廠商的 OS 系統。

即使是這幾個國外品牌廠商，NAPALM 目前也無法實現完整的功能集。所以 Google 等網路設備的大用戶一直在致力於推廣一個能夠替代 Netconf 的標準化介面：OpenConfig。

OpenConfig

IETF 已經為 Netconf 和 YANG Model 發布了很多 RFC，從 2006 年的 Netconf RFC 4741，2010 年的 YANG Model RFC 6020，到現在已經超過 10 年。而最新的一個 RFC 在什麼時候呢？就在幾天之前的 2018 年 4 月 3 日，Huawei、Juniper 和 Cisco 聯合提交了一個 OSPF YANG Model 的草案 —— 標準化的進展太慢了。

也許，這就是問題所在 —— Netconf 標準是由網路設備廠商推動的，內耗太大。各個設備廠商都希望在軟體定義網路的時代繼續保持硬體設備的重要性，並且能夠體現自己公司產品的差異化優勢。

但是從網路運維者的角度考慮，這顯然不合理，因為設備廠商所推動的 Netconf 標準並不是他們真正想要的。所以 Google，ATT，British Telecom，Facebook，Apple，Microsoft 等互聯網服務提供商成立了 OpenConfig 工作組，希望提供一個中立於設備廠商的標準 API。目前國內的騰訊、百度和阿里等互聯網服務提供商也已經加入了 OpenConfig 工作組。

OpenConfig 沿用了 Netconf 的協議框架，但是它不太關注底層的數據傳輸，而是更關註上層的數據表達和數據建模。這意味著：不管是 A 廠還是 B 廠，所有的數據都必須符合 OpenConfig YANG Model，並且 Key-Value 都必須是 OpenConfig 所規定的標準格式！

OpenConfig 的另外一個核心要點是：雖然網路設備可能支持豐富的功能特性，甚至是設備廠商私有的功能特性，但是OpenConfig 只關心與互聯網行業用戶通用的運維工作和網路設計工作相關的功能，例如 BGP、OpenFlow、Telemetry 等等。OpenConfig 不會為設備廠商的私有特性定義 YANG Model，也不會為設備廠商所特有的 Key-Value 做定義，所以不會出現不兼容的情況。

但反過來講，OpenConfig 也不會為了兼容某些設備廠商而讓 YANG Model 過於簡單，所以設備廠商需要讓自己的功能滿足 OpenConfig YANG Model 的要求，具備 Model 所定義的所有的 Key，並且能夠為所有的 Key 提供對應的 Value。

在 Key-Value 格式固定之後，網路運維人員對數據的解析工作就非常方便了。只要網路設備支持標準的 OpenConfig YANG，NAPALM 就可以對原始數據進行解析，不再依賴第三方 Module 就可以管理多廠商多 OS 的網路，進而實現真正的網路自動化。

使用 OpenConfig 的另一個好處就是可以簡化 SDN 網路架構，用戶使用一個控制器集群就可以同時控制多個廠商的網路設備，不再需要使用設備廠商的商用控制器做中繼。

OpenConfig 工作組在 2015 年已經向 IETF 提交了 2 個標準草案，雖然目前還沒有標準的 RFC 發布，但是各大廠商都已經開始 OpenConfig 的開發工作。銳捷的數據中心交換機支持 Netconf YANG 和 OpenConfig YANG，並且在國內正配合主流雲廠商進行標準化 SDN 的測試。

參考文獻

https://www.slideshare.net/tailfsystems/tailf-why-netconf

http://jedelman.com/home/openconfig-data-models-and-apis

https://www.dravetech.com/presos/i_love_the_smell_of_oc_in_the_morning

https://www.zhihu.com/question/40822826/answer/139443624

https://en.wikipedia.org/wiki/NETCONF

https://github.com/openconfig/public/tree/master/release/models

http://www.ieee802.org/1/files/public/docs2015/new-mholness-yang-8021Q-0515-v04.pdf

https://napalm.readthedocs.io/en/latest/

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！