一文讀懂網管協議 - SNMP，NETCONF，RESTCONF

一文讀懂網管協議 – SNMP，NETCONF，RESTCONF

2021 年 2 月 22 日
筆記
network

本文篇幅較長，主要涉及以下內容：

介紹傳統 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.

在數據採集方面，傳統人工定時登上設備材料系統日誌，分析情況，這更加無法適用。在故障響應上，數據採集，分析都存在先天的不足。比如收集效率低，數據的利用率延遲或不高。

最後從商業成本的考慮，人工的維護方案也是較高的一筆輸出。

而且對於工程師而言，需要不斷學習不同廠商的配置命令，學習成本很高，但意義不大。

通常來說，網路工程師在開始一個項目前，會進行如下四個部分：

了解用戶的需求
針對用戶的需求，確定相應的具體方案。
根據用戶的方案，查找並學習對應設備的配置命令
最後申請割接窗口，準備回滾方案並實施。

在這裡的第三步，其實就是一個比較耗時，但沒多少意義的過程。因為在集中學習不同廠商的設備命令，但從業務考慮明明解決的都是同一個問題。

在發現 CLI 管理設備的方式出現瓶頸後，並不是馬上過度到現在流行的網路自動化配置方式，而是先推出了一個叫 Simple Network Management Protocol – SNMP 的應用層協議，甚至在當前的一些現網中，依然被使用。

SNMP

SNMP 的出現，主要想解決兩個問題：

設備資訊的採集
使用 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 的出現，在一定程度上解決了網路設備的管理問題。但面對現代大規模的網路來說，依然有著很多挑戰：

性能不足，在下發和讀取配置時，採用依次讀取，效率低。
下發不足，支援寫 MIB 的對象相對於讀較少。
不支援事務機制，在配置下發失敗是，無法回滾。
拓展性差，提供給外部的介面較少。
模型兼容性差，MIB 庫混亂，無法適配所有廠商，導致定義各種私有 MIB 庫。

面對這些問題，06 年由 IETF 領導並開發出了一個新的協議 – NETCONF，網路管理協議。和 SNMP 不同，NETCONF 基於 RPC 的方式，天生就能很好的支援事務回滾等操作，從而更好地處理複雜網路的各種需求。

NETCONF

NETCONF 協議提供了一種更簡單的方式來管理（”查詢，配置，修改，刪除”）設備，就像資料庫操作中的 DML. 同時開放了 API 介面，當想要對設備進行操作時，直接通過調用 API 進行。

對於支援 NETCONF 的設備來說，至少能開啟一個或多個 session。並且在每個 session 中應用的配置更改，都可以被全局的 session 監聽到。這就讓一個或多個 Manager(Client) 操作同一個設備（agent）成為了可能。

相比 SNMP 而言，有著如下的優勢：

基於 RPC，增加了事務支援
優化查詢功能，增加過濾查詢方式
拓展性強，在其協議內部分為 4 層，各層之間相互獨立
更好的將配置和狀態數據解耦，並區分狀態數據（candidate, running, startup）
易使用，結合提供的 API，實現可編程性的網路操作
安全性更好，在傳輸層可選用 SSH，TLS 協議等。

NETCONF 採用 C/S 的架構，通過 RPC 在 client 和 server 間交流。client 可以是 Python 腳本或應用。server 一般指的是網路設備，在具體實現上有三個組件：

NETCONF agent：運行在網路設備上，用於接收和處理 RPC 請求。還可主動將一些告警事件通知客戶端。
NETCONF 客戶端：利用 NETCONF 協議對網路設備進行管理以及接收 agent 發出的告警通知。
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 層，各層之間項目獨立。

內容層：

這一層包含了以 XML 或 JSON 格式的配置數據，也就是想對設備進行管理的具體內容。（由 XSD 或者 YANG 約束生成）

操作層：

定義了 Client 和 Server 交互時的一系列操作方法，用於獲取或修改配置數據。

消息層：

為編碼數據時，提供了一種 RPC 和通知的機制：

* RPC invocations(<rpc> messages)  
* RPC results(<rpc-reply> messages)
* event notifications(<notification> messages)

傳輸層：

NETCONF 使用 SSH 或 TLS 協議，保證數據在 Client 和 Server 傳輸的安全性。

NETCONF 交互

對於 Manager 和 Agent 來說，Session 建立會經歷如下的過程：

Manager 請求 NETCONF 中 SSH 子系統建立連接。
Agent 回復 Hello 消息，包含本身支援的特性和能力。
Manager 告知 Agent 自己所支援的特性和能力。
Manager 開始發送 RPC 操作請求。
Agent 回復 RPC 請求操作結果。

具體看下 NETCONF 中消息的報文結構，以修改介面配置舉例：

Manager 請求變更介面配置：

 <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <top xmlns="//example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu>1500</mtu>
             </interface>
           </top>
         </config>
       </edit-config>
</rpc>

Agent 回復結果：

 <rpc-reply message-id="101 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
 </rpc-reply>

首先可以看到，NETCONF 使用 XML 作為數據傳輸的格式。

第一行的 <rpc> 標籤，表明該請求是 RPC 請求，message-id 屬性由 client/manager 確定。Agent 在回復結果時，會帶上 message-id，用於表示該操作的結果。

urn:ietf: 屬性表示 XML 中的命令空間。 base：1.0 表示當前 NETCONF 的版本。

第二行 <edit-config> 指定執行 RPC 操作的內容為修改配置。

之後 <config> 中包裹的內容就是，想要下發的配置內容，修改 mtu 為 1500.

但這裡還有一個疑問，在說到 NETCONF 時，總提到一種叫 YANG 的語言，那麼它們之間的關係是什麼？

在組裝修改設備配置 Payload 時，這裡也沒有用到 YANG ？

其實，YANG 早已用到了。為什麼 <interface> 中可以包含 <name> 和 <mtu> 屬性。而不是把 mtu 放在和 <interface> 同級。

原因就在於上面的格式，都是按照 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 //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 整合在一起，以更為流行的方式，實現對設備的管理。

參考

Tags: network