首先

，让我们假想一个场景：

由于业务产生调换

，必要为一个 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

▲ SNMP Overview

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-Example

上图是一个 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

Netconf 是 IETF 颁布的尺度和谈

，它的全称是 Network Configuration Protocal。从名字就能够看出来

，Netconf 的作用是基于网络来装置、操作和删除设备的配置。在 Netconf 的架构中

，网络设备充任 Netconf Server 的角色

，而运维人员的这一侧则是 Netconf Client。此表

，和 OSI 尺度模型一样

，Netconf 也是分层结构。

▲ Netconf 4 Layers

它有 4 个档次

，从下到上顺次为：

• 安全传输层

安全传输层在 Netconf Client 和 Netconf Server 之间提供安全的端到端衔接。与 SNMP 选取非面向衔接的 UDP 和谈分歧

，Netconf 选取面向衔接的 TCP 和谈

，通常是 SSH 和谈

，保障衔接的靠得住性和安全性。

• 新闻层

新闻层也称为 RPC（远程过程挪用）层。Netconf Server（网络设备）上面部署了 Netconf 利用

，Netconf Client 必要挪用 Server 上的利用所提供的函数/步骤

，但由于 Client 和 Server 不在统一个内存空间

，无法直接挪用

，所以必要通过网络来表白挪用的语义

，并通报挪用的数据。这个过程

，称为 RPC。它提供了一个单一的

，与安全传输层无关的机造来封装操作层和内容层的数据：

○RPC 挪用： <rpc> 元素所封装的新闻

○RPC 了局： <rpc-reply> 元素所封装的新闻

○事务通知： <notification> 元素所封装的新闻

• 操作层

操作层界说了如图所示的 9 种基础操作集

，其中：

    <get>、 <get-config> 用来对设备进行取值操作

    <edit-config>、 <copy-config>、 <delete-config> 用于配置设备参数

    <lock> 和 <unlock> 是在对设备进行操作时

，为预防并发产生混乱的锁行为

    <close-session> 和 <kill-session> 用于实现一个会话操作

• 内容层

顾名思义

，内容层就是用来表白配置数据和状态数据

，网络运维人员只必要关注数据自身

，而不必要去关注设备的有关号令
；⊥缟璞冈谀谌莶闼∪〉氖萏迨酵ǔＪ XML

，但也有厂商的数据体式选取了 JSON。

固然网络运维人员不再必要关注设备的有关号令了

，但依然无法直接使用 Netconf 配置设备

，还必要思考配置结构。

什么叫“配置结构”呢？

如果我们此刻要将互换机的 10# 端口划入 VLAN 20。Ggpoker官网互换机必要在物理端口模式下配置：

而某 H 品牌互换机却必要在 VLAN 逻辑端口模式下配置：

从上面两个配置示例能够发现Ggpoker官网互换机和 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 到网络设备里面

，以批改设备的配置文件。

▲ Netconf & NAPALM

读到这里

，也许您已经猜到我将要说什么了……

是的

，NAPALM 还是不能彻底解决网络自动化所面对的问题。

由于各厂商 Netconf 的数据表白存在好多差距

，所以 NAPALM 必必要依赖第三方的 Module 来实现原始数据的解析和翻译。若是要解析厂商 A 的某个 OS 系统的配置

，就必要一个 OSA_Module
；若是要解析厂商 B 的某个 OS 系统的配置

，则必要 OSB_Module。所以目前 NAPALM 支持的 OS 类型还比力少

，仅限于某几个国表品牌厂商的 OS 系统。

即便是这几个国表品牌厂商

，NAPALM 目前也无法实现齐全的职能集。所以 Google 等网络设备的大用户一向在致力于推广一个可能代替 Netconf 的尺度化接口： OpenConfig。

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 & NAPALM

使用 OpenConfig 的另一个益处就是能够简化 SDN 网络架构

，用户使用一个节造器集群就能够同季节造多个厂商的网络设备

，不再必要使用设备厂商的商用节造器做中继。

▲ 单节造器架构

OpenConfig 工作组在 2015 年已经向 IETF 提交了 2 个 YANG 尺度草案

，固然目前还没有尺度的 RFC 颁布

，但是它现已成为网络自动化技术的发展趋向

，因而各大网络设备厂商都起头了 OpenConfig 的开发工作。Ggpoker官网的数据中心互换机支持 Netconf YANG 和 OpenConfig YANG

，目前在国内共同公有云提供商进行尺度化 SDN 的测试工作。

本期作者：陈程

Ggpoker官网网络互联网系统部行业征询

往期杰出回首 

●【第一期】浅谈物联网技术之通讯和谈的纷争

●【第二期】若何通过网络遥测（Network Telemetry）技术实现精密化网络运维？