从零开始学OpenDaylight之六:YANG

时间:2022-02-17 19:08:18

 一、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

        从零开始学OpenDaylight之六:YANG

 

 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的网络管理构架;

 

     从零开始学OpenDaylight之六:YANG从零开始学OpenDaylight之六:YANG

从零开始学OpenDaylight之六: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。

 

从零开始学OpenDaylight之六:YANG从零开始学OpenDaylight之六:YANG

 

 

三、YANG的未来

      YANG的使用已不局限于NETCONF

从零开始学OpenDaylight之六:YANG

 

四、YANG学习资料链接:

1. YANG工具:http://www.yang-central.org/twiki/bin/view/Main/YangTools 

2. yang模型理解http://www.sdnlab.com/18066.html

3. ODL中拓扑展现功能总结 http://www.sdnlab.com/18534.html

4. ODL中拓扑展现功能总结(二)http://www.sdnlab.com/18730.html

5. SDN网络与传统网络对比分析 http://www.sdnlab.com/18725.html

 

本文参考互联网相关资料整理