首先，讓我們假想一個場景：
由于業務發生變更，需要為一個 POD 里面的幾十臺交換機修改 QoS 配置。作為網絡運維人員，應該怎樣處理這項工作呢？
如果需要變更的對象是整個數據中心幾百臺甚至幾千臺交換機，又該怎樣處理這項工作呢？
當下，互聯網行業已經普遍采用 DevOps 的體系流程�？咳肆θヒ慌_設備一臺設備的更改配置，已經不再是正確的思維方式。原因不僅僅是浪費時間 —— 要知道，人如果要長時間保持注意力集中，大腦需要耗費大量的能量，很難保證不出現遺漏或者錯誤。而機器卻不會。
因此，正確的方法是利用 DevOps 的流程，讓機器來完成這項工作。例如采用基于 Python 的 SSH 庫 Paramiko 或 Netmiko，以及 Ansible 或 SaltStack 等自動化工具編寫運維腳本。
Netmiko 庫和 Ansible 等運維工具雖然可以通過程序化的腳本對網絡設備實現批量管理，但仍然需要運維工程師對網絡設備的 CLI 很熟悉，預先在腳本中建立需要被執行的 Command 列表。
CLI
CLI 最大的問題就是在不同廠商的設備之間，甚至在不同版本之間存在較大差異。比如在某 C 廠商交換機上配置邊緣端口，不同的 OS 版本命令并不相同：而對于另一些廠商，配置命令則差異更大。例如在某 E 品牌 交換機上配置邊緣端口的命令為：這意味著：如果設備版本升級，就可能需要更改運維腳本的代碼。為了避免廠商綁定，網絡內通常也會同時存在多個廠商的設備，相應地，也可能需要準備多種運維腳本或者讓運維腳本變得很復雜 —— 先判斷設備型號和版本號，再運行相應的 Command-list。
所以 CLI 并不適合用來作為一種 API。雖然采用自動化工具處理 Commands 可以節省網絡運維人員的工作量，但是技術門檻和維護成本都比較高。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 查詢或修改若干 Key 所對應的 Value，就可以實現信息采集或者網絡設備的配置修改。
上圖是一個 MIB 示例，請注意標黃色的部分。OID 1.3.6.1.2.1.2.2.1.5 用來以 bps 為單位評估接口流量，它屬于 RFC 1213 標準 MIB，名稱為 ifSpeed，只讀。因為這個 MIB 并不是我從正在運行的設備上取下來的，所以當前的 Value 為空。
需要注意的是，SNMP Manager 側的 MIB 并不是必需的。如果使用數字 OID 1.3.6.1.2.1.2.2.1.5，SNMP Manager 可以直接從 SNMP Agent get 接口流量帶寬，而不需要安裝完整的 MIB。
現在 SNMP 在網絡監控領域已經被廣泛使用，利用 Zabbix、Nagios、Cacti 等開源的 SNMP 管理工具采集網絡設備接口流量帶寬和其他設備信息，同時也有大量的基于 Python 的 SNMP 庫用來實現運維開發，例如 PySNMP、 EasySNMP、 Net-SNMP等等，并且它們都可以集成到 Ansible 和 SaltStack 等自動化運維工具上。
看上去還不錯，但實際上 SNMP 仍然不是一個合適的 API，因為它存在幾個問題：
○太古老，并發性能不好
○基于 UDP 協議傳輸，比較不可靠。雖然在應用層有 Response 機制保證丟包之后的重復 get/ set，但代價就是性能和運行時間都受到影響
○最致命的問題是，各廠商都大量的使用私有 MIB，卻不存在一個可以自動發現網絡設備當前所采用的 MIB 的機制。網絡運維人員必須分別向設備廠商索取網絡設備的 MIB，耗費大量的時間整理自己需要的 OID，再手工導入到自動化運維平臺或者腳本當中
所以 SNMP 仍然只適合用來做信息采集，提供告警和可視化報表，但自動化運維的 API 則需要考慮其他的選項。站在網絡運維人員的角度，這個 API 應該滿足以下要求：
○容易使用 —— Usability 是所有產品的核心價值
○需要能夠清晰地區分“配置數據”，“設備運行狀態數據”和“統計數據”
○需要能夠分別從各個網絡設備獲取上述 3 種數據，并且可以方便地對比不同設備的數據
○可以讓網絡運維人員統一地管理整個網絡的所有設備，而不是一臺一臺的單獨管理
○對不同廠商的設備都能夠使用同一種配置方法
○配置變更對網絡業務的影響要盡可能的小
○能夠提供一個標準化的，對設備 Pulling 和 Pushing 配置文件的流程，以滿足對設備配置的備份和恢復的業務需求
○能夠很方便地，持續地，檢查設備配置文件的一致性
○能夠提供基于文本的配置方式，并且不會導致配置的亂序，例如不能攪亂 ACL 規則的順序
能夠滿足這些要求的網絡設備的北向 API 接口就是 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。
雖然網絡運維人員不再需要關注設備的相關命令了，但仍然無法直接使用 Netconf 配置設備，還需要考慮配置結構。
什么叫“配置結構”呢？
假如我們現在要將交換機的 10# 端口劃入 VLAN 20。從上面兩個配置示例可以發現銳捷交換機和 H 品牌交換機的配置結構有明顯差異，所以無法直接使用 XML 或者 JSON 修改它們的設備配置。
為了解決配置結構的問題，需要將 XML 和 JSON 數據格式抽象成一個統一的標準的模型，這就是 YANG。YANG 的全稱是 Yet Another Next Generation，沒有恰當的中文來翻譯它。通俗的講，YANG 是表達 Netconf 所操作的配置數據和狀態數據的模板，它描述什么才是符合設備期望的數據。有了 YANG Model，配置結構就交給它去處理，網絡運維人員就只需要做一個完形填空即可。
這個過程在邏輯上，與向 SNMP 的 OID 填充/讀取 Value 差不多。
Netconf 和 YANG Model 的出現，為網絡自動化帶來了極大的便利。配合自動化的程序，可以實現動態向網絡設備下發配置，將數據面和控制面分離，組成軟件定義的網絡。事實上，Netconf 也是 OpenDayLight 等開源 SDN Controller 所廣泛使用的南向接口之一。 此外，Ansible 也集成了 Netconf 的 Module，并且可以通過 Python 來擴展 ncclient 和 nxpy 等庫，實現功能擴展。
但 Netconf 就是我們在尋找的理想的 API 嗎？
站在網絡運維者的角度，答案卻是否定的。
原因在于很多廠商雖然支持 Netconf，但有一些 Key-Value 卻存在差異。比如為了表達“端口”，有些廠商用 intf 作為 Key，但另外一些廠商卻用 interface 作為 Key。另一個例子就是 Uptime，設備運行時間，各家廠商的設備返回的時間格式更是五花八門。這為網絡運維人員處理數據的工作造成了很大的麻煩，不得不耗費大量的時間和精力去閱讀設備廠商的 Netconf 文檔，去編寫大量的正則表達式。
還有，雖然主流的 SDN Controller 的南向接口都支持 Netconf，但是在實際部署時，卻無法用單一的 Controller 去控制多廠商的網絡設備。通常都是各個廠商使用自己的 SDN Controller 控制自己的設備，然后再用 REST API 與用戶的 SDN Controller 對接。
上文所提到的網絡運維人員所關心的 9 大問題，Netconf 幾乎都能滿足，但距離完全滿足還有一些差距。
有一個解決辦法，就是利用 NAPALM。
NAPALM
NAPALM 是一個 Python 庫，它的全稱是 Network Automation and Programmability Abstraction Layer with Multivendor support，多廠商支持的網絡自動化和可編程抽象層。
目前 Ansible 集成了 3 個 NAPALM 模塊，分別是：
○napalm_parse_yang：用于從設備或文件中解析配置/狀態數據
○napalm_diff_yang：用于比較 2 個 YANG 對象的差異
○napalm_translate_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。
IETF 已經為 Netconf 和 YANG Model 發布了很多 RFC，從 2006 年的 Netconf RFC 4741，2010 年的 YANG Model RFC 6020，到現在已經超過 10 年。而最新的一個 RFC 在什么時候呢？就在幾天之前的 2018 年 4 月 3 日，3 家設備廠商聯合提交了一個 OSPF YANG Model 的草案 —— 標準化的進展太慢了。
也許，這就是問題所在 —— Netconf 標準是由網絡設備廠商推動的，內耗太大。各個設備廠商都希望在軟件定義網絡的時代繼續保持硬件設備的重要性，并且能夠體現自己公司產品的差異化優勢。
但是從網絡運維者的角度考慮，這顯然不合理，因為設備廠商所推動的 Netconf 標準并不是他們真正想要的。所以 Google，AT&T，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 個 YANG 標準草案，雖然目前還沒有標準的 RFC 發布，但是它現已成為網絡自動化技術的發展趨勢，因此各大網絡設備廠商都開始了 OpenConfig 的開發工作。銳捷的數據中心交換機支持 Netconf YANG 和 OpenConfig YANG，目前正在國內配合公有云提供商進行標準化 SDN 的測試工作。
