1. 問題的提出

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

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

(2).必須明確區(qū)分配置數(shù)據(jù)、描述操作狀態(tài)的數(shù)據(jù)和統(tǒng)計數(shù)據(jù)；

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

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

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

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

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

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

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

(10).網(wǎng)絡范圍的配置通常存儲在中央主數(shù)據(jù)庫中，并轉(zhuǎn)換成可被推送到設備的格式，通過生成CLI命令序列或?qū)⑼暾呐渲梦募扑偷皆O備上。沒有共同的數(shù)據(jù)庫模式……盡管各種操作符使用的模型可能非常相似；

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

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

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

2. 標準的制定

為解決上述的問題，歷經(jīng)多年的討論，最終產(chǎn)生了一系列的標準：

(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的數(shù)據(jù)類型。

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

(7).2011年，RFC6244 使用NETCONF和YANG的網(wǎng)絡管理構(gòu)架。

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

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

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

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

3. NETCONF基礎知識

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

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

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

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

商；

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

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

④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配置信息的開發(fā)較為簡單，即在代碼編寫“拼接XML字符串，調(diào)用rpc接口”的邏輯就可以了，感興趣的人員可以參考：

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

4.YANG

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

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

①構(gòu)建自動化配置基礎應用程序；

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

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

④根據(jù)業(yè)務場景編寫RPC和數(shù)據(jù)邏輯代碼；

⑤不同廠商重復步驟；

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

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

5. NETCONF在SDN中的應用

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