從零開始學OpenDaylight之六：YANG

本文轉載自查看原文 2017-08-04 22:29 8773 OpenDayLight

一、YANG基礎

1. 什么是YANG?

YANG 是隨着 NETCONF 協議而產生的數據建模語言，由RFC6020定義，類似於XML Schema和SNMP的SMI，具有良好的可讀性和可擴展性。其關鍵特性：

● 服務和網元數據模型vs信息模型（UML）
- YANG是數據建模語言
● 領域專用語言
- 專為網絡配置而生
● 網元配置建模
- Yang is rich enough to model NE configuration (often follow the CLI)
● 服務配置建模
- Yang is rich enough to model services in the same language as the NE
● 網絡拓撲建模
- 通過發布YANG來可以支持任何新設備
● 設備廠商必須通過IETF創建和發布自己設備的楊模型

需要解釋一下數據模型和協議的關系：

什么是數據模型？一個數據模型明確和精確地確定數據的結構、語法和語義；那協議呢？用於查看和操作數據的遠程原語（例如：XML RPC或HTTP方法）；對數據模型定義的數據進行編碼（例如：XML或JSON）

YANG Concepts

2. 為什么會出現YANG?

首先從NETCONF的出現說起，它是一種網絡配置協議，該協議的產生起源於網管的一次用戶體驗吐槽大會，在會上提出了網絡管理中的14個問題：

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

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

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

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

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

-- 服務和網絡管理，而不僅僅是設備管理

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

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

-- 配置數據的導入導出

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

-- 一致性檢查

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

--基於文本進行配置

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

提取、記錄和規范這些網絡范圍的配置數據庫模式的公共部分是可取的。

--標准化數據模型

(11). 區分配置的分布和特定配置的激活是很重要的。設備應該能夠容納多種配置。

--支持多種配置集

(12). Typical requirements are a role-based access control model and the principle of least privilege, where a user can be given only the minimum access necessary to perform a required task.

(13). It must be possible to do consistency checks of access control lists across devices.

(14). SNMP access control is data-oriented, while CLI access control is usually command (task) oriented. … As such, it is a requirement to support both data-oriented and task-orientedaccess control

--支持基於角色的配置 ROLE-BASED Access Control

為解決這些問題，NETCONF歷經多年的討論，最終產生了一系列的標准：

(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月RFC6242更新了基於 SSH 的傳輸模式。NETCONF 協議是完全基於XML 之上的，所有的配置數據和協議消息都用XML 表示。

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

再次網絡設備配置的實踐角度來說，讓你配置一台設備，你直接CLI敲命令就可以了，如果讓你配置10台、100台設備你會怎么去做，你肯定會去想有沒有這樣的方法，可以使用極少的步驟統一配置下發，甚至一鍵下發。進一步來講，如果這100台設備又分屬不同的廠商，廠商或多或少有些差別，難度又加大了。以下兩部分摘自知乎，講得比較好，易於理解。

 網絡設備的配置結構往往是是不同的。實現同樣的功能的不同設備需要的配置結構也往往不同。比如思科設備接口上配置一個address 只要知道接口名 ip版本 和地址掩碼就足夠了 但是juniper的機器上不但要知道這些還要額外提供一個unit 號來標識邏輯接口。特別是現在nfv大潮下，nfv是干毛的，網絡功能虛擬化，既然虛擬化我就更關注的是功能本身而不是實現這個功能的設備，對於管理人員來說，他往往就只想告訴一套nfv系統，我要什么功能，比如 我要一號站點能聯網我要DHCP服務我要VPN，而單純利用netconf是無法配置的，因為還要求具體的配置結構。這可咋整！

沒事兒，我們只要給對應的設備所需的配置結構來個模型不就行了？到時候不就是完形填空嗎，yang model就是吃這口飯的，我只需知道對應設備的yang model就可以向管理者請求對應設備所需的信息了，具體結構上的問題有yang model來解釋。

什么叫做結構上的問題呢？還是舉剛才那個例子

思科為啥不需要unit號來指定邏輯端口呢？因為它的邏輯端口藏在接口名里

所以它的配置類似這樣

接口名{
    ip{
        address x.x.x.x
        mask x.x.x.x
    }
}
但是juniper的額外需要一個unit號來表示邏輯端口

所以它的配置類似這樣

接口名{
    unit x {
        ip{
            address x.x.x.x
            mask x.x.x.x
        }
    }   
}
當然實際上他們的yang model 要比這個復雜的多，比如juniper還有family 這個層級這里就是舉一個例子

但是對於上層用戶管理來說，他只用填邏輯口號，接口名，地址以及ip版本就可以了，他不需要知道具體到底實際的配置長啥樣了，因為有可能及其復雜233.

是不是感覺很完美了，這樣NFV可以讓服務提供商隨意換設備了，底層是思科華為還是juniper沒啥所謂，反正只要有yang model我們就知道到底怎么配一台機器了。

XML呢，剛說過netconf是一種協議，它實際是個服務器，接受客戶端發來的請求來配置自己，所以每台設備上都有一個netconf server，這里的信息交互就是用xml來實現的，所以yang model其實就是一種描述XML結構的模型。

簡單而言，支持netconf的設備其實就是有了一套有標准的設備API。
這套API不光能夠做配置，還能提交一些本來由CLI實現的命令。
本質上，netconf協議交換的是XML，傳輸的是一個一個的RPC。
你只需把你需要的配置，按照你設備上的netconf模型寫一個xml，通過一個netconf client 發送給設備，設備就可以去給你配置，並把配置的結果返回給你。

傳統我們做自動配置腳本，都是基於ssh連接到設備上，然后一條一條命令去輸入，這種腳本局限性很大，搞成模板替換數據也是很費神的一件事兒。有了netconf這些都會成為歷史，只需整體寫一個xml模板，然后因為它是xml，所有很多python的模板包都可以輕輕松松拿來用，比如jinjia template。 然后，因為你的配置是整體發送過去的，也就不用一條條命令來看執行結果，處理那些討厭的問題， 比如突然某一條失敗了，配置要回滾。。。

更棒的是，netconf 對不同的配置結構都是通過統一的模型語言來描述的，也就是yang model，大部分的配置結構都可以用yang model來描述，理論上你要是有目標主機的yang model，連配置模板也可以自動生成。。。如果你給你的腳本加個fancy的GUI，那么恭喜你，你完成了一個SDN的雛形。

SNMP--網絡監控協議；NETCONF--網絡管理協議；OpenFlow--網絡控制協議；

3. 為什么不使用XML Schema Language?

XML Sechema 也可以進行XML的檢驗，但不易於操作員來閱讀，而YANG可讀性好、簡單、直接、可擴展；

二、YANG在OpenDaylight中的使用

YANG在OpenDaylight中也用來做為建模語言，MD-SAL中M即是YANG。