技术盛宴 | 数据中心自动化运维技术探索之NETCONF
|
操作层 操作层是承载在消息层上的具体操作内容，这些具体操作仅能承载在<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项与配置直接相关，包括
还剩余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具备以下优势：
NETCONF问题 NETCONF协议因其良好的易用性和扩展性，已经随着SDN技术的逐步落地得到了越来越广泛的使用，主流设备厂商设备均可以支持NETCONF功能。 但是这样是否就完美解决了网管运维面临的问题呢？答案显然是否定的。原因在于：
为了解决这些现实问题，业界的设备使用者们推出了另外一种标准化方案。 OpenConfig （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
