NETCONF

法律安全 2019-02-07

展开全文

引子

NETCONF和YANG的目的是以可编程的方式实现网络配置的自动化，从而简化和加快网络设备和服务的部署，为网络运营商和企业用户节约成本。NETCONF和YANG对应的RFC文档分别是RFC6241和RFC6020，而RFC6244描述了一个实现NETCONF/YANG的参考架构。

按照RFC6241的定义，NETCONF是安装、编辑和删除网络设备配置的标准协议。RFC6020指出，YANG是一种数据模型语言(Data Modeling Language)，用来描述NETCONF相关的网络配置和网络状态的数据模型，包括NETCONF支持的RPC(Remote Procedure Call)消息和异步通知(Notification)。请注意，YANG本身不是数据模型，而是定义数据模型的语言。YANG和NETCONF是相伴而生的，虽然，原则上YANG也能够用于其他的协议和不同的领域，但基本上可以认为YANG就是为NETCONF量身定做的。

2002年，IAB(Internet Architecture Board)召集了一次关于网络管理的专题工作会议(Workshop)，最终形成了RFC3535。在这份文档中，针对当时网络管理中存在的问题，提出了14项需求，我们不妨列出其中关键的几项：

简单好用。这何须说？！
严格区分网络可配置的数据和运行时的状态数据。可配置的数据如静态IP地址和VLAN，用来改变设备的行为；状态数据如接收、丢弃、转发的数据包的计数统计，用来监控设备的行为。PicOS的Cli就有Operational模式和Configure模式，分别用于输出系统状态和改变系统配置。
可以将整个网络作为配置的对象，而不仅仅是单独的设备。所谓SDN的集中式管理不就是这样吗？很多SDN的Controller平台如OpenDaylight本身也是基于整个网络视图的开发平台。
支持多个网络设备配置的transaction机制。比如，给定一个网络，利用Dijkstra算法得到两个主机之间的最短路径，将正确路由配置到这一路径上的每个交换设备。若某个交换设备配置失败，那么所有的交换设备都应该恢复到原来状态。这个说起来简单，做起来恐怕并不容易。
网络设备可保留多份配置拷贝，不同配置之间可以自由切换，以适配不同的应用场景。这样，交换机就可以切换到特殊的配置来应对流量高峰期的到来。

另外，更为重要的是，是否支持可编程配置的API不是问题，问题是以怎样的方式来支持。这也是自动化配置的基础。显然，已有的网络管理协议SNMP和上述的需求比较起来就大大的力所不逮了：尽管具有一些配置的功能，但SNMP本身并不是面向配置的协议，也不适合开发用于配置的客户端应用，更谈不到Transaction机制的支持。要满足这些需求，设计新的替代的网络管理协议就不可避免了。于是NETCONF和YANG的1.0版本分别于2006年和2010年正式发布。

总的来说，NETCONF/YANG并不规范配置的内容，支持NETCONF/YANG的设备供应商可保留自己的特有的配置内容，但需要转换成用YANG定义的数据模型。然后，NETCONF通过定义标准的操作接口，必须用统一的方法来安装、编辑、删除配置内容，获取设备运行的状态数据。也就是说，数据内容可以不同，但定义数据(YANG)和操作数据(NETCONF)的方法必须一致统一。

相对来讲，NETCONF和YANG都不是很新的东西。SDN(Software Defined Network)在学术界和工业界的发展和影响赋予了这两项技术老树吐新芽，迎来第二春的机会。大家都知道，SDN不能仅仅停留在抽象的概念层面上，必须找到应用的切入点，并向更广泛的领域逐渐展开，才会具有真正的生命力。目前来看，虚拟网络和自动化配置是SDN应用的两个重要支柱。自动化配置让人们重新发现了NETCONF和YANG的价值。

NETCONF和YANG相互交织缠绕在一起，剪不断，理还乱，很难把它们分开来一一描述清楚。所以本文从自动化网络设备配置的功能为切入点，用实际的用例，来说明NETCONF/YANG是如何相互配合完成这些功能的。

组成和交互

NETCONF的自动化配置系统采用Client/Server架构。Client和Server之间由面向连接的传输协议建立会话。SSH(Secure Shell)是NETCONF强制支持的传输协议，其他的传输协议如TLS和SOAP也能满足NETCONF的要求。Client和Server通信的内容是NETCONF定义的双向的XML格式的RPC(Remote Procedure Call)消息，包括从Client发送到Server的<rpc>请求消息，以及Server的响应消息<rpc-reply>。这样，Client就可以获取并修改Server的配置数据(configuration datastore)。

下图描述了NETCONF配置系统的结构。NETCONF Server是要配置的网络设备，除了硬件之外，NETCONF引擎是和NETCONF Client建立会话的软件模块，当然，Server上面还会运行自身设备的软件系统。配置数据由NETCONF引擎维护并传递给Server的软件系统，最终应用到硬件的芯片。正如上文所述，配置数据的语法结构是用YANG语言定义的数据模型来描述的，包括数据类型和数据结构。这和XML的Schema与对应的应用域数据的关系完全类似。YANG分层的树状结构非常适用于网络设备的配置数据的定义。YANG的另外一个优点是没有晦涩的内容，简单易懂。用户拿到YANG的数据模型文件，即可明白如何写NETCONF Client程序来配置网络设备。YANG语言的数据模型可以无信息丢失的转换为XML的格式，称为YIN(YANG Independent Notation)，主要是为了利用随手可得的标准的XML解析器。开源的NETCONF工具库libnetconf提供了转换的工具lnctool。NETCONF引擎和Client程序用YIN检查配置数据的合法性。下文将用一个简单的例子来说明YANG是如何定义配置数据的数据模型。

一般地，Client和Server经过如下的步骤来完成配置的获取和改变：

Client和Server建立面向连接的传输协议的会话；
通过Hello消息协商彼此支持的功能(Capability)，如都支持的NETCONF的最高级版本，从而避免解析时的歧义；
Client向Server发送<rpc>的请求；
Server接收并解析<rpc>请求；
通过YANG数据模型的定义来验证RPC请求的合法性；
执行RPC的请求；
执行结果作为<rpc-reply>响应消息返回给Client；
Client接收并解析响应消息。

由此可见，用户能够以任何编程语言实现远端网络设备的定制化配置的需求，所做的无非是与Server建立会话连接，封装发送<rpc>请求消息，接收解析<rpc-reply>消息。重要的是，用户可以通过这种简单的交互模式，实现自己的业务逻辑，比如，可根据网络的负载和设备的状态，应用不同的配置。这也许就是可编程的自动化配置的内涵，也是YANG和NETCONF设计的目标。

模型和数据

METCONF Server上面的配置叫做配置存储。配置存储是设备完整的合法的一份配置数据拷贝，使能某个配置存储可以把设备从缺省的初始状态转换到特定的运行状态。在同一个设备上，NETCONF可支持三种配置存储,包括：

运行时配置(running configuration datastore)是设备当前激活状态的运行中的配置，和运行的状态完全一致。
重启时配置(startup configuration datastore)是系统下次重启时的配置，可以和运行时配置不一样。
可选配置(candidate configuration datastore)是没有生效的候选配置，可使用commit命令将可选配置应用到设备，从而，可选配置变为当前的运行时配置。

无论是运行时配置，重启时配置还是可选配置的数据，都是用YANG定义的数据模型来描述的。下面给出一个关于网络设备接口的极度简化的例子。

YANG语言是非常直观的模型语言，理解了上面代码中YANG语言的一些关键词，如module，container，list，leaf等，就基本可以清楚的知道代码的含义了。解释如下：

module定义了一种分层的配置树结构，一个module是自包含的(self-contained)，可重用的。它可以使能NETCONF的所有功能，如配置操作(operation)，RPC和异步通知(notification)。开发者可根据配置数据的语义来定义不同的module。❶
namespace用于唯一的标识module，等同于xml文件中的namespace。❷
container节点把相关的子节点组织在一起。❸
list节点可以有多个实例，每个实例都有一个key唯一标识。❹❺
leaf是叶子节点，具有数据类型和值，如叶子结点name的数据类型(type)是string，它唯一的表示list节点interface。❻❼
另一个布尔类型的叶子节点，缺省值是true。❽❾

配置和操作

上文已说明，NETCONF Client和NETCONF Server通过RPC交互完成网络设备的配置。下面给一个具体的例子，NETCONF Client向NETCONF Server发送一个xml编码的<rpc>请求❶，在Server的运行时配置❷上通过操作(operation)create新建一个网络接口❸。

如果操作成功，NETCONF Server将返回<rpc-reply>。