本文篇幅較長，主要涉及以下內容： * 介紹傳統 CLI 配置網路裝置存在的挑戰，網管協議出現的背景 * SNMP 原理，互動過程，以及 trade-off * NETCONF 架構，互動過程 * RESTCONF 架構，和 NETCONF 的對比 隨著 5G 的大火，SDN, NFV 等概念被頻繁提及。想要更好的理解這些概念，網路協議自然是對必不缺少的一環。 拿 SDN 來說，全稱為 Software Defined Networking - 軟體定義網路。從傳統網路來說，整體採用分散式的架構，控制平面和轉發平面都位於同一臺裝置上。在運維，以及靈活性上都有著不小的挑戰。 而 SDN 的出現，將控制平面和轉發平面解耦，並將所有的裝置統一管理起來，使得網路具有了可程式設計的能力，從面相服務的角度，根據業務需要，實時動態的調整裝置的配置或狀態，大大降低了管理難度。 那麼 NETCONF，RESTCONF 這樣的協議又是起到怎樣的作用呢？ 這就要從 SDN 架構說起，SDN 主要有三個角色，SDN 應用，SDN 控制，網路裝置。  SDN 應用一般會通過 HTTP 的方式，呼叫 SDN 控制器暴露的介面，而 SDN 控制器，會通過 NETCONF，RESTCONF 類似的協議，與裝置進行互動，進行業務的下發。 可見，NETCONF 類似的協議起到和裝置直接互動的作用。 還有最近 DEVOPS 概念的流行，也強調從傳統人工 CLI 配置，過度到自動化的網路配置。而 NETCONF 類似協議，就讓這些自動化操作成為可能，比如現在的 ANSIBLE，Python 的各種類庫。 下面是網管協議的實際用例，可以看到涵蓋的範圍已經非常之廣：  下面就從傳統 CLI 面臨的挑戰開始，來詳細瞭解下這些發揮著重要作用的協議。 ## 傳統命令操作帶來的主要挑戰 採用傳統 CLI 配置方式主要存在著如下的挑戰：  在相容性方面，若是網路工程師的話肯定深有體會。 拿配置靜態路由的配置舉例， Cisco 裝置命令如下： ``` Router(config)#ip route 0.0.0.0 0.0.0.0 10.10.10.1 ``` 而對於華為和華三裝置來說： ``` Router(config)#p route-static 0.0.0.0 0.0.0.0 10.10.10.1 ``` 有時不光是不同廠商之間的命令不同，甚至同一廠商不同型號之間的命令也不相同。 比如思科針對不同的場景就區分了不同的網路軟體系統： * 針對於企業的 IOS * 針對於運營商的 IOS-XR * 針對於資料中心的 NX-OS * 以及面向下一代的 IOS-XE，將資料層面和控制解耦，底層支援 Linux. 而出錯率這方面，更不必說，人工配置遠沒有機器配置的準確以及迅速。 而且目前的網路在規模和需求上也和之前大不一樣，比如在實時性上，作為運營商需要根據業務需求動態調整策略如 EVPN，L3VPN，L2TP。傳統 CLI 手工配置根本無法滿足，而無法做到維護管理。而現在的常用解決方案都是利用一些現成的 SDN Controller 進行實時調整如 Cisco 的 NSO. 在資料採集方面，傳統人工定時登上裝置材料系統日誌，分析情況，這更加無法適用。在故障響應上，資料採集，分析都存在先天的不足。比如收集效率低，資料的利用率延遲或不高。 最後從商業成本的考慮，人工的維護方案也是較高的一筆輸出。 而且對於工程師而言，需要不斷學習不同廠商的配置命令，學習成本很高，但意義不大。 通常來說，網路工程師在開始一個專案前，會進行如下四個部分： 1. 瞭解使用者的需求 2. 針對使用者的需求，確定相應的具體方案。 3. 根據使用者的方案，查詢並學習對應裝置的配置命令 4. 最後申請割接視窗，準備回滾方案並實施。 在這裡的第三步，其實就是一個比較耗時，但沒多少意義的過程。因為在集中學習不同廠商的裝置命令，但從業務考慮明明解決的都是同一個問題。 在發現 CLI 管理裝置的方式出現瓶頸後，並不是馬上過度到現在流行的網路自動化配置方式，而是先推出了一個叫 `Simple Network Management Protocol` - SNMP 的應用層協議，甚至在當前的一些現網中，依然被使用。 ## SNMP SNMP 的出現，主要想解決兩個問題： 1. 裝置資訊的採集 2. 使用 GUI 替代 CLI 的方式進行裝置配置下發 但由於其讀多寫少的特點，現被廣泛用於裝置資訊的監控和採集。 SNMP 目前共有三個版本： * SNMP V1，第一個版本。在管理裝置上，採用明文的方式，有 `read-only`, `read-write`, `trap` 三種和裝置通訊的方式。 * SNMP V2，主要改進了效能，安全性以及裝置交流的方式。 * SNMP V3，主要優化了安全性，增加了一些更強的認證流程。 ### SNMP 原理 SNMP 整體架構上有些類似於 Client / Server，其主要的工作元件主要有三個： * SNMP Manager：，主要用於管理網路中的多個裝置，對其進行讀和寫的操作。類似於 Server. * SNMP Agent：執行在網路裝置上，通常都需要手動開啟。作為 SNMP 代理，在收到 SNMP Manager 發出請求後，對請求的內容進行解析，然後對裝置進行配置，將配置的結果作為 Response 回覆給 Manager. * SNMP MIB: MIB - Management Information Base 全稱為資訊管理庫。可以將其理解成用於互動的一種資料模型，也就是互動的規則。MIB 同樣存在於網路裝置中。定義和描述瞭如何管理裝置上的資源。Manager 和 Agent 之間的交流的資訊就是 MIB 的內容。  可以看到一個 Manager 可以管理網路中的多個裝置。而每臺裝置上執行著 SNMP Agent 用於和 Manger資訊互動，交流的內容需要符合 MIB 的規範。 看到這，可能對 MIB 這個概念還是有些模糊。這樣，我們先不從最後的結果來分析這個元件的作用，而是從設計的角度，來說一下推導下為什麼要有 MIB 這個東西？ 這裡想要實現的是通過 Manager 去管理網路上的 Agent（其實就是管理裝置）。那麼如何管理呢，比如 Manager 想要獲取 Agent1 的 GigabitEthernet0/0/0/1 的 IP 地址。 這時就需要在 Agent1 上先約定好一個內容，比如當 Agent 接收到 `1.1` 這個字串時，就會將介面的資訊返回給 Manager. 之後如果 Manager 傳送 `1.1` 就能獲取到介面的資訊了，但傳送別的內容，Agent 是無法識別並工作的。MIB 本質就是這樣，確定瞭如 `1.1` 這樣的一組規則，去規範資訊互動的訪問方式。 其實，這裡的 `1.1` 就是 MIB 中的一個物件，在 MIB 中還以層級的方式存在著許多這樣的物件，將網路的裝置的資源抽象成形如 `1.1` 物件。通過這些物件，Manger 和 Agent 就可以實現很好的交流了。 真正的 MIB 類似與下圖，而這裡形如 `1.3.6.1.1.1.2` 這樣連線起來的字串稱為 ASN，其實就是對應了裝置上的各種資源，Manager 和 Agent 也通過它們進行交流。  ### SNMP 操作 SNMP Manger 和 SNMP Agent 間的互動主要有三種類型： * SNMP Get * SNMP SET * SNMP Notifications SNMP Get：主要是檢索裝置的資訊，Get 一種有三種類型： * GET - 從 SNMP agent 獲取固定的物件。 * GETNEXT - 檢索當前物件的後一個物件，由於 MIB 本身層級的樹形結構，存在後繼。 * GETBULK - 獲取一組固定的物件。 SNMP SET：主要是修改 MIB 中的物件，進而修改裝置的配置。 SBMP Notifications：是 SNMP 的主要特性，之前的 GET 和 SET 是屬於拉的操作，而 SNMP 正好相反，類似於推的操作，可以由 agent 發起，將一些資訊 push 到 SNMP Manager 上。類似於 Web Socket. 主要用於通知如認證失敗，重啟，斷開連線等事件。 Notifications 主要有兩種形式：Traps 和 Informs. 兩者間的不同主要在於可靠性，agent 在產生 Informs 給 Manager 後，如果傳送失敗，會重新發送。Manager 收到後，需要回復確認給 agent。  而 Traps 不同，無論訊息傳送是否成功，Manager 都不需要回復。  ### SNMP 缺點 雖然 SNMP 的出現，在一定程度上解決了網路裝置的管理問題。但面對現代大規模的網路來說，依然有著很多挑戰： 1. 效能不足，在下發和讀取配置時，採用依次讀取，效率低。 2. 下發不足，支援寫 MIB 的物件相對於讀較少。 3. 不支援事務機制，在配置下發失敗是，無法回滾。 4. 拓展性差，提供給外部的介面較少。 5. 模型相容性差，MIB 庫混亂，無法適配所有廠商，導致定義各種私有 MIB 庫。 面對這些問題，06 年由 IETF 領導並開發出了一個新的協議 - NETCONF，網路管理協議。和 SNMP 不同，NETCONF 基於 RPC 的方式，天生就能很好的支援事務回滾等操作，從而更好地處理複雜網路的各種需求。 ## NETCONF NETCONF 協議提供了一種更簡單的方式來管理（"查詢，配置，修改，刪除"）裝置，就像資料庫操作中的 DML. 同時開放了 API 介面，當想要對裝置進行操作時，直接通過呼叫 API 進行。 對於支援 NETCONF 的裝置來說，至少能開啟一個或多個 session。並且在每個 session 中應用的配置更改，都可以被全域性的 session 監聽到。這就讓一個或多個 Manager(Client) 操作同一個裝置（agent）成為了可能。 相比 SNMP 而言，有著如下的優勢： 1. 基於 RPC，增加了事務支援 2. 優化查詢功能，增加過濾查詢方式 3. 拓展性強，在其協議內部分為 4 層，各層之間相互獨立 4. 更好的將配置和狀態資料解耦，並區分狀態資料（candidate, running, startup） 5. 易使用，結合提供的 API，實現可程式設計性的網路操作 6. 安全性更好，在傳輸層可選用 SSH，TLS 協議等。 NETCONF 採用 C/S 的架構，通過 RPC 在 client 和 server 間交流。client 可以是 Python 指令碼或應用。server 一般指的是網路裝置，在具體實現上有三個元件： 1. NETCONF agent：執行在網路裝置上，用於接收和處理 RPC 請求。還可主動將一些告警事件通知客戶端。 2. NETCONF 客戶端：利用 NETCONF 協議對網路裝置進行管理以及接收 agent 發出的告警通知。 3. datastore：在 NETCONF 中，區分了多個不同型別的 datastore, 這些 datastore 儲存著不同狀態下的裝置資訊。 關於 datastore 可以將其理解成一個可以獲取和儲存資訊的概念。在具體實現上，可以是檔案，資料庫，記憶體等等。 在 NETCONF 中常用到三類 datastore： * startup configuration datastore: 儲存了裝置啟動時，載入的配置資訊。 * candidate configuration datastore: 儲存了想要執行的配置資訊，修改該資料庫時，並不會影響裝置的真實配置。 * running configuration datastore: 儲存了當前裝置上正在生效的配置，修改時會影響真實的裝置。 此外提到 datastore 就必須要提到一種資料模型語言 —— YANG，datestore 中就是以 YANG 的形式來約束配置的資料。 YANG 的出現結合上 NETCONF 和 RESTCONF 這樣的協議，為自動化，可程式設計化的網路提供了強大的支援。YANG 的本質和之前 SNMP 中 MIB ASN 一樣，作用都是以一種方式來約束資料，關於 YANG 之後會寫一篇文章單獨介紹。 ### NETCONF 協議架構  NETCONF 分為 4 層，各層之間專案獨立。 1. 內容層： 這一層包含了以 XML 或 JSON 格式的配置資料，也就是想對裝置進行管理的具體內容。（由 XSD 或者 YANG 約束生成） 2. 操作層： 定義了 Client 和 Server 互動時的一系列操作方法，用於獲取或修改配置資料。  3. 訊息層： 為編碼資料時，提供了一種 RPC 和通知的機制： * RPC invocations( messages) * RPC results( messages) * event notifications( messages) 4. 傳輸層： NETCONF 使用 SSH 或 TLS 協議，保證資料在 Client 和 Server 傳輸的安全性。 ### NETCONF 互動  對於 Manager 和 Agent 來說，Session 建立會經歷如下的過程： 1. Manager 請求 NETCONF 中 SSH 子系統建立連線。 2. Agent 回覆 Hello 訊息，包含本身支援的特性和能力。 3. Manager 告知 Agent 自己所支援的特性和能力。 4. Manager 開始傳送 RPC 操作請求。 5. Agent 回覆 RPC 請求操作結果。 具體看下 NETCONF 中訊息的報文結構，以修改介面配置舉例：  Manager 請求變更介面配置： ```xml

Ethernet0/0 1500 ``` Agent 回覆結果： ```xml ``` 首先可以看到，NETCONF 使用 XML 作為資料傳輸的格式。 第一行的 `` 標籤，表明該請求是 RPC 請求，`message-id` 屬性由 client/manager 確定。Agent 在回覆結果時，會帶上 `message-id`，用於表示該操作的結果。 `urn:ietf:` 屬性表示 XML 中的命令空間。 `base：1.0` 表示當前 NETCONF 的版本。 第二行 `` 指定執行 RPC 操作的內容為修改配置。 之後 ` ` 中包裹的內容就是，想要下發的配置內容，修改 mtu 為 1500. 但這裡還有一個疑問，在說到 NETCONF 時，總提到一種叫 YANG 的語言，那麼它們之間的關係是什麼？ 在組裝修改裝置配置 Payload 時，這裡也沒有用到 YANG ？ 其實，YANG 早已用到了。為什麼 `` 中可以包含 `` 和 `` 屬性。而不是把 `mtu` 放在和 `` 同級。 **原因就在於上面的格式，都是按照 YANG 的約束而來。** 在裝置中，存在著許多的 YANG Module，這些 Module 都是由 YANG 語言編寫的檔案。當 `agent` 接收到 RPC 請求時，會通過 YANG Module 來校驗發來的資料，格式是否合法。 **簡單來說，可以把 YANG 理解成一份約束檔案，裡面規定著傳來引數的格式，是陣列，物件還是其他格式。** 至於說為什麼 YANG 檔案能約束 XML 的檔案格式，原因在於 YANG 和 XML 之間是可以相互轉換的，甚至 YANG 還可以轉換成 JSON. 在之後的 RESTCONF 中會提到這一點。 到目前為止，對 NETCONF 已經有了一個大體認識： NETCONF 的出現是為了彌補像 SNMP 這些協議的不足。更好的滿足現在網路的需要，在易用性，拓展性等等方面都做出了進一步優化，從而更方便，高效的管理網路。 究其本質，NETCONF 是由多個協議組裝而成。資料的產生及校驗通過 YANG，資料的格式是 XML. 介面的呼叫通過 RPC，資料的傳輸通過 SSH. ### NETCONF 操作 Server 端：開啟裝置 NETCONF ``` #  開啟 netconf netconf-yang # 檢視 netconf 程序 show platform software yang-management ``` Client 端：測試裝置 NETCONF ``` ssh admin@IP -p 830 -s netconf ``` 關於 NETCONF 具體實現程式設計化操作，可以參見 [YANG]() 這篇。 ## RESTCONF 在談起 RESTCONF 前，想必剛接觸這個概念的人都會有這樣一個疑問 RESTCONF 和 REST 到底有沒有關係？ 再回答這個問題前，先來回憶一下什麼是 REST，以及 REST 出現的背景。 REST - Representational State Transfer，全稱為表現層狀態轉化，是建立在 HTTP 基礎上，對其進行規範的一種架構風格要求。 > 注意，REST 是一種設計的風格，而不是標準。 其認為，網路中的實體都是以資源的方式存在，但資源卻存在著多種表現形式，取決於使用者的需要。比如一個使用者的資訊，可以用 XML, JSON, 甚至是 txt 等多種方式表現出來。將不同的網路資源轉換成不同的表現形式，就是其表現層的體現。 而狀態轉移來說，由於 HTTP 本身是無狀態的協議，所以資源的狀態全都儲存在服務端。當對服務端的資源進行操作時，必然存在資料狀態的改變。 但由於狀態的改變基於表現層，所以稱為表現層狀態轉移。 在具體實現上，URI 定義了訪問資源的具體路徑，而 HTTP 中 Header 的 `Content-Type` 和 `Accept` 決定了了表現層的形式。 HTTP 中的 CURD 動作（Create，Put，Get，Delete，patch..）去改變服務端的資源狀態。 比如查詢書店具有的圖書： ``` GET http://www.store.com/products ``` 通過 REST 的方式，更合理的實現 WEB 服務之間的互動。 這時再看 RESTCONF，就很好理解了。RESTCONF 是通過 REST 來實現對網路裝置管理的協議。其本質和 NETCONF 很像，使用 YANG 進行資料的定義和約束，使用 HTTP 進行互動。使用 NETCONF 中 datastore 的概念，進行資訊的儲存。 ### RESTCONF 架構  圖中很好的表示了 RESTCONF 協議組成，很形象的指出 RESTCONF = NETCONF / YANG + HTTP(s). 如果拿之前的 [NETCONF 協議架構]()作為對比，RESTCONF 就是將： * 內容層，同樣由 YANG 約束生成。 * RPC 訊息層和操作層，換成了 HTTP 的操作層。 * 將 SSH 構成的傳輸層，換成了 HTTP（s）的傳輸方式。 ### RESTCONF VS NETCONF 互動  圖中很好的對比了 RESTCONF 和 NETCONF 的互動過程，都是採用了 C/S 架構，在具體元件上： | | NETCONF | RESTCONF | | --- | --- | --- | | 客戶端 | NETCONF client | HTTP Client | | 配置格式由誰約定 | YANG module / XSD | YANG module | | 傳送內容格式 | XML | XML/JSON | | 互動方式 | RPC | HTTP | | 傳輸協議 | SSH | HTTP(s) | | 服務端 | NETCONF server | HTTP server | 對於操作來說，將 RPC 操作換成了 HTTP 操作：  ### RESTCONF 操作 Server 端：開啟裝置 RESTCONF ``` #  開啟 RESTCONF restconf-yang # 檢視 RESTCONF 程序 show platform software yang-management ``` Client 端： 由於已經採用了 REST 風格，可以利用 POSTMAN 等等 HTTP 客戶端進行測試。 關於 RESTCONF 具體實現程式設計化操作和其 URL 的使用是非常重要的一部分，但由於其依賴 YANG 這個概念，這個後面會單獨提到，可以參見 [YANG]() 這篇。 ## 總結 這篇文章，耗時很久，查閱了大量資料，完成後真的如釋重負一般。 當然對網管協議也有了進一步的理解。 下面做一個簡單的總結： 傳統 CLI 配置方式，已經無法滿足當代網路可程式設計化的需要，而且在相容性，易用性，正確率存在著諸多問題，進而網管協議應運而生。 SNMP 作為推出的第一代協議，在一定程度上解決了裝置管理的問題。但由於其讀多寫少的特點，以及在相容性，效率，以及缺乏事務性的不足，在現網中，一般用其作為裝置配置採集或監控的工具。 為了更好的滿足網路的需要，第二代協議 NETCONF 出現，由於 NETCONF 天生 RPC 支援事務的特點，再加上 YANG 解決了多廠商命令相容性的問題，現被廣泛使用在各種網管平臺，SDN 控制器中。 隨後 HTTP REST 風格的普及，IETF 又推出了 RESTCONF 協議，將 NETCONF 和 HTTP 整合在一起，以更為流行的方式，實現對裝置的管理。 ## 參考 [SNMP 介紹](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/xe-16/snmp-xe-16-book/nm-snmp-cfg-snmp-support.html#GUID-633FA74F-DA24-419F-B0AC-3CD0D3FD8384) --- [NETCONF - wiki](https://en.wikipedia.org/wiki/NETCONF) [RFC6241 - NETCONF](https://tools.ietf.org/html/rfc6241) [NETCONF datestore](https://tools.ietf.org/id/draft-ietf-netmod-revised-datastores-08.html) [通過 NETCONF 實現網路自動化](https://medium.com/@k.okasha/network-automation-and-the-rise-of-netconf-e96cc33fe28) --- [REST 介紹](http://www.ruanyifeng.com/blog/2011/09/restful.html) [RESTCONF - RFC8040](https://tools.ietf.org/html/rfc8040) [基於Model驅動的自動化網路](https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2018/pdf/LTRCRT-2700.pdf) [RESTCONF 介紹](https://www.ciscolive.com/c/dam/r/ciscolive/apjc/docs/2016/pdf/DEVNET-1081.pdf) [CISCO 可程式設計化網路](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/XE3-9-0E/15-25E/configuration/guide/xe-390-configuration/prgrmblty.html) ---- [SDN 和 NFV 的關係](https://time.geekbang.org/column/article/