一文秒懂cli、snmp、yang、netconf、restconf、openconfig

前言

自以太网诞生以来，各种技术引领着一代代的潮流。星辰闪耀，数不尽的网络承载着各种通信的可能，让我们也不禁感慨网络之浩瀚。

前有“云大物移智链边”的风起云涌，后有AI浪潮的大放异彩。上层应用的遍地开花，也迫使着底层网络技术的不断发展。SD-WAN、P4、QUIC、SRV6、SNOIC等一堆和网络相关的技术也应运而生。

无论以上种种技术如何的变迁，最终信息的传递还是基础硬件扛下了所有。尽管这些年来也有高性能硬件也在不断诞生，
如多年前处理网络数据包速度达到6.5Tb/s的Tofino芯片犹如破竹之势，与传统交换机相比可谓是以一抵百，然而硬件的变革不像软件一般疾风骤雨说换就换，迁移成本、兼容性等都不是能一蹴而就的。为了一解燃眉之急，只好使出必杀技：质量不够，数量来凑。

随着设备数量的增加，也给运维管理人员带来了更大的挑战。如何对如此众多的设备进行统一的管理也成为了一个的思考方向。

本文将以笔者的个人观点，总结下从cli到snmp、netconf、restconf、openconfig这些网络管理技术的特点与应用场景。

cli

从祖师爷CLI开始，人们便开始探索着如何通过命令行界面来掌控网络的命运。
telnet带内(管理)，cosole带外(管理)，飘逸又自在。

特点：简单方便，功能完备，一本参考手册可走天下。

如果仅需管理几台设备用cli方式完全足够，酷酷的控制台界面，不能再拉风。

命令基本靠手敲，是否敲错全靠人眼判别。

这种模式下，一旦所需要管理的设备多起来还用cli来管理，疯是早晚的事儿。

为此有人想到了自动化编程来解决：什么Paramiko、jsch哪种语言熟练用哪个。

看似能解决繁琐和批量管理的问题，但也让人想到了一些缺点：

• 不同型号的设备命令不同，还得靠背，兼容性差
• 没有规范的协议标准，自动化方式效率低
• 缺乏模块化与事务机制，配置一个功能由多个命令组成，容易出现部分命令成功的情况，可靠性差
• 监控功能匮乏，尽管通过CLI提供的命令能输出状态信息但解析为自动化成本则较高，无标准的监控机制
  ……

SNMP

前面讲到cli实现自动化有诸多不便，“饭得一口一口吃，事得一件一件办”。于是，横扫网络监控数十载的SNMP便就此诞生了。

Simple Network Management Protocol (SNMP)，简单网络管理协议。

SNMP协议也算是一个发展历史较长的协议，诞生于上世纪80年代初，主要为解决网络设备的监控与管理诞生，它最重要特点就是：simple，简单。

发展至今SNMP有了3个版本，主要特点如下表：

简单来讲，SNMP基于C/S架构，网络设备作为SNMP代理，向网络管理系统提供各种管理信息，管理系统则通过SNMP协议进行查询和配置。

SNMP中主要涉及到以下组件：

• NMS，网络管理系统
• Agent，代理进程，被管理设备中的代理进程，向NMS上报数据
• Managed Object，被管对象/设备
• MIB，管理信息库，被管理设备维护的变量的数据库。设备与网管需持有相同的MIB，以确保采集指标一致。

另一个重点为：SNMP交互过程主要采用一问一答的pull机制，数据包使用UDP进行传输，NMS(网管)端监听162端口，Agent(被采集者)监听161端口。

Agent也可使用Trap或Inform主动向NMS上报消息，多用于告警场景。Trap与Inform区别在于Inform需要NMS回复确认消息。

整体来看SNMP非常符合它的名字——SIMPLE。也正因为简单，在当前网络大时代SNMP存在以下缺点：

• 消息传递使用UDP传递，缺乏可靠性
• 监控功能基于pull机制，且必须一对一通信，监控大量设备时Server端占用资源大
• SET功能缺乏事务性，加上UDP传输，多个SET容易部分成功部分失败
• 监控周期一般为分钟级，微突发场景的数据无发采集到，毛刺数据丢失(不满足《奈圭斯特采样定理》)，数据完整性不佳

当然SNMP并非无用武之地，毕竟它是SIMPLE NMP，如仅需采集些数据做做展示，用它绝对是不二之选。搞个prometheus的snmp_exporter，再搭配个grafana的界面，实现个XXX监控系统分分钟的事儿（天下武功，唯快不破）。

该有的数据都有，界面要多炫酷有多炫酷，有没有？没准这也是SNMP经久不衰的秘诀之一。

MIB

在SNMP中组件有好几个，这里单独对MIB简单介绍下。
MIB是Management Information Base的缩写，即：管理信息库。
也可以简单理解为：MIB是对象与ID映射关系库。

在MIB中定义了被管理设备所维护的变量，如：对象的名称、对象的状态、对象的访问权限和对象的数据类型等。

MIB为树型结构，每个对象标识符OID（object identifier）对应于树中的一个管理对象，该树的每个分支都有一个数字和一个名称，并且每个点都以从该树的顶部到该点的完整路径命名，如上图mgmt的OID为1.3.6.1.2。

支持SNMP的每个设备都有一个自己的MIB，可以是公有的也可以是私有的，一般设备厂商采用公有+私有方式，私有MIB算是公有MIB的必要补充。

当使用SNMP查询设备的某个信息时，需要先找到对应的设备信息的MIB拿到OID值。

以要查询华为S7700设备的CPU信息为例，找到对应的产品手册MIB文档，获取出OID，再使用Agent传入OID参数查询即可。

Telemetry(广义)

前面提到SNMP在监控场景存在着一些不存，有耿直的小伙这里可能表示不服了：既然SNMP不行，那有解决办法么？

于是乎《RFC 9232》便被提出来了——Network Telemetry Framework。它算是对一个广义的网络监控框架的描述，其中构思了理想的框架。

可以认为：在广义的Telemetry中，一个监控系统应由网络设备、采集器、分析器和控制器等部件组成。

控制器向设备发送订阅消息请求订阅某项监控数据，随后设备将被监控数据使用推模式向采集器进行持续上送，数据推送周期由采集器自行控制，监控周期可实现亚秒级监控。

RFC 9232中提出的Telemetry没有阐述具体的实现，一般也认为它是广义的Telemetry，狭义的Telemetry可查看后文OpenConfig中Stream Telemetry章节。

yang

《周易》有言：“易有太极，是生两仪。两仪生四象，四象生八卦”。
从微观到宏观，从物质到精神，世间万物都被认为是太极的表现形式。站在一个更高阶的抽象，仿佛它就是宇宙的万象之源。

没错，接下来介绍本文的一个重点——yang。

前文多次提到，无论是cli还是snmp都只能对一个对象单独配置，而不是面向一个业务。不支持事务，可读性差等问题纷来沓至。

为了解决以上问题并应对现代网络环境中日益增长的配置管理需求，IETF亲自出手提出了YANG（Yet Another Next Generation）作为描述网络配置数据的建模语言。其对应的RFC链接为：https://datatracker.ietf.org/doc/html/rfc6020

YANG官方定义为：YANG是一种数据建模语言。YANG模型定义了数据的层次化结构，可用于基于网络配置管理协议（例如NETCONF/RESTCONF）的操作，包括配置、状态数据、远程过程调用和通知。YANG相对于SNMP的模型MIB，更有层次化，能够区分配置和状态，可扩展性强。

简单来讲，YANG站在一个更高的维度，提供了一种高屋建瓴的思想来指导配置或监控的数据落地的方式。如数据库表中的DDL，提供出定义和约束。也可以与SNMP中的提到的MIB进行类比，MIB中将一个个具体的指标进行定义，属于最小单元，YANG则将这些最小单元进行组装形成一个模型。

与MIB同样的，在管理者与被管理者间都有一份相同的YANG模型，具体数据发送时发送方携带YANG模型标识及数据实体形成一个整体进行发送，发送方式并不进行约束，SSH、HTTP、gRPC啥都行。

如作为网络配置人员需对某一设备进行配置，仅需要拿到对应设备的YANG文件按照它的定义向设备下发配置即可。

如作为开发人员则可能需要编写YANG文件，YANG文件的语法需要符合它的语法规则，这部分网上的资料也很多，如果是大佬也可直接查看对应RFC文档。
https://datatracker.ietf.org/doc/html/rfc7950

快速入门的话看华为的资料也不错，链接为：YANG API参考

在yang的github中也整理了些关于其他硬件厂商的yang模型，感兴趣者可进一步查看
https://github.com/YangModels/yang/tree/main/vendor

NETCONF

如前所述，YANG模型的上层一般由NETCONF、RESTCONF、OPENCONFIG/gRPC来进行调用。这里根据各自诞生的时间顺序依次来看一下。

最先出场的是NETCONF（Network Configuration Protocol）其诞生时间也最久，由IETF于2003年成立。在当时那个XML蔚然成风的年代，NETCONF协议也选择使用XML作为传输载体，以SSH协议进行通信。

交互过程如上图所示。每次NETCONF CLIENT与NETCONF SERVER进行交互前也需要进行握手，各自发送HELLO包并完成支持能力的协商，之后便可以发送RPC包进行正真的交互了。

以某个修改设备的某个配置为例，其封装的XML内容如下：

NETCONF中除了支持配置外，也支持订阅告警功能。

使用的是netconf中的Notification能力，Notification支持向客户端上报告警和事件，以便客户端及时感知设备配置等的变更。

经过多年的发展，各设备厂商也几乎NETCONF协议进行了适配。

github上也逐步涌现出了一些关于netconf的框架，比较知名的有netopeer2，使用C语言实现了NETCONF-SERVER端。ncclient，使用PYTHON实现了NETCONF-CLEINT端。JAVA方面比较成熟则有OPENDAYLIGHT中的NETCONFIG模块，NETCONF的SERVER端与CLIENT端均有实现。

RESTCONF

随着网络规模、复杂度、自动化运维的需求增大，以及WEB技术的高速发展，当前网络管理者希望设备能够提供支持Web应用访问和操作网络设备的标准化接口，NETCONF已无法满足网络发展中对设备编程接口提出的新要求，于是2017年融合了NETCONF和HTTP协议RESTCONF悄然诞生，为用户提供高效开发Web化运维工具的能力。

RESTCONF与NETCONF比较

项目	NETCONF+YANG	RESTCONF+YANG
传输通道（协议）	NETCONF传输层首选推荐SSH（Secure Shell）协议，XML信息通过SSH协议承载。	RESTCONF是基于HTTP协议访问设备资源。RESTCONF提供的编程接口符合IT业界流行的RESTful风格。
报文格式	采用XML编码。	采用XML或JSON编码。
操作特点	NETCONF的操作复杂，例如： * NETCONF支持增、删、改、查，支持多个配置数据库，也支持回滚 。 * NETCONF需要两阶段提交（即先提交参数，再commit参数）。	RESTCONF的操作简单，例如： * RESTCONF支持增、删、改、查操作，仅支持<running/>配置数据库。 * RESTCONF操作方法无需两阶段提交，操作直接生效。

与NETCONF相比，RESTCONF涵盖有NETCONF的所有功能，其支持JSON编码的特点让数据的可视化进行了增强，也大大减少了运维管理的开发周期。

RESTCONF操作方法与NETCONF协议方法

RESTCONF+YANG	NETCONF+YANG
OPTIONS	N/A
HEAD	<get-config>,<get>
GET	<get-config>,<get>
POST	<edit-config> (nc:operation=“create”)
POST	调用RPC操作
PATCH	当操作对象已存在时，<edit-config> (nc:operation=“merge”)
DELETE	<edit-config> (nc:operation=“delete”)

RESTCONF目前落地方面也还不错，很多厂商的设备都对其进行了支持。

更多RESTCONF的资料也可查看此链接：RESTCONF介绍

OPENCONFIG

现在的你是否还记《笑傲江湖》中有过这样一句话：“有人的地方就会有江湖。”

我想，这句话搬到网络行业中同样适用，不同的网络设备厂商有着各自不同的规范与命令，从SNMP的MIB到YANG的模型，厂商与厂商之间，设备与设备之间均不能通用，仿佛一个个的江湖。

普遍来看不同厂商有着各自的特色也没有什么不好，总比全一模一样被告抄袭好很多。不过有个问题是比较明显的，给要管理众多设备的软件厂商带来了许多适配工作，终于有一天几位软件老大哥提出了构想：“大道之行也，天下为公，要不咱们哥几个给制定个规范，让所有的配置和监控模型全给统一一下？”，大哥们的执行能力也很强，想着：“反正自己又不是设备厂商对自己也没啥影响”，说干就干，于是由Google、Facebook、Microsoft、AT&T等公司牵头的OpenConfig便诞生了。

OpenConfig标语中写着一句话：“Vendor-neutral, model-driven network management designed by users”，由用户设计的与厂商无关模型驱动的网络管理。

OpenConfig的目标是希望成为一个与设备无关的建模标准，具有以下特点：

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

在OpenConfig的主页中也用4个图例概括了OpenConfig的主要功能：

分别有：

• Common data models，通用数据模型
• Streaming telemetry，流式数据遥测
• Management protocols，管理协议
• Testing and compliance，测试与合规

仔细一品，仿佛理想被照进了现实，一切都是那样的美好。接下来一起简单学习下。

Data models

在Common data models部分，OpenConfig旨在使用通用的数据模型来管理网络中的各种设备。

模型描述语言仍使用的是YANG，已发布的模型在OpenConfig的github中也可能看到对常用的协议进行了全覆盖。其已发布模型链接地址为：
https://github.com/openconfig/public/tree/master/release

查看某些主流设备厂商的主页，OpenConfig也能在部分产品中找到对OpenConfig模型进行了部分的适配

除了硬件设备厂商外，部分软件交换机也进行了部分的适配，如在SONIC的github中也可看到OpenConfig的身影

初步来看效果也还不错。

Streaming telemetry

在前文介绍SNMP的时候提到了广义的telemetry技术，而满足telemetry要求的狭义telemetry技术的则为这里的Streaming telemetry。
同时Streaming telemetry也是OpenConfig各大模块中落地最多的模块，现几乎所有的大型硬件厂商都对Streaming telemetry提供了支持。

Streaming telemetry的出现让设备监控发展到另一个新的高度。

Streaming telemetry下的数据监控/遥测过程大致为：采集控制器与被采集设备使用GRPC进行通信完成数据的订阅，采集设备再使用GRPC方式持续向采集器进行数据的推送，数据使用gpb进行封装也具有良好的性能。

工程应用时，如需使用Streaming telemetry实现可直接查看对应设备的介绍文档，各大设备厂商几乎都有对它的介绍。

再提一点：为什么grpc比netconf、restconf性能高，可直接看如下图：

同样的内容如果用netconf传输，使用的是xml进行传输其字节大大小会比GPB大上很多，性能也便是不言而喻。

gNMI

文章最后再看下gNMI是何方神圣。

gNMI是gRPC Network Management Interface的简写，是一套基于gRPC的标准化网络管理接口。

接口内容可从gNMI的github仓库中找到，gnmi.proto的service内容如下：

service gNMI {
  // Capabilities allows the client to retrieve the set of capabilities that
  // is supported by the target. This allows the target to validate the
  // service version that is implemented and retrieve the set of models that
  // the target supports. The models can then be specified in subsequent RPCs
  // to restrict the set of data that is utilized.
  // Reference: gNMI Specification Section 3.2
  rpc Capabilities(CapabilityRequest) returns (CapabilityResponse);
  // Retrieve a snapshot of data from the target. A Get RPC requests that the
  // target snapshots a subset of the data tree as specified by the paths
  // included in the message and serializes this to be returned to the
  // client using the specified encoding.
  // Reference: gNMI Specification Section 3.3
  rpc Get(GetRequest) returns (GetResponse);
  // Set allows the client to modify the state of data on the target. The
  // paths to modified along with the new values that the client wishes
  // to set the value to.
  // Reference: gNMI Specification Section 3.4
  rpc Set(SetRequest) returns (SetResponse);
  // Subscribe allows a client to request the target to send it values
  // of particular paths within the data tree. These values may be streamed
  // at a particular cadence (STREAM), sent one off on a long-lived channel
  // (POLL), or sent as a one-off retrieval (ONCE).
  // Reference: gNMI Specification Section 3.5
  rpc Subscribe(stream SubscribeRequest) returns (stream SubscribeResponse);
}

以上便是gNMI的全部，仅有4个方法。分别为：

• Capabilities
• Get
• Set
• Subscribe

既然gNMI是接口，熟悉面向对象编程的同学一定知道，接口必定有实现。

那么gNMI的实现在哪里呢？

以上图为例，展示了gNMI的实现交换总览图。
简单来讲：gNMI作为grpc的接口，实现时由调用者和提供者两部分构成，以Streaming telemetry遥测场景为例，则监控管理平台为client端，被监控设备上的系统为server端，client与server端都为gNMI接口的实现。

再以sonic的官方配置文档为例，一起看下：

gNMI Collector与gNMI Server都为gNMI的实现者，一方为调用方，一方为被调用方。
上图中使用到了gNMI中的两种模式Dial-in与Dial-out。

• Dial-in模式：设备作为gRPC服务器，采集器作为gRPC客户端。由采集器主动向设备发起gRPC连接并订阅需要采集的数据信息。
• Dial-out模式：设备作为gRPC客户端，采集器作为gRPC服务器。设备主动和采集器建立gRPC连接，将设备上配置的订阅数据推送给采集器。

JAVA方面著名的SDN开源项目onos中的开(放)光(传输)项目odtn(Open Disaggregated Transport Network)应用也使用到了OpenConfig，ODTN应用架构图如下：

如想快速体验下OpenConfig可直接使用google官方的gnxi，容器和源码在github中都能找到，值得体验。

更多详尽内容可移步openConfig的官方gNMI介绍查看：https://www.openconfig.net/docs/gnmi/gnmi-specification

快速也入门gNMI也可查看此文《网络编程和自动化基础-gNMI》

---

总结

以上，总结了cli、snmp、netconf、restconf、opencofig这些配置与遥测技术的知识与特点，总体来说各有各的优劣。如果您恰巧面临着配置技术的选型希望此文对您有帮助，如果您问我哪个最好？我的答案是：“技术选型就像买新鞋，只有都亲自看看试试才知道。没有最好的只有最合适的”。

每项技术的诞生都解决了对应时期很多的实际问题，而今再来回头看，我认为它们都是伟大的。

个人文笔原因很多细节仍有许多不尽之处，如有问题欢迎留言评论交流。如果此文对您有帮助，记得点赞收藏额~