首先，让我们假想一个场景：
由于业务发生变更，需要为一个 POD 里面的几十台交换机修改 QoS 配置。作为网络运维人员，应该怎样处理这项工作呢？
如果需要变更的对象是整个数据中心几百台甚至几千台交换机，又该怎样处理这项工作呢？
当下，互联网行业已经普遍采用 DevOps 的体系流程。靠人力去一台设备一台设备的更改配置，已经不再是正确的思维方式。原因不仅仅是浪费时间 —— 要知道，人如果要长时间保持注意力集中，大脑需要耗费大量的能量，很难保证不出现遗漏或者错误。而机器却不会。
因此，正确的方法是利用 DevOps 的流程，让机器来完成这项工作。例如采用基于 Python 的 SSH 库 Paramiko 或 Netmiko，以及 Ansible 或 SaltStack 等自动化工具编写运维脚本。
Netmiko 库和 Ansible 等运维工具虽然可以通过程序化的脚本对网络设备实现批量管理，但仍然需要运维工程师对网络设备的 CLI 很熟悉，预先在脚本中建立需要被执行的 Command 列表。
CLI
CLI 最大的问题就是在不同厂商的设备之间，甚至在不同版本之间存在较大差异。比如在某 C 厂商交换机上配置边缘端口，不同的 OS 版本命令并不相同：而对于另一些厂商，配置命令则差异更大。例如在某 E 品牌 交换机上配置边缘端口的命令为：这意味着：如果设备版本升级，就可能需要更改运维脚本的代码。为了避免厂商绑定，网络内通常也会同时存在多个厂商的设备，相应地，也可能需要准备多种运维脚本或者让运维脚本变得很复杂 —— 先判断设备型号和版本号，再运行相应的 Command-list。
所以 CLI 并不适合用来作为一种 API。虽然采用自动化工具处理 Commands 可以节省网络运维人员的工作量，但是技术门槛和维护成本都比较高。SNMP 似乎是一种更好的选择。
SNMP 的历史很悠久，第 1 个与之相关的 RFC 1065 发布于 1988 年，距今已有 30 年。在 SNMP 架构中，一个网络设备以守护进程的方式运行 SNMP Agent，而 NMS（网络管理系统）和网络运维人员所使用的各种 SNMP 管理工具则称为 SNMP Manager。SNMP Agent 能够响应来自 SNMP Manager 的各种请求信息。
SNMP Agent 会维护一个 MIB（管理信息库），里面保存着大量的 OID （对象标识符）。一个 OID 是一对唯一的 Key-Value，SNMP Manager 向 SNMP Agent 查询或修改若干 Key 所对应的 Value，就可以实现信息采集或者网络设备的配置修改。
上图是一个 MIB 示例，请注意标黄色的部分。OID 1.3.6.1.2.1.2.2.1.5 用来以 bps 为单位评估接口流量，它属于 RFC 1213 标准 MIB，名称为 ifSpeed，只读。因为这个 MIB 并不是我从正在运行的设备上取下来的，所以当前的 Value 为空。
需要注意的是，SNMP Manager 侧的 MIB 并不是必需的。如果使用数字 OID 1.3.6.1.2.1.2.2.1.5，SNMP Manager 可以直接从 SNMP Agent get 接口流量带宽，而不需要安装完整的 MIB。
现在 SNMP 在网络监控领域已经被广泛使用，利用 Zabbix、Nagios、Cacti 等开源的 SNMP 管理工具采集网络设备接口流量带宽和其他设备信息，同时也有大量的基于 Python 的 SNMP 库用来实现运维开发，例如 PySNMP、 EasySNMP、 Net-SNMP等等，并且它们都可以集成到 Ansible 和 SaltStack 等自动化运维工具上。
看上去还不错，但实际上 SNMP 仍然不是一个合适的 API，因为它存在几个问题：
○太古老，并发性能不好
○基于 UDP 协议传输，比较不可靠。虽然在应用层有 Response 机制保证丢包之后的重复 get/ set，但代价就是性能和运行时间都受到影响
○最致命的问题是，各厂商都大量的使用私有 MIB，却不存在一个可以自动发现网络设备当前所采用的 MIB 的机制。网络运维人员必须分别向设备厂商索取网络设备的 MIB，耗费大量的时间整理自己需要的 OID，再手工导入到自动化运维平台或者脚本当中
所以 SNMP 仍然只适合用来做信息采集，提供告警和可视化报表，但自动化运维的 API 则需要考虑其他的选项。站在网络运维人员的角度，这个 API 应该满足以下要求：
○容易使用 —— Usability 是所有产品的核心价值
○需要能够清晰地区分“配置数据”，“设备运行状态数据”和“统计数据”
○需要能够分别从各个网络设备获取上述 3 种数据，并且可以方便地对比不同设备的数据
○可以让网络运维人员统一地管理整个网络的所有设备，而不是一台一台的单独管理
○对不同厂商的设备都能够使用同一种配置方法
○配置变更对网络业务的影响要尽可能的小
○能够提供一个标准化的，对设备 Pulling 和 Pushing 配置文件的流程，以满足对设备配置的备份和恢复的业务需求
○能够很方便地，持续地，检查设备配置文件的一致性
○能够提供基于文本的配置方式，并且不会导致配置的乱序，例如不能搅乱 ACL 规则的顺序
能够满足这些要求的网络设备的北向 API 接口就是 Netconf。
Netconf 是 IETF 发布的标准协议，它的全称是 Network Configuration Protocal。从名字就可以看出来，Netconf 的作用是基于网络来安装、操作和删除设备的配置。在 Netconf 的架构中，网络设备充当 Netconf Server 的角色，而运维人员的这一侧则是 Netconf Client。此外，和 OSI 标准模型一样，Netconf 也是分层结构。
它有 4 个层次，从下到上依次为：
●安全传输层
安全传输层在 Netconf Client 和 Netconf Server 之间提供安全的端到端连接。与 SNMP 采用非面向连接的 UDP 协议不同，Netconf 采用面向连接的 TCP 协议，通常是 SSH 协议，保证连接的可靠性和安全性。
●消息层
消息层也称为 RPC（远程过程调用）层。Netconf Server（网络设备）上面部署了 Netconf 应用，Netconf Client 需要调用 Server 上的应用所提供的函数/方法，但由于 Client 和 Server 不在同一个内存空间，无法直接调用，所以需要通过网络来表达调用的语义，并传达调用的数据。这个过程，称为 RPC。它提供了一个简单的，与安全传输层无关的机制来封装操作层和内容层的数据：
○RPC 调用： 元素所封装的消息
○RPC 结果： 元素所封装的消息
○事件通知： 元素所封装的消息
●操作层
操作层定义了如图所示的 9 种基础操作集，其中：
用来对设备进行取值操作
用于配置设备参数
和是在对设备进行操作时，为防止并发产生混乱的锁行为和用于结束一个会话操作
●内容层
顾名思义，内容层就是用来表达配置数据和状态数据，网络运维人员只需要关注数据本身，而不需要去关注设备的相关命令。基础网络设备在内容层所采用的数据格式通常是 XML，但也有厂商的数据格式采用了 JSON。
虽然网络运维人员不再需要关注设备的相关命令了，但仍然无法直接使用 Netconf 配置设备，还需要考虑配置结构。
什么叫“配置结构”呢？
假如我们现在要将交换机的 10# 端口划入 VLAN 20。从上面两个配置示例可以发现锐捷交换机和 H 品牌交换机的配置结构有明显差异，所以无法直接使用 XML 或者 JSON 修改它们的设备配置。
为了解决配置结构的问题，需要将 XML 和 JSON 数据格式抽象成一个统一的标准的模型，这就是 YANG。YANG 的全称是 Yet Another Next Generation，没有恰当的中文来翻译它。通俗的讲，YANG 是表达 Netconf 所操作的配置数据和状态数据的模板，它描述什么才是符合设备期望的数据。有了 YANG Model，配置结构就交给它去处理，网络运维人员就只需要做一个完形填空即可。
这个过程在逻辑上，与向 SNMP 的 OID 填充/读取 Value 差不多。
Netconf 和 YANG Model 的出现，为网络自动化带来了极大的便利。配合自动化的程序，可以实现动态向网络设备下发配置，将数据面和控制面分离，组成软件定义的网络。事实上，Netconf 也是 OpenDayLight 等开源 SDN Controller 所广泛使用的南向接口之一。 此外，Ansible 也集成了 Netconf 的 Module，并且可以通过 Python 来扩展 ncclient 和 nxpy 等库，实现功能扩展。
但 Netconf 就是我们在寻找的理想的 API 吗？
站在网络运维者的角度，答案却是否定的。
原因在于很多厂商虽然支持 Netconf，但有一些 Key-Value 却存在差异。比如为了表达“端口”，有些厂商用 intf 作为 Key，但另外一些厂商却用 interface 作为 Key。另一个例子就是 Uptime，设备运行时间，各家厂商的设备返回的时间格式更是五花八门。这为网络运维人员处理数据的工作造成了很大的麻烦，不得不耗费大量的时间和精力去阅读设备厂商的 Netconf 文档，去编写大量的正则表达式。
还有，虽然主流的 SDN Controller 的南向接口都支持 Netconf，但是在实际部署时，却无法用单一的 Controller 去控制多厂商的网络设备。通常都是各个厂商使用自己的 SDN Controller 控制自己的设备，然后再用 REST API 与用户的 SDN Controller 对接。
上文所提到的网络运维人员所关心的 9 大问题，Netconf 几乎都能满足，但距离完全满足还有一些差距。
有一个解决办法，就是利用 NAPALM。
NAPALM
NAPALM 是一个 Python 库，它的全称是 Network Automation and Programmability Abstraction Layer with Multivendor support，多厂商支持的网络自动化和可编程抽象层。
目前 Ansible 集成了 3 个 NAPALM 模块，分别是：
○napalm_parse_yang：用于从设备或文件中解析配置/状态数据
○napalm_diff_yang：用于比较 2 个 YANG 对象的差异
○napalm_translate_yang：用于将 YANG 对象转译成设备原始的配置
从设备取出原始配置数据/状态数据之后，可以使用 NAPALM 将其翻译成标准格式的 NAPALM 数据。反之，也可以将标准格式的 NAPALM 数据翻译成设备原始配置数据，并 Push 到网络设备里面，以修改设备的配置文件。
读到这里，也许您已经猜到我将要说什么了……
是的，NAPALM 还是不能彻底解决网络自动化所面临的问题。
因为各厂商 Netconf 的数据表达存在很多差异，所以 NAPALM 必须要依赖第三方的 Module 来完成原始数据的解析和翻译。如果要解析厂商 A 的某个 OS 系统的配置，就需要一个 OSA_Module；如果要解析厂商 B 的某个 OS 系统的配置，则需要 OSB_Module。所以目前 NAPALM 支持的 OS 类型还比较少，仅限于某几个国外品牌厂商的 OS 系统。
即使是这几个国外品牌厂商，NAPALM 目前也无法实现完整的功能集。所以 Google 等网络设备的大用户一直在致力于推广一个能够替代 Netconf 的标准化接口： OpenConfig。
IETF 已经为 Netconf 和 YANG Model 发布了很多 RFC，从 2006 年的 Netconf RFC 4741，2010 年的 YANG Model RFC 6020，到现在已经超过 10 年。而最新的一个 RFC 在什么时候呢？就在几天之前的 2018 年 4 月 3 日，3 家设备厂商联合提交了一个 OSPF YANG Model 的草案 —— 标准化的进展太慢了。
也许，这就是问题所在 —— Netconf 标准是由网络设备厂商推动的，内耗太大。各个设备厂商都希望在软件定义网络的时代继续保持硬件设备的重要性，并且能够体现自己公司产品的差异化优势。
但是从网络运维者的角度考虑，这显然不合理，因为设备厂商所推动的 Netconf 标准并不是他们真正想要的。所以 Google，AT&T，British Telecom，Facebook，Apple，Microsoft 等互联网服务提供商成立了 OpenConfig 工作组，希望提供一个中立于设备厂商的标准 API。目前国内的腾讯、百度和阿里等互联网服务提供商也已经加入了 OpenConfig 工作组。
OpenConfig 沿用了 Netconf 的协议框架，但是它不太关注底层的数据传输，而是更关注上层的数据表达和数据建模。这意味着：不管是 A 厂还是 B 厂，所有的数据都必须符合 OpenConfig YANG Model，并且 Key-Value 都必须是 OpenConfig 所规定的标准格式！
OpenConfig 的另外一个核心要点是：虽然网络设备可能支持丰富的功能特性，甚至是设备厂商私有的功能特性，但是 OpenConfig 只关心与互联网行业用户通用的运维工作和网络设计工作相关的功能，例如 BGP、OpenFlow、Telemetry 等等。OpenConfig 不会为设备厂商的私有特性定义 YANG Model，也不会为设备厂商所特有的 Key-Value 做定义，所以不会出现不兼容的情况。
但反过来讲，OpenConfig 也不会为了兼容某些设备厂商而让 YANG Model 过于简单，所以设备厂商需要让自己的功能满足 OpenConfig YANG Model 的要求，具备 Model 所定义的所有的 Key，并且能够为所有的 Key 提供对应的 Value。
在 Key-Value 格式固定之后，网络运维人员对数据的解析工作就非常方便了。只要网络设备支持标准的 OpenConfig YANG，NAPALM 就可以对原始数据进行解析，不再依赖第三方 Module 就可以管理多厂商多 OS 的网络，进而实现真正的网络自动化。
使用 OpenConfig 的另一个好处就是可以简化 SDN 网络架构，用户使用一个控制器集群就可以同时控制多个厂商的网络设备，不再需要使用设备厂商的商用控制器做中继。
OpenConfig 工作组在 2015 年已经向 IETF 提交了 2 个 YANG 标准草案，虽然目前还没有标准的 RFC 发布，但是它现已成为网络自动化技术的发展趋势，因此各大网络设备厂商都开始了 OpenConfig 的开发工作。锐捷的数据中心交换机支持 Netconf YANG 和 OpenConfig YANG，目前正在国内配合公有云提供商进行标准化 SDN 的测试工作。
