技术盛宴|数据中心自动化运维技术探索之NETCONF

数据中心交换机实现运维自动化，零配置上线技术（ZAM）只是完成了交换机预先可知的固定配置，主要是一些基本的互通以及登录相关配置。未来的业务是变化的，所以具体的与业务相关的配置还需要根据具体需求配置或更新。NETCONF（Network Configuration Protocols，网络配置协议）协议提供了业务配置部署自动化的解决方案。

那么NETCONF是如何出现的？为什么需要开发NETCONF？NETCONF能干什么？发展趋势又是怎样的？本文将针对以上几个问题，对数据中心运维自动化技术进行一些介绍和探讨。

SNMP的问题

要谈NETCONF，SNMP是无法绕过去的。SNMP（Simple Network Management Protocol ，简单网络管理协议）最早由IETF在20世纪80年代晚期（1980s）开发，自诞生之日起，SNMP就被用来监控（如告警、性能管理）网络设备，大多数专业的网络设备都有SNMP agent代理，这些代理被激活和配置后用于和SNMP管理NMS（Network Management System，网络管理系统）通信。

一套完整的SNMP系统主要包括管理信息库（MIB）、管理信息结构（SMI）及SNMP报文协议。

MIB

MIB，管理信息库，汇总存储着资源与OID的唯一对应关系，NMS根据查询的资源在MIB中找到对应的OID，通过SNMP查询报文将读取的OID信息发送至网络设备，网络设备根据OID查询对应的资源信息，最终封装为SNMP响应报文发送给NMS。

如图一所示，查询资源iso.org.dod.internet.mgmt.mib.ip.ipInReceives对应的OID即为：1.3.6.1.2.1.4.3。

图一 ：MIB树形层次结构

SMI

SMI，管理信息结构，是SNMP中定义被管理的网络实体（即网络设备）中特定数据的语言。定义了数据类型、对象模型，以及写入和修改管理信息的规则等内容。

SNMP报文

SNMP规定了5种协议数据单元PDU（SNMP报文），用来在管理进程和代理之间的信息交换。

如图二所示：

• get-request，用于从代理进程处提取一个或多个参数值；
• get-next-request，用于从代理进程处提取紧跟当前参数值的下一个参数值；
• set-request，用于设置代理进程的一个或多个参数值；
• get-response，用于代理向管理进程返回的一个或多个参数值；
• trap，代理进程主动发出的报文，通知管理进程有某些事件发生。

图二：SNMP五种报文操作

从SNMP协议设计中可以看出，尽管具有一些配置的功能，但SNMP本身并不是面向配置的协议，也不适合开发用于配置的客户端应用。大量的运维实践也证明，SNMP更多是作为网络设备状态监控的工具，而在配置管理层面，SNMP还不具备成为一个成熟 工具 的能力。

而且即便在网络设备监控层面，SNMP也还存在着其他的问题，比如：

• 性能差，效率低；
• 基于UDP协议传输，可靠性较差，只能依靠本身机制保证可靠性，影响性能；
• 私有MIB导致多厂家设备统一管理难度大。

正是由于SNMP的各种不足和缺陷，才导致了NETCONF的产生。

NETCONF的由来

在2001、2002年，IAB（Internet Architecture Board，互联网架构委员会），组织了几次关于网络管理的专题工作会议，将网管以及协议开发者组织起来针对当时的主流网管协议（SNMP、CLI等）存在的问题进行了讨论，会议结果最终形成了RFC 3535。在这份文档中，针对当时网络管理中存在的问题，提出了14项需求，其中最关键的几项有：

• 易用性；
• 明确区分配置数据、描述操作状态的数据和统计数据；
• 面向服务和网络的配置管理，而不是单个设备的管理；
• 配置数据的导入导出脱离原始人员操作；
• 基于文本进行配置；
• 标准化数据模型等等。

针对RFC 3535中罗列的需求，2003年成立了NETCONF工作组，NETCONF的设计遵循RFC 3535。2006年NETCONF核心RFC 4741发布，2011年更新版的RFC 6241发布（废除RFC 4741）。

NETCONF简介

NETCONF协议，顾名思义是安装、编辑和删除网络设备配置的标准协议。从上文NETCONF由来也可看出，NETCONF主要解决的问题之一就是网络设备的配置管理、下发、更改等问题。NETCONF如何来实现对网络设备配置的管理，我们先来看下NETCONF的架构设计。

NETCONF架构

NETCONF使用C/S结构，面向连接，协议报文使用XML格式。

图三：NETCONF 协议架构

从图三中可以看出NETCONF协议内部分为4层，由下至上分别是安全传输层，消息层，操作层和内容层。

安全传输层

NETCONF所具备的一大优势在于从协议层面就规定其传输层必须使用带有安全加密的通信协议，如SSH，TLS等。对比其他明文传输协议，NETCONF协议层面就对数据安全性做了保障。由于NETCONF协议规定必须要支持SSH，所以目前SSH是NETCONF使用最广泛的传输层协议。

消息层

消息层提供了一种简单的、不依赖于传输协议的RPC和通告封装机制。

client采用<rpc>元素封装操作请求信息，并通过一个安全的、面向连接的会话将请求发送给服务器，而服务器将采用<rpc-reply>元素封装RPC请求的响应信息（即操作层和内容层的内容），然后将此响应信息发送给请求者。另外，服务器可以采用<notification>元素向客户端通告事件。

操作层

操作层是承载在消息层上的具体操作内容，这些具体操作仅能承载在<rpc>和<rpc-reply>消息上，<notification>消息无操作层内容。

NETCONF协议规定了9种简单的RPC操作，如表一所示：

表一：RPC基本操作

除了以上9种基本操作，NETCONF也支持用户自定义RPC操作，这里不做展开描述。

内容层

内容层主要用来描述网络管理所涉及的配置数据和通知数据等。但是NETCONF并没有对于内容层的数据结构模型做标准化定义，那如何来描述内容层的相关数据呢，2006年，在NETCONF首个版本RFC 4741发布的同时，一种专门为NETCONF准备的数据建模语言YANG（RFC 6020）也同时发布。目标是对NETCONF数据模型、操作进行建模，覆盖NETCONF协议的操作层和内容层。

下图即是一个NETCONF的RPC报文中各层内容的示意。

图四：NETCONF RPC报文示例

NECONF操作

那在这个架构下NETCONF到底是如何实现设备配置管理的？

我们来看一次NETCONF交互的流程 ：

图五：NETCONF交互流程示意

在Client和Server建立NETCONF会话后，两端先通过<hello>报文互相通知对端本端对于NETCONF的支持能力，即Capability。同步完成后Client端发起RPC操作，Server端运行后将应答消息封装入<rpc-reply>回复给Client端。对于设备配置，就是在Client端发起RPC配置相关的操作。

NETCONF定义的9项基本RPC操作中有4项与配置直接相关，包括

• <get-config>；
• <edit-config>；
• <copy-config>；
• <delete-config>。

还剩余2项与配置权限相关，2项会话关闭和1项状态数据查询。从这里也能看出NETCONF对于配置管理的重视。

可是这些好像还是没法体现NETCONF比SNMP好在哪？SNMP存在的问题如何解决的？

这里不得不引出NETCONF中另外一个重要的组成部分YANG。

YANG

YANG（Yet Another Next Generation），无法用中文给出恰当的翻译。从YANG的标准文档RFC 6020中，我们可以明确它的定位： A Data Modeling Language for the Network Configuration Protocol （NETCONF），NETCONF的数据建模语言。

为什么要YANG

NETCONF需要对设备的配置（configuration）和状态（state）做操作，例如编辑配置，获取状态，而NETCONF的内容层并没有定义标准化的数据模型。同时操作层除了定义9种基本的RPC操作，还允许自定义RPC，自定义的RPC和具体操作内容都需要进行建模，YANG就是用来完成这个建模的。

YANG使用modules和submodule进行数据建模。一个YANG module，如图六所示，定义了具有垂直结构的数据，这些数据可以被用做基于NETCONF的操作，包括配置、状态数据的描述，还有RPC操作等。它使得NETCONF的Client和Server之间能有完整的数据描述。

图六：YANG module举例

怎么用YANG

YANG建模得到的数据具备树形结构。其中每一个节点都有一个名字，都有一个值或者一些子节点。YANG文件为这些节点，以及节点之间的交互提供明确清晰的描述，即数据模型路径。

网络设备对于NETCONF的支持，就是在设备注册YANG的数据模型路径，使设备能够根据YANG文件的数据模型路径获取数据或者写入配置。

那么对于运维人员来说只需拿到设备厂商的YANG模型，根据YANG模型的要求将相关的配置或数据参数填入，即可通过NETCONF发起相关RPC操作，完成配置或数据读取任务。

通过YANG和NETCONF，就实现了基于可编程技术的网络配置和管理，为自动化运维提供了基础。

NETCONF与SNMP对比

介绍完NETCONF，我们再回头看下NETCONG与SNMP的简单对比：

表二：SNMP&NETCONF对比

相比SNMP，NETCONF具备以下优势：

简单易用，YANG模型简单易学，可读性好，且可直接映射到XML；

清晰区分配置数据和状态数据，对于不同数据，存储在不同数据库中，互相区分明确；

可以统一管理整个网络所有设备，而不再是基于单台设备管理；

自动化的配置下发和数据收集，降低人工误操作几率；

标准化数据模型（建模语言）；

扩展性好，除了标准操作，还可以自定义操作，实现独特管理功能；

基于SSH协议，提供配置锁定等机制，数据安全性高。

NETCONF问题

NETCONF协议因其良好的易用性和扩展性，已经随着SDN技术的逐步落地得到了越来越广泛的使用，主流设备厂商设备均可以支持NETCONF功能。

但是这样是否就完美解决了网管运维面临的问题呢？答案显然是否定的。原因在于：

• 各厂商设备支持NETCONF基本都使用私有YANG模型， 不同厂商设备不能识别其他厂商YANG文件；
• 对于使用NETCONF运维平台的使用者，需要学习熟悉各厂商的NETCONF文档和YANG文件；
• NETCONF YANG Model整体的标准化进程十分缓慢。

为了解决这些现实问题，业界的设备使用者们推出了另外一种标准化方案。

OpenConfig

为了屏蔽使用NETCONF时不同厂商设备的差异，由Google发起，AT&T，British Telecom，Facebook， Apple ，Microsoft 等参与成立了 OpenConfig 工作组，希望能创建一个与设备厂商无关的开放模型，用于网络配置和策略。目前国内的腾讯、百度和阿里等公司也已经加入了 OpenConfig 工作组。

OpenConfig标准化

OpenConfig的目的是基于实际案例的操作需求，使用YANG语言编译一组中立的通用数据模型，以最终实现基于可编程技术的网络自动化运维。

OpenConfig具备以下几个主要特征：

• 沿用NETCONF协议框架；
• 使用YANG作为建模语言；
• 不修改底层数据传输，只关注上层的数据表达和数据建模。

也就是说OpenConfig更多的是要成为一个建模的标准。

OpenConfig本身是基于标准化的NETCONF协议框架和建模语言YANG来开发，在YANG Model维度进行标准化，相当对于YANG模型做了规范，需要各厂家设备全部需要能够识别OpenConfig YANG Model的YANG文件，这样，不同厂商的设备就可以通过统一模型的YANG文件来管理，不同的只是YANG文件中填入的参数。

通俗的理解，OC （OpenConfig）YANG就是希望做成一种类似公有的YANG模型，如图七所示。

图七：OC YANG模型

OpenConfig生态情况

目前OpenConfig还不是一个官方标准组织，甚至还不是一个正式的组织，很多的成员还都是通过邮件邀请的。它由Google倡导，Microsoft、AT&T、英国电信等都是它的拥护者，国内BAT均已加入。

图八：OpenConfig生态

OpenConfig目前还没有发布标准RFC，但已经成为NETCONF的下一个发展趋势，各大网络设备厂商都已经开始了OpenConfig的开发工作。

目前，由于在网络管理、配置下发以及开放性等方面的优势，NETCONF基本已经成为实现数据中心运维自动化的主流协议。同时各大网络设备厂商也纷纷将NETCONF加入功能支持列表里。虽然由于私有YANG的问题导致在实际应用中还存在一些问题，但OpenConfig已经为解决这些问题提供了明确可行的思路。随着OpenConfig的逐步落地，数据中心自动化运维技术将迎来新一波浪潮。

锐捷网络的数据中心交换机产品，包括RG-N18000-X系列核心交换机、RG-S6510系列25G TOR、RG-S6220-H系列万兆TOR都已支持NETCONF和OpenConfig YANG。2018年上半年发布的OpenConfig YANG模型也已全部完成适配，目前正在配合国内公有云提供商进行测试。

感谢您关注锐捷网络技术干货文章！现诚邀您参与有奖调研，您宝贵的意见和建议将帮助我们在技术探索与分享上持续精进。

点击下方链接参与调研。

http://survey.ruijie.com.cn/jq/29323915.aspx