1. 問題的提出

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

(1).從操作員的角度來(lái)看，易用性是任何網(wǎng)絡(luò)管理技術(shù)的關(guān)鍵要求；

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

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

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

(5).支持在多個(gè)設(shè)備上配置事務(wù)，以簡(jiǎn)化網(wǎng)絡(luò)配置管理；

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

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

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

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

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

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

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

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

2. 標(biāo)準(zhǔn)的制定

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

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

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

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

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

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

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

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

總的來(lái)說，我們重點(diǎn)關(guān)注如下幾標(biāo)準(zhǔn)：

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

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

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

3. NETCONF基礎(chǔ)知識(shí)

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

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

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

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

商；

③Client端發(fā)起rpc請(qǐng)求消息到Server端，進(jìn)行設(shè)備的配置請(qǐng)求；

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

④Server端進(jìn)行操作并將應(yīng)答消息封裝到rpc-reply，回復(fù)給Client端。

元素消息是對(duì)消息的響應(yīng)。

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

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

現(xiàn)在腦補(bǔ)一個(gè)場(chǎng)景：需要配置數(shù)百上千臺(tái)設(shè)備，并且這些設(shè)備來(lái)自不同的廠商，那如何實(shí)現(xiàn)自動(dòng)化配置呢？DevOps人員只需做如下步驟：

①構(gòu)建自動(dòng)化配置基礎(chǔ)應(yīng)用程序；

②加載廠商設(shè)備的YANG文件；

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

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

⑤不同廠商重復(fù)步驟；

⑥部署自動(dòng)化配置基礎(chǔ)應(yīng)用程序。

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

5. NETCONF在SDN中的應(yīng)用

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