介绍传统 CLI 配置网络设备存在的挑战，网管协议出现的背景随着 5G 的大火，SDN, NFV 等概念被频繁提及。想要更好的理解这些概念，网络协议自然是对必不缺少的一环。

Tags:

via Pocket https://ift.tt/3lRFJfC original site

March 26, 2021 at 09:45AM

Comments

from: github-actions[bot] on: 3/26/2021

一文读懂网管协议 - SNMP，NETCONF，RESTCONF - 以终为始 - 博客园

一文读懂网管协议 - SNMP，NETCONF，RESTCONF

本文篇幅较长，主要涉及以下内容：

介绍传统 CLI 配置网络设备存在的挑战，网管协议出现的背景
SNMP 原理，交互过程，以及 trade-off
NETCONF 架构，交互过程
RESTCONF 架构，和 NETCONF 的对比

随着 5G 的大火，SDN, NFV 等概念被频繁提及。想要更好的理解这些概念，网络协议自然是对必不缺少的一环。

拿 SDN 来说，全称为 Software Defined Networking - 软件定义网络。从传统网络来说，整体采用分布式的架构，控制平面和转发平面都位于同一台设备上。在运维，以及灵活性上都有着不小的挑战。

而 SDN 的出现，将控制平面和转发平面解耦，并将所有的设备统一管理起来，使得网络具有了可编程的能力，从面相服务的角度，根据业务需要，实时动态的调整设备的配置或状态，大大降低了管理难度。

那么 NETCONF，RESTCONF 这样的协议又是起到怎样的作用呢？

这就要从 SDN 架构说起，SDN 主要有三个角色，SDN 应用，SDN 控制，网络设备。

SDN 应用一般会通过 HTTP 的方式，调用 SDN 控制器暴露的接口，而 SDN 控制器，会通过 NETCONF，RESTCONF 类似的协议，与设备进行交互，进行业务的下发。

可见，NETCONF 类似的协议起到和设备直接交互的作用。

还有最近 DEVOPS 概念的流行，也强调从传统人工 CLI 配置，过度到自动化的网络配置。而 NETCONF 类似协议，就让这些自动化操作成为可能，比如现在的 ANSIBLE，Python 的各种类库。

下面是网管协议的实际用例，可以看到涵盖的范围已经非常之广：

下面就从传统 CLI 面临的挑战开始，来详细了解下这些发挥着重要作用的协议。

传统命令操作带来的主要挑战

采用传统 CLI 配置方式主要存在着如下的挑战：

在兼容性方面，若是网络工程师的话肯定深有体会。

拿配置静态路由举例， Cisco 设备命令如下：

Router(config)#ip route 0.0.0.0 0.0.0.0 10.10.10.1

而对于华为和华三设备来说：

Router(config)#p route-static 0.0.0.0 0.0.0.0 10.10.10.1

有时不光是不同厂商之间的命令不同，甚至同一厂商不同型号之间的命令也不相同。

比如思科针对不同的场景就区分了不同的网络软件系统：

针对于企业的 IOS
针对于运营商的 IOS-XR
针对于数据中心的 NX-OS
以及面向下一代的 IOS-XE，将数据层面和控制解耦，底层支持 Linux.

而出错率这方面，更不必说，人工配置远没有机器配置的准确以及迅速。

而且目前的网络在规模和需求上也和之前大不一样，比如在实时性上，作为运营商需要根据业务需求动态调整策略如 EVPN，L3VPN，L2TP。传统 CLI 手工配置根本无法满足，而无法做到维护管理。而现在的常用解决方案都是利用一些现成的 SDN Controller 进行实时调整如 Cisco 的 NSO.

在数据采集方面，传统人工定时登上设备材料系统日志，分析情况，这更加无法适用。在故障响应上，数据采集，分析都存在先天的不足。比如收集效率低，数据的利用率延迟或不高。

最后从商业成本的考虑，人工的维护方案也是较高的一笔输出。

而且对于工程师而言，需要不断学习不同厂商的配置命令，学习成本很高，但意义不大。

通常来说，网络工程师在开始一个项目前，会进行如下四个部分：

了解用户的需求
针对用户的需求，确定相应的具体方案。
根据用户的方案，查找并学习对应设备的配置命令
最后申请割接窗口，准备回滚方案并实施。

在这里的第三步，其实就是一个比较耗时，但没多少意义的过程。因为在集中学习不同厂商的设备命令，但从业务考虑明明解决的都是同一个问题。

在发现 CLI 管理设备的方式出现瓶颈后，并不是马上过度到现在流行的网络自动化配置方式，而是先推出了一个叫 Simple Network Management Protocol - SNMP 的应用层协议，甚至在当前的一些现网中，依然被使用。

SNMP

SNMP 的出现，主要想解决两个问题：

设备信息的采集
使用 GUI 替代 CLI 的方式进行设备配置下发

但由于其读多写少的特点，现被广泛用于设备信息的监控和采集。

SNMP 目前共有三个版本：

SNMP V1，第一个版本。在管理设备上，采用明文的方式，有 read-only, read-write, trap 三种和设备通信的方式。
SNMP V2，主要改进了性能，安全性以及设备交流的方式。
SNMP V3，主要优化了安全性，增加了一些更强的认证流程。

SNMP 原理

SNMP 整体架构上有些类似于 Client / Server，其主要的工作组件主要有三个：

SNMP Manager：，主要用于管理网络中的多个设备，对其进行读和写的操作。类似于 Server.
SNMP Agent：运行在网络设备上，通常都需要手动开启。作为 SNMP 代理，在收到 SNMP Manager 发出请求后，对请求的内容进行解析，然后对设备进行配置，将配置的结果作为 Response 回复给 Manager.
SNMP MIB: MIB - Management Information Base 全称为信息管理库。可以将其理解成用于交互的一种数据模型，也就是交互的规则。MIB 同样存在于网络设备中。定义和描述了如何管理设备上的资源。Manager 和 Agent 之间的交流的信息就是 MIB 的内容。

可以看到一个 Manager 可以管理网络中的多个设备。而每台设备上运行着 SNMP Agent 用于和 Manger信息交互，交流的内容需要符合 MIB 的规范。

看到这，可能对 MIB 这个概念还是有些模糊。这样，我们先不从最后的结果来分析这个组件的作用，而是从设计的角度，来说一下推导下为什么要有 MIB 这个东西？

这里想要实现的是通过 Manager 去管理网络上的 Agent（其实就是管理设备）。那么如何管理呢，比如 Manager 想要获取 Agent1 的 GigabitEthernet0/0/0/1 的 IP 地址。

这时就需要在 Agent1 上先约定好一个内容，比如当 Agent 接收到 1.1 这个字符串时，就会将接口的信息返回给 Manager.

之后如果 Manager 发送 1.1 就能获取到接口的信息了，但发送别的内容，Agent 是无法识别并工作的。MIB 本质就是这样，确定了如 1.1 这样的一组规则，去规范信息交互的访问方式。

其实，这里的 1.1 就是 MIB 中的一个对象，在 MIB 中还以层级的方式存在着许多这样的对象，将网络的设备的资源抽象成形如 1.1 对象。通过这些对象，Manger 和 Agent 就可以实现很好的交流了。

真正的 MIB 类似与下图，而这里形如 1.3.6.1.1.1.2 这样连接起来的字符串称为 ASN，其实就是对应了设备上的各种资源，Manager 和 Agent 也通过它们进行交流。

SNMP 操作

SNMP Manger 和 SNMP Agent 间的交互主要有三种类型：

SNMP Get
SNMP SET
SNMP Notifications

SNMP Get：主要是检索设备的信息，Get 一种有三种类型：

GET - 从 SNMP agent 获取固定的对象。
GETNEXT - 检索当前对象的后一个对象，由于 MIB 本身层级的树形结构，存在后继。
GETBULK - 获取一组固定的对象。

SNMP SET：主要是修改 MIB 中的对象，进而修改设备的配置。

SBMP Notifications：是 SNMP 的主要特性，之前的 GET 和 SET 是属于拉的操作，而 SNMP 正好相反，类似于推的操作，可以由 agent 发起，将一些信息 push 到 SNMP Manager 上。类似于 Web Socket. 主要用于通知如认证失败，重启，断开连接等事件。

Notifications 主要有两种形式：Traps 和 Informs. 两者间的不同主要在于可靠性，agent 在产生 Informs 给 Manager 后，如果发送失败，会重新发送。Manager 收到后，需要回复确认给 agent。

而 Traps 不同，无论消息发送是否成功，Manager 都不需要回复。

SNMP 缺点

虽然 SNMP 的出现，在一定程度上解决了网络设备的管理问题。但面对现代大规模的网络来说，依然有着很多挑战：

性能不足，在下发和读取配置时，采用依次读取，效率低。
下发不足，支持写 MIB 的对象相对于读较少。
不支持事务机制，在配置下发失败是，无法回滚。
拓展性差，提供给外部的接口较少。
模型兼容性差，MIB 库混乱，无法适配所有厂商，导致定义各种私有 MIB 库。

面对这些问题，06 年由 IETF 领导并开发出了一个新的协议 - NETCONF，网络管理协议。和 SNMP 不同，NETCONF 基于 RPC 的方式，天生就能很好的支持事务回滚等操作，从而更好地处理复杂网络的各种需求。

NETCONF

NETCONF 协议提供了一种更简单的方式来管理（”查询，配置，修改，删除”）设备，就像数据库操作中的 DML. 同时开放了 API 接口，当想要对设备进行操作时，直接通过调用 API 进行。

对于支持 NETCONF 的设备来说，至少能开启一个或多个 session。并且在每个 session 中应用的配置更改，都可以被全局的 session 监听到。这就让一个或多个 Manager(Client) 操作同一个设备（agent）成为了可能。

相比 SNMP 而言，有着如下的优势：

基于 RPC，增加了事务支持
优化查询功能，增加过滤查询方式
拓展性强，在其协议内部分为 4 层，各层之间相互独立
更好的将配置和状态数据解耦，并区分状态数据（candidate, running, startup）
易使用，结合提供的 API，实现可编程性的网络操作
安全性更好，在传输层可选用 SSH，TLS 协议等。

NETCONF 采用 C/S 的架构，通过 RPC 在 client 和 server 间交流。client 可以是 Python 脚本或应用。server 一般指的是网络设备，在具体实现上有三个组件：

NETCONF agent：运行在网络设备上，用于接收和处理 RPC 请求。还可主动将一些告警事件通知客户端。
NETCONF 客户端：利用 NETCONF 协议对网络设备进行管理以及接收 agent 发出的告警通知。
datastore：在 NETCONF 中，区分了多个不同类型的 datastore, 这些 datastore 保存着不同状态下的设备信息。

关于 datastore 可以将其理解成一个可以获取和存储信息的概念。在具体实现上，可以是文件，数据库，内存等等。

在 NETCONF 中常用到三类 datastore：

startup configuration datastore: 保存了设备启动时，加载的配置信息。
candidate configuration datastore: 保存了想要运行的配置信息，修改该数据库时，并不会影响设备的真实配置。
running configuration datastore: 保存了当前设备上正在生效的配置，修改时会影响真实的设备。

此外提到 datastore 就必须要提到一种数据模型语言 —— YANG，datestore 中就是以 YANG 的形式来约束配置的数据。

YANG 的出现结合上 NETCONF 和 RESTCONF 这样的协议，为自动化，可编程化的网络提供了强大的支持。YANG 的本质和之前 SNMP 中 MIB ASN 一样，作用都是以一种方式来约束数据，关于 YANG 之后会写一篇文章单独介绍。

NETCONF 协议架构

NETCONF 分为 4 层，各层之间项目独立。

内容层：

这一层包含了以 XML 或 JSON 格式的配置数据，也就是想对设备进行管理的具体内容。（由 XSD 或者 YANG 约束生成）

操作层：

定义了 Client 和 Server 交互时的一系列操作方法，用于获取或修改配置数据。

消息层：

为编码数据时，提供了一种 RPC 和通知的机制：

* RPC invocations(<rpc> messages)  
* RPC results(<rpc-reply> messages)
* event notifications(<notification> messages)

传输层：

NETCONF 使用 SSH 或 TLS 协议，保证数据在 Client 和 Server 传输的安全性。

NETCONF 交互

对于 Manager 和 Agent 来说，Session 建立会经历如下的过程：

Manager 请求 NETCONF 中 SSH 子系统建立连接。
Agent 回复 Hello 消息，包含本身支持的特性和能力。
Manager 告知 Agent 自己所支持的特性和能力。
Manager 开始发送 RPC 操作请求。
Agent 回复 RPC 请求操作结果。

具体看下 NETCONF 中消息的报文结构，以修改接口配置举例：

Manager 请求变更接口配置：

 <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu>1500</mtu>
             </interface>
           </top>
         </config>
       </edit-config>
</rpc>

Agent 回复结果：

<rpc-reply message-id="101 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <ok/>
</rpc-reply>

首先可以看到，NETCONF 使用 XML 作为数据传输的格式。

第一行的 <rpc> 标签，表明该请求是 RPC 请求，message-id 属性由 client/manager 确定。Agent 在回复结果时，会带上 message-id，用于表示该操作的结果。

urn:ietf: 属性表示 XML 中的命令空间。 base：1.0 表示当前 NETCONF 的版本。

第二行 <edit-config> 指定执行 RPC 操作的内容为修改配置。

之后 <config> 中包裹的内容就是，想要下发的配置内容，修改 mtu 为 1500.

但这里还有一个疑问，在说到 NETCONF 时，总提到一种叫 YANG 的语言，那么它们之间的关系是什么？

在组装修改设备配置 Payload 时，这里也没有用到 YANG ？

其实，YANG 早已用到了。为什么 <interface> 中可以包含 <name> 和 <mtu> 属性。而不是把 mtu 放在和 <interface> 同级。

原因就在于上面的格式，都是按照 YANG 的约束而来。

在设备中，存在着许多的 YANG Module，这些 Module 都是由 YANG 语言编写的文件。当 agent 接收到 RPC 请求时，会通过 YANG Module 来校验发来的数据，格式是否合法。

简单来说，可以把 YANG 理解成一份约束文件，里面规定着传来参数的格式，是数组，对象还是其他格式。

至于说为什么 YANG 文件能约束 XML 的文件格式，原因在于 YANG 和 XML 之间是可以相互转换的，甚至 YANG 还可以转换成 JSON. 在之后的 RESTCONF 中会提到这一点。

到目前为止，对 NETCONF 已经有了一个大体认识：

NETCONF 的出现是为了弥补像 SNMP 这些协议的不足。更好的满足现在网络的需要，在易用性，拓展性等等方面都做出了进一步优化，从而更方便，高效的管理网络。

究其本质，NETCONF 是由多个协议组装而成。数据的产生及校验通过 YANG，数据的格式是 XML. 接口的调用通过 RPC，数据的传输通过 SSH.

NETCONF 操作

Server 端：打开设备 NETCONF

#  打开 netconf 
netconf-yang

# 查看 netconf 进程
show platform software yang-management

Client 端：测试设备 NETCONF

ssh admin@ IP -p 830 -s netconf

关于 NETCONF 具体实现编程化操作，可以参见 YANG 这篇。

RESTCONF

在谈起 RESTCONF 前，想必刚接触这个概念的人都会有这样一个疑问 RESTCONF 和 REST 到底有没有关系？

再回答这个问题前，先来回忆一下什么是 REST，以及 REST 出现的背景。

REST - Representational State Transfer，全称为表现层状态转化，是建立在 HTTP 基础上，对其进行规范的一种架构风格要求。

注意，REST 是一种设计的风格，而不是标准。

其认为，网络中的实体都是以资源的方式存在，但资源却存在着多种表现形式，取决于使用者的需要。比如一个用户的信息，可以用 XML, JSON, 甚至是 txt 等多种方式表现出来。将不同的网络资源转换成不同的表现形式，就是其表现层的体现。

而状态转移来说，由于 HTTP 本身是无状态的协议，所以资源的状态全都保存在服务端。当对服务端的资源进行操作时，必然存在数据状态的改变。

但由于状态的改变基于表现层，所以称为表现层状态转移。

在具体实现上，URI 定义了访问资源的具体路径，而 HTTP 中 Header 的 Content-Type 和 Accept 决定了了表现层的形式。

HTTP 中的 CURD 动作（Create，Put，Get，Delete，patch..）去改变服务端的资源状态。

比如查询书店具有的图书：

GET http://www.store.com/products

通过 REST 的方式，更合理的实现 WEB 服务之间的交互。

这时再看 RESTCONF，就很好理解了。RESTCONF 是通过 REST 来实现对网络设备管理的协议。其本质和 NETCONF 很像，使用 YANG 进行数据的定义和约束，使用 HTTP 进行交互。使用 NETCONF 中 datastore 的概念，进行信息的储存。

RESTCONF 架构

图中很好的表示了 RESTCONF 协议组成，很形象的指出 RESTCONF = NETCONF / YANG + HTTP(s).

如果拿之前的 NETCONF 协议架构作为对比，RESTCONF 就是将：

内容层，同样由 YANG 约束生成。
RPC 消息层和操作层，换成了 HTTP 的操作层。
将 SSH 构成的传输层，换成了 HTTP（s）的传输方式。

RESTCONF VS NETCONF 交互

图中很好的对比了 RESTCONF 和 NETCONF 的交互过程，都是采用了 C/S 架构，在具体组件上：

NETCONF

RESTCONF

客户端

NETCONF client

HTTP Client

配置格式由谁约定

YANG module / XSD

YANG module

发送内容格式

XML

XML/JSON

交互方式

RPC

HTTP

传输协议

SSH

HTTP(s)

服务端

NETCONF server

HTTP server

对于操作来说，将 RPC 操作换成了 HTTP 操作：

RESTCONF 操作

Server 端：打开设备 RESTCONF

#  打开 RESTCONF 
restconf-yang

# 查看 RESTCONF 进程
show platform software yang-management

Client 端：

由于已经采用了 REST 风格，可以利用 POSTMAN 等等 HTTP 客户端进行测试。

关于 RESTCONF 具体实现编程化操作和其 URL 的使用是非常重要的一部分，但由于其依赖 YANG 这个概念，这个后面会单独提到，可以参见 YANG 这篇。

总结

这篇文章，耗时很久，查阅了大量资料，完成后真的如释重负一般。

当然对网管协议也有了进一步的理解。

下面做一个简单的总结：

传统 CLI 配置方式，已经无法满足当代网络可编程化的需要，而且在兼容性，易用性，正确率存在着诸多问题，进而网管协议应运而生。

SNMP 作为推出的第一代协议，在一定程度上解决了设备管理的问题。但由于其读多写少的特点，以及在兼容性，效率，以及缺乏事务性的不足，在现网中，一般用其作为设备配置采集或监控的工具。

为了更好的满足网络的需要，第二代协议 NETCONF 出现，由于 NETCONF 天生 RPC 支持事务的特点，再加上 YANG 解决了多厂商命令兼容性的问题，现被广泛使用在各种网管平台，SDN 控制器中。

随后 HTTP REST 风格的普及，IETF 又推出了 RESTCONF 协议，将 NETCONF 和 HTTP 整合在一起，以更为流行的方式，实现对设备的管理。

参考

[通过 NETCONF 实现网络自动化](https://medium.com/@ k.okasha/network-automation-and-the-rise-of-netconf-e96cc33fe28)

posted @ 2021-02-22 21:13 以终为始阅读(292) 评论(0) 编辑收藏