近年來，隨著全球云計算領域的不斷發展與業務的不斷增長，促使網絡技術也不斷發展，SDN技術應運而生，從最初的基于Openflow的轉發與控制分離的核心思想，人們不斷的去擴展SDN的外延，目前，人們可以達成一個共識，Openflow不再是必備條件（但轉發與控制分離依然是核心條件），網絡可編程能力慢慢地成為衡量一套SDN架構的重要標準之一。

傳統的網絡設備進行可編程操作，一般是基于CLI與SNMP協議去進行的，腳本也好，網管軟件也罷，都是在此基礎上去進行開發，實現我們今天要談的廣義范圍上的網絡可編程能力，進而實現很多場景的自動化。有些設備支持一些web界面的配置，通過xml進行整體配置的替換，此類極少，本篇不做贅述。

CLI

CLI（Command-line Interface），通過命令行的方式實現人機交互，是網工必備的熟練，人們每天打開軟件ssh或者Telnet到設備，然后貼入一段配置，保存生效。有一天人們厭倦了這種重復，通過程序自動生成配置腳本，批量登錄到設備下發配置生效，實現自動化，這是一種網絡可編程的方式。說說優點，非常符合人的思維、思路與既有的技術體系。但是說到底，這種方式更傾向于人，而非網絡設備。它有著以下一些缺點：

• 廠商之間的命令集存在巨大差異，何止是廠商，同型號不同軟件版本可能差異都非常大。
• 開發人員必須熟知命令集及其使用方法，從配置層面存在安全風險。比如手一瓢，想開端口變成了關閉端口...
• 對傳輸協議不強制要求（SSH與Telnet），存在生產安全風險
• 解析與生成配置的過程及其復雜，很多時候寫的正則只能是無限接近“真相”，而不是全部“真相”。
• 沒有事務性，一次配置可能部分生效，部分不生效
• 沒有自動化的檢查機制，完全依賴人。比如我想測試一下這段生成的腳本對不對，有辦法，但是很困難，很多時候難以簡單實現。
• 沒有數據建模的思想

CLI始終是人機交互的方式，可以通過程序可以賦予網絡一定的可編程能力，但它畢竟不是天生面向網絡可編程的一種方式。在當今云計算與SDN的浪潮之下，不適用于網絡中的大規模自動化部署，可編程能力有限，這其中的開發難度難以為外人道也。

SNMP

SNMP（SNMP，Simple Network Management Protocol），該協議能夠支持網絡管理系統，用以監測連接到網絡上的設備是否有任何引起管理上關注的情況。它由一組網絡管理的標準組成，包含一個應用層協議（application layer protocol）、數據庫模式（database schema），和一組數據對象。

維基百科里的一段內容，我們劃下重點，網絡管理，監測，數據對象。它是用來管理網絡的，能配置能采集，主要用于監測，它有數據建模，將網絡設備的一些模塊、特征、狀態數據結構化。主要是用于網管系統（劃重點，多是監控）。那我們也來說說它的缺點：

• 可讀性差。它偏向人機中的“機”，用起來可讀性差，建模數據也可讀性低，用的是一個ASN.1的超集。
• 安全性受限，有v1 v2c v3三個版本，安全性依次提高，但是目前最通用的是v2c，安全性有限。v3版本從設計上很安全，但是普及性。。。
• 無備份及恢復回滾等機制。命令行我們還有show run等方式備份，但snmp。。。
• 極少的寫操作。讀很多，寫很少，多用于監控。
• 能采集的數據項有限，無法獲取整臺設備的配置。很多時候我們發現能用cli采集出來，但是無法用snmp采集。
• 性能有瓶頸，采集數據上限64K，采集顆粒度過大，在大型復雜網絡中可能是分鐘級或者更久。這個也劃下重點，我們對于顆粒度的要求也非常嚴格，很多時候希望幾秒鐘采集一次端口流量。大型網絡中，傳統的網管軟件，我覺得是...多展開一句，現在的方式是Telemetry（比如gRPC）可以實現微秒級，有的需要軟硬件結合才行，目前還未普及，但未來一定是趨勢，至于這個未來什么時候來..

SNMP自誕生之日，極大地被應用在了網絡監控領域，用于獲取數據進行監控，配置能力的缺失與復雜導致人們對其在網絡配置方面使用甚少。只有讀的網絡可編程...

Netconf協議與YANG Model

面向下一代網絡，我們需要什么樣的網絡管理協議去更好地實現網絡可編程能力，提高自動化的水平？

IETF于2002年在RFC3535提出了以下幾點設想（實際有33條之多，結合網上資料與筆者認知，寫了以下幾條）：

1、有對網絡配置的可編程接口

2、同樣的配置可以跨廠商型號

3、需要統一可讀性良好的建模語言

4、完整的錯誤檢查及恢復功能

5、事務性

有了想法，那就去實現，在2006年IETF提出了Netconf協議，基于RFC3535提出的問題進行了解決。最初的Netconf只規定了協議的基本框架和操作，定義考慮RFC3535的一些問題的解決方法，沒有規定統一的建模語言，所以早期部分廠商的設備只是支持Netconf的一些基本操作，底層沒有使用統一的數據建模語言。

在2010年發布了RFC6020， 提出了YANG Model建模語言，以及和NETCONF 的結合方法。一個定義的是數據建模的語言統一各廠商之間的底層資源邏輯，一個定義的是對配置數據、狀態數據的操作統一各廠商的命令集，YANG模型創建的數據實例包裹在Netconf協議之中傳輸，二者相互結合，構建了一套新的基于YANG模型的使用Netconf協議驅動的新時代的通用網絡可編程接口。

在2016年之后，Netconf協議與YANG Model緊密結合并流行開來。至此我們再去看一些SDN架構軟件層面的時候，多多少少聽到了這兩個名詞。

YANG 與Netconf，一個是靜，一個動，就好比陰陽，二者衍生出了下一個時代的網絡可編程世界。（當我們去看github上，YANG的倉庫時也會發現，它的圖標是太極，包括它名字中與“陽”的關聯也多少透露出當初設計者的設計思想）

我們接下來就簡單講講YANG Model與Netconf協議，我們先來講數據建模語言YANG，看看它是如何描述這個網絡世界的數字孿生。

YANG Model

在RFC6020的文檔中，開篇明義，YANG，A Data Modeling Language for the Network Configuration Protocol。是Yet Another Next Generation (Yang) Data Modeling Language的縮寫。它是一種建模語言，用于描述網絡概念的。

支持定義列表、字典、甚至更復雜的數據結構，支持約束、枚舉、引用導入，版本管理、命名空間。由于篇幅，我們做簡單講解，詳細信息大家可以參考：

官方文檔：https://tools.ietf.org/html/rfc6020

互聯網博文：https://www.jianshu.com/p/ca7f5fe11fae

它可以非常簡單的用結構化語言描述出這個網絡設備。比如對于一個端口的定義：

作為一個專業的運維人員，有點網絡基礎和一點點編程基礎就可比較清晰的了解端口的定義，它是一個list結構的，可以有多個，它的一個屬性是interface-name(同時是key，唯一，不可重復)，還有speed屬性和duplex屬性，他們都是字符串。
一個網絡設備的很多屬性都以YANG Model去描述，包括配置狀態和運行狀態。

就這樣，YANG Model用結構化語言描述了這個網絡世界。有興趣額的可以看看上面的那個互聯網博文，有非常深入的描述。

它可以很好的轉換成XML數據，包裹在Netconf協議之中進行傳輸（我們后續會講解）：

同時為了拉平廠商之間的差異，谷歌牽頭的Openconfig對數據模型就行了標準化，從官網中我們看到這樣一行標語“Vendor-neutral, model-driven network management designed by users”,由用戶設計的、跨廠商通用的、模型驅動的網絡編程（我么先這么翻譯吧）。簡單點說它是為了讓各廠商之間的建模是相同的，大家再去配置某些數據的時候就不用一個個去翻看各廠商的私有的yang model了。但是網絡總有私有協議，不同廠商總會為了“更好的用戶體驗”和“更好的商業戰略”去創造新的、更牛的私有協議（這真的是網絡廠商的原罪啊）。圖中是一些比較常用openconfig的yang model實現。

從圖中來看，我覺得還是挺多的，常用的配置比較齊全。但是實際中要看廠商是否也支持這些yang model。某科的一些高版本的設備基本都是支持的。國產的我暫時沒去細看。

網絡是不可能完全相同的，能做到大同，對于一個做網絡運維開發的工程師來說，已經是謝天謝地了！

openconfig可以在

https://github.com/openconfig/public/tree/master/release/models

查找。私有的yang model 大家可以去各個官網查找。

Netconf協議

說完了yang model，我們來聊聊Netconf協議，yang model定義了網絡世界的數字描述，Netconf定義了對數據的獲取（get）與調整（config）。
Netconf對yang model描述的世界的數據yang data封裝操作，實現對網絡世界的管理。

yang data封裝在xml中，然后通過Netconf協議進行管理。它是一個分層思想很棒的協議，有層次的描述了這個協議的一些細節。我們看看上圖。

• 傳輸：Netconf是通過SSH協議傳輸，面向連接，且有安全保障。
• 消息：通過RPC進行對網絡設備的遠端調用，網管發出rpc請求，網絡設備恢復rpc-reply。
• 操作：這是Netconf的靈魂所在，它支持get（配置及運行數據）、get-config（獲取配置數據，且一個設備可以有多個配置數據，一個running，一個startup，多個candidate候選）、edit-config（配置網絡設備的參數，支持增刪改）這些常用的，還有delete-config、copy-config（復制配置到目的地，目的地可以是ftp、文件或者是正在running的配置等等）、lockunlock(對配置進行鎖定，防止多進程操作導致的配置沖突或者失敗等情況)等等。
• 數據：data就是xml包裹的yang data，如上圖我們所描述的那個端口一樣，結構化數據易于編程。用來描述要配置或者刪除或者獲取的數據。

這就是Netconf的四個layer，控制端與網絡設備端通過Netconf溝通，通過傳統的ssh協議，用Netconf子系統，默認端口是830。如下圖：

這個圖用原始的ssh演示了交互，但是實際上我們是通過編程去實現這個過程的。編程的實現方式我后續會演示給大家。

Netconf配置網絡設備，交互過程大致如下：

這個圖，如此low，大家也可以看出來，是我自己畫的... 我對Netconf的理解如上，網上很多圖，我覺得都是不太對的，server agent 很多行為都對不上。這個是我登錄設備所直觀感受的，當然也和官方文檔是一一對應的。

我們可以看看一些Netconf的例子：

hello，建鏈。

我們看到了幾個關鍵字，Netconf的版本，支持的YANG Model，session id。同時hello中表明我們是在什么樣的命名空間下操作，此例中是Netconf對應版本。

獲取配置

get-cofig有一個參數是source，即獲取哪里的配置數據（running、startup 或者其他）。還有一個參數是filter，即在哪個yang model描述的數據模型獲取哪個數據。這個對應的是網絡設備當初發送的capability中的。如果成功會回復對應的配置數據。

獲取配置或者運行數據

類似get-config，但是獲取的是running配置（個人理解）或者運行數據。可以指定filter。

復制配置

復制操作兩個參數，源與目的。成功回復的是ok標簽。

編輯配置

編輯配置的時候指定編輯的數據項，capability的命名空間及對應標簽，比如這個是配置dhcp的，它是有http://tail-f.com/ns/example/dhcp這個yang model所描述。

優雅的關閉session

在ssh里來回傳輸的就是這種報文，我們只是把報文部分摘出來，方便大家理解。

然后簡單補充一些內容，供參考。

• Netconf是基于session的，每次成功都會有一個session id。
• 每次請求都有message id，只要是逐漸變大即可。
• 對數據配置可以鎖定，獨占，通過lock操作。
• Netconf是事務性的，操作要么全部實現，要么全部不實現。同時根據官網文檔，這個事務性是針對N臺網絡設備的配置，即一次配置多態都可以支持事務性。不過我沒操作過...
• Netconf支持訂閱，看設備性能而言，數量級大概是5個session左右，我可以訂閱某數據項，當發生變化的時候，設備會告知我。
• capability，我是這樣理解的，網絡設備發送的是Netconf的版本和YANG Model，控制端發送的是Netconf的版本，二者對的上Netconf版本才能繼續。這條是我的直觀感受。歡迎指教。
• get edit等操作會指定要改的數據，用filter可以過濾。
• copy-config支持把一個配置全集從某處復制到某處，某處可以是FTP File，設備上的running、startup、candidate配置。
• Netconf還支持對配置的驗證，使用validate操作。

本文還是希望做到科普，具體細節不做贅述，大家可以去看看RFC的相關協議，其實不是很長。

在實際中基于一些開源的軟件，比如python的ncclient，我們可以非常方便的對網絡設備進行自動化配置，實現網絡可編程。這就是Netconf與YANG Model的使命所在。

網絡人員閱讀格式良好的YANG Model定義，基于Netconf定義的操作，使用相關的編程語言對網絡設備進行可編程操作。通過這種方式鑄就網絡可編程的道路。

我們再去擴展的想象一下，YANG Model已經定義了網絡設備的數據結構，我們可以通過Netconf去操作，那是不是也可以通過其他協議去操作呢？

答案是肯定的，實際上后續也從Netconf衍生出了很多其他的協議，比如RESTConf。如下圖，

YANG Model（public與native）定義了數據結構，之上是新的網管協議，Netconf、RESTCon、gRPC等等。這樣我們可以通過基于HTTP RESTful API的RESTConf對網絡設備操作，也可以通過基于SSH的Netconf對網絡設備操作，也可以通過基于HTTP2.0的gRPC對網絡設備操作，他們都是基于數據結構良好的YANG Model，編寫對應的data，封裝到xml或者json當中對網絡設備編程，這就是未來的網絡可編程之路，準確點說，是Model Driven Program，基于模型的網絡可編程。網工逐步的關注于設備的參數，而不是命令集，通過閱讀對應的數據模型，對網絡進行參數配置。

寫在最后，我為什么要開這個公眾號。本人上學期間學的是計算機科學與技術，步入職場后，進行的是網絡運維工作，想想分團隊原因可能是我研究生是網絡技術研究院導致的（手動滑稽），從最開始的網絡運維到后期通過工具基于CLI去簡化工作，提高效率，后逐步將工具開發成BS架構的web應用，不斷接觸新技術，后續不斷豐富新功能，有幸趕上了開源技術與SDN的發展，逐步轉型做了NetDevOps方面的工作，用自己的編程能力為團隊提高運維能力，自己也樂于這一行行代碼的編寫中。隨著編寫的不斷深入，逐步發現，NetDevOps應該是一個未來每個網工應該具備的技能（眾人拾柴火焰高），這樣才能即高屋建瓴又可快速實現。反觀網絡上的一些資料，說實話國內非常少，國內的氛圍也不是很強，國內的很多軟件都是基于老的CLI后者snmp，大家工作還是在用文本工具和SSH工具。于是希望自己能夠授人以漁，將自己的經驗（坑）和技能分享給更多的網絡運維工程師，盡自己的一點綿薄之力。小處說，你能學點東西減少自己的工作量，著眼遠處，國內的網絡運維能真正向自動化方向演進。

后續會錄一些視頻和編寫一些文章，寫一個文檔，感覺真費勁，歡迎訂閱收藏點擊喜歡在看之類的。

附錄：

Netconf常見的operation

總結

以上是生活随笔為你收集整理的基于python的modbus协议编程_通往未来的网络可编程之路：Netconf协议与YANG Model的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。