什么是NETCONF

1. 问题的提出

在单机配置时代，网络工程师通过命令行直接就搞定了；在网络设备达到数十台、数百台时，而这些设备可能来自不同的厂商时，网络工程师对网络管理的窘境有颇多怨言。作为网络工程师面临的挑战和压力是什么？要维持上万台的设备、数十万的部件和上千条线路。这么多的压力终于在网管的用户体验吐槽大会上爆发，提出了网络管理中的14个问题：

(1).从操作员的角度来看，易用性是任何网络管理技术的关键要求；

(2).必须明确区分配置数据、描述操作状态的数据和统计数据；

(3).需要能够从设备中提取单独的配置数据、操作状态数据和统计数据，并能够在设备之间进行比较；

(4).必须使操作员能够集中于整个网络的配置，而不是逐个设备配置；

(5).支持在多个设备上配置事务，以简化网络配置管理；

(6).假定需要进行配置 a和配置 b，应该能够生成从a到b所需的操作，以便使得状态变化对网络系统产生最小的影响。将配置更改所造成的影响降到最低是很重要的；

(7).备份和恢复配置的机制是操作人员需要的原始操作；

(8).为了在两个配置之间确定变化以及这些配置是否一致，必须很容易地对配置进行一致性检查；

(9).基于文本的配置，如差异化和版本管理工具，如RCS或CVS，可以用来处理配置，这意味着设备不应任意重新排序数据，如访问控制列表；

(10).网络范围的配置通常存储在中央主数据库中，并转换成可被推送到设备的格式，通过生成CLI命令序列或将完整的配置文件推送到设备上。没有共同的数据库模式……尽管各种操作符使用的模型可能非常相似；

(11).区分配置的分布和特定配置的激活是很重要的，设备应该能够容纳多种配置； (12).基于角色的访问控制模型和最小权限原则，其中只能为用户提供执行所需任务所需的最小访问权限；

(13).可以跨设备对访问控制列表进行一致性检查；

(14).SNMP访问控制是面向数据的，而CLI访问控制通常是面向命令（任务）的。 因此，需要支持面向数据和面向任务的访问控制。

2. 标准的制定

为解决上述的问题，历经多年的讨论，最终产生了一系列的标准：

(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月，RFC6241定义NETCONF的安装，操作和删除网络设备配置的机制。RFC6242更新了基于 SSH 的传输模式。NETCONF 协议是完全基于XML 之上的，所有的配置数据和协议消息都用XML 表示。

(7).2011年，RFC6244 使用NETCONF和YANG的网络管理构架。

总的来说，我们重点关注如下几标准：

① RFC6241定义NETCONF的安装，操作和删除网络设备配置的机制。

②RFC6242更新了基于 SSH 的传输模式。NETCONF 协议是完全基于XML 之上的，所有的配置数据和协议消息都用XML 表示。

③RFC6020指出，YANG是一种数据模型语言(Data Modeling Language)，用来描述NETCONF相关的网络配置和网络状态的数据模型、RPC和Notification。

3. NETCONF基础知识

NETCONF协议是网络设备配置的标准协议，用来进行网络设备的配置管理、下发、更改等问题。它划分为4层：安全传输层、消息层、操作层和内容层。如下图所示：

其中，传输层规定传输层必须使用TLS、SSH等带有安全加密的通信协议，其中SSH是当前应用最多的传输层协议；消息层提供 RPC 接口，用于实现远程调用和通知；操作层定义了 edit-config、get-config、delete-config 和 copy-config 等9种操作，用户也可以自定义RPC操作；内容层描述了配置数据和通知数据，但没有标准化数据结构模型，该模型由RFC 6020：YANG建模。YANG的信息存储在NETCONF协议的3个标准概念配置数据库，如下表所示：

类型	说明
Running： 运行配置库	目前在设备上运行的生效配置
Candidate：备份配置库	任何改变都不会马上直接影响网络设备
startup初始配置库	网络设备启动时所加载的配置库

①Client端发起hello消息到Server端并告知对NETCONF的支持能力；

②Server端发起hello消息到Client端并告知对NETCONF的支持能力，完成能力协

商；

③Client端发起rpc请求消息到Server端，进行设备的配置请求；

元素封装了从客户端到服务器端的协议操作请求。

④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配置信息的开发较为简单，即在代码编写“拼接XML字符串，调用rpc接口”的逻辑就可以了，感兴趣的人员可以参考：

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

4.YANG

NETCONF是网络管理协议，分为安全传输层、消息层、操作层和内容层等4层，而YANG是和NETCONF相伴而生的，可以对操作层和内容层进行建模。但为什么要用YANG呢？我们知道SNMP在请求端使用BER对操作请求和应答进行编码，并在接收端使用BER进行解码。就BER编码（Basic Encoding Rule）来说，其过程是将数据分成TLV三部分并按照TLV的顺序对数据进行编码，生成字节流（T-Tag-类型标识，L-Length-类型的长度，V-Value-数据内容）。在这种情况下，每个字段出现的顺序是预先约定的，其类型和长度是固定的，如果要在新增字段，则意味着协议两端的编解码都要进行修改。而如果将本部分内容通过一个文件来描述或者建模，协议两端根据该文件进行编解码，则与具体的字段解耦了。所以，YANG建模语言就适时而生了（RFC6020：https://tools.ietf.org/html/rfc6020#page-11）。

现在脑补一个场景：需要配置数百上千台设备，并且这些设备来自不同的厂商，那如何实现自动化配置呢？DevOps人员只需做如下步骤：

①构建自动化配置基础应用程序；

②加载厂商设备的YANG文件；

③使用代码生成工具将YANG文件转化为公共代码模板；

④根据业务场景编写RPC和数据逻辑代码；

⑤不同厂商重复步骤；

⑥部署自动化配置基础应用程序。

经过这些步骤后，你需要做的就是“一键”下发配置，成百上千台设备配置就搞定了。

5. NETCONF在SDN中的应用

在现有的网络中，NETCONF和YANG已有了较好的实践。就软件定义网络而言，从OpenDaylight的架构图中，我们可以看到NETCONF即能做北向接口也能做南向接口。同时，不同厂商的控制器也支持NETCONF作为其接口协议。NETCONF作为出色的网络管理协议，将继续发挥其优异的网络配置作用。