1. 問題的提出

在單機配置時代，網絡工程師通過命令行直接就搞定了；在網絡設備達到數十臺、數百臺時，而這些設備可能來自不同的廠商時，網絡工程師對網絡管理的窘境有頗多怨言。作為網絡工程師面臨的挑戰和壓力是什么？要維持上萬臺的設備、數十萬的部件和上千條線路。這么多的壓力終于在網管的用戶體驗吐槽大會上爆發，提出了網絡管理中的14個問題：

(1).從操作員的角度來看，易用性是任何網絡管理技術的關鍵要求；

(2).必須明確區分配置數據、描述操作狀態的數據和統計數據；

(3).需要能夠從設備中提取單獨的配置數據、操作狀態數據和統計數據，并能夠在設備之間進行比較；

(4).必須使操作員能夠集中于整個網絡的配置，而不是逐個設備配置；

(5).支持在多個設備上配置事務，以簡化網絡配置管理；

(6).假定需要進行配置 a和配置 b，應該能夠生成從a到b所需的操作，以便使得狀態變化對網絡系統產生最小的影響。將配置更改所造成的影響降到最低是很重要的；

(7).備份和恢復配置的機制是操作人員需要的原始操作；

(8).為了在兩個配置之間確定變化以及這些配置是否一致，必須很容易地對配置進行一致性檢查；

(9).基于文本的配置，如差異化和版本管理工具，如RCS或CVS，可以用來處理配置，這意味著設備不應任意重新排序數據，如訪問控制列表；

(10).網絡范圍的配置通常存儲在中央主數據庫中，并轉換成可被推送到設備的格式，通過生成CLI命令序列或將完整的配置文件推送到設備上。沒有共同的數據庫模式……盡管各種操作符使用的模型可能非常相似；

(11).區分配置的分布和特定配置的激活是很重要的，設備應該能夠容納多種配置； (12).基于角色的訪問控制模型和最小權限原則，其中只能為用戶提供執行所需任務所需的最小訪問權限；

(13).可以跨設備對訪問控制列表進行一致性檢查；

(14).SNMP訪問控制是面向數據的，而CLI訪問控制通常是面向命令（任務）的。 因此，需要支持面向數據和面向任務的訪問控制。

2. 標準的制定

為解決上述的問題，歷經多年的討論，最終產生了一系列的標準：

(1).RFC4741- 4744 分別描述了NETCONF在三種不同的傳輸模式SOAP，BEEP和SSH下是如何工作的。

(2).2008 年7 月推出RFC5277，主要定義了NETCONF的事件通知機制，用于故障管理。

(3).2009 年5 月推出的RFC5539 描述了NETCONF如何保證傳輸層傳輸信息的安全機制，加強了NETCONF的安全體系。

(4).2010年，RFC 6020 為NETCONF的YANG建模語言。

(5).2010年，RFC 6021 通用YANG的數據類型。

(6).2011年6月，RFC6241定義NETCONF的安裝，操作和刪除網絡設備配置的機制。RFC6242更新了基于 SSH 的傳輸模式。NETCONF 協議是完全基于XML 之上的，所有的配置數據和協議消息都用XML 表示。

(7).2011年，RFC6244 使用NETCONF和YANG的網絡管理構架。

總的來說，我們重點關注如下幾標準：

① RFC6241定義NETCONF的安裝，操作和刪除網絡設備配置的機制。

②RFC6242更新了基于 SSH 的傳輸模式。NETCONF 協議是完全基于XML 之上的，所有的配置數據和協議消息都用XML 表示。

③RFC6020指出，YANG是一種數據模型語言(Data Modeling Language)，用來描述NETCONF相關的網絡配置和網絡狀態的數據模型、RPC和Notification。

3. NETCONF基礎知識

NETCONF協議是網絡設備配置的標準協議，用來進行網絡設備的配置管理、下發、更改等問題。它劃分為4層：安全傳輸層、消息層、操作層和內容層。如下圖所示：

其中，傳輸層規定傳輸層必須使用TLS、SSH等帶有安全加密的通信協議，其中SSH是當前應用最多的傳輸層協議；消息層提供 RPC 接口，用于實現遠程調用和通知；操作層定義了 edit-config、get-config、delete-config 和 copy-config 等9種操作，用戶也可以自定義RPC操作；內容層描述了配置數據和通知數據，但沒有標準化數據結構模型，該模型由RFC 6020：YANG建模。YANG的信息存儲在NETCONF協議的3個標準概念配置數據庫，如下表所示：

①Client端發起hello消息到Server端并告知對NETCONF的支持能力；

②Server端發起hello消息到Client端并告知對NETCONF的支持能力，完成能力協

商；

③Client端發起rpc請求消息到Server端，進行設備的配置請求；

元素封裝了從客戶端到服務器端的協議操作請求。

④Server端進行操作并將應答消息封裝到rpc-reply，回復給Client端。

元素消息是對消息的響應。

![圖片](https://mmbiz.qpic.cn/mmbiz_png/prnpGufYiaQLFCAWDk1YTaHzd4Qdb0MeVkiaJVVnCktIpxbNxCTFrDk66eDzAehz51ffDfBkstgGcZyApVAPWMCQ/640?wx_fmt=png&tp=wxpic&wxfrom=5&wx_lazy=1&wx_co=1)

NETCONF配置信息的開發較為簡單，即在代碼編寫“拼接XML字符串，調用rpc接口”的邏輯就可以了，感興趣的人員可以參考：

https://www.juniper.net/documentation/en_US/junos/topics/task/installation/netconf-java-toolkit-downloading-and-installing.html

4.YANG

NETCONF是網絡管理協議，分為安全傳輸層、消息層、操作層和內容層等4層，而YANG是和NETCONF相伴而生的，可以對操作層和內容層進行建模。但為什么要用YANG呢？我們知道SNMP在請求端使用BER對操作請求和應答進行編碼，并在接收端使用BER進行解碼。就BER編碼（Basic Encoding Rule）來說，其過程是將數據分成TLV三部分并按照TLV的順序對數據進行編碼，生成字節流（T-Tag-類型標識，L-Length-類型的長度，V-Value-數據內容）。在這種情況下，每個字段出現的順序是預先約定的，其類型和長度是固定的，如果要在新增字段，則意味著協議兩端的編解碼都要進行修改。而如果將本部分內容通過一個文件來描述或者建模，協議兩端根據該文件進行編解碼，則與具體的字段解耦了。所以，YANG建模語言就適時而生了（RFC6020：https://tools.ietf.org/html/rfc6020#page-11）。

現在腦補一個場景：需要配置數百上千臺設備，并且這些設備來自不同的廠商，那如何實現自動化配置呢？DevOps人員只需做如下步驟：

①構建自動化配置基礎應用程序；

②加載廠商設備的YANG文件；

③使用代碼生成工具將YANG文件轉化為公共代碼模板；

④根據業務場景編寫RPC和數據邏輯代碼；

⑤不同廠商重復步驟；

⑥部署自動化配置基礎應用程序。

經過這些步驟后，你需要做的就是“一鍵”下發配置，成百上千臺設備配置就搞定了。

5. NETCONF在SDN中的應用

在現有的網絡中，NETCONF和YANG已有了較好的實踐。就軟件定義網絡而言，從OpenDaylight的架構圖中，我們可以看到NETCONF即能做北向接口也能做南向接口。同時，不同廠商的控制器也支持NETCONF作為其接口協議。NETCONF作為出色的網絡管理協議，將繼續發揮其優異的網絡配置作用。