数据中心互换机实现运维自动化，零配置上线技术（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的逐步落地，数据中心自动化运维技术将迎来新一波海潮。

iSlot官方网站网络的数据中心互换机产品，蕴含RG-N18000-X系列主题互换机、RG-S6510系列25G TOR、RG-S6220-H系列万兆TOR都已支持NETCONF和OpenConfig YANG。2018年上半年颁布的OpenConfig YANG模型也已全数实现适配，目前在共同国内公有云提供商进行测试。

本期作者：刘臣平

iSlot官方网站网络互联网系统部行业征询

往期杰出回首  

• 【第一期】浅谈物联网技术之通讯和谈的纷争
• 【第二期】若何通过网络遥测（Network Telemetry）技术实现精密化网络运维？
• 【第三期】畅谈数据中心网络运维自动化
• 【第四期】基于Rogue AP反造的无线安全技术探求
• 【第五期】流量可视化之ERSPAN的前世今生
• 【第六期】若何实现数据中心网络架构“去”堆叠
• 【第七期】运维可视化之INT职能详解
• 【第八期】浅析RDMA网络下MMU水线设置
• 【第九期】第七代无线技术802.11ax详解
• 【第十期】数据中心自动化运维技术索求之互换机零配置上线
• 【第十一期】 浅谈数据中心100G光？
• 【第十二期】数据中心网络等价多蹊径（ECMP）技术利用钻研
• 【第十三期】若何为RDMA构建无损网络
• 【第十四期】基于EVPN的散布式VXLAN实现规划

有关推荐：

• 畅谈数据中心网络运维自动化

• 运维可视化之INT职能详解

• 数据中心自动化运维技术索求之互换机零配置上线