作者：从结尾开始
资料来源：https://www.cnblogs.com/michael9/p/14432935.html
本文篇幅较长，主要涉及以下内容：
摘要：本文介绍了传统CLI配置网络设备面临的挑战，网络管理协议的背景，SNMP原理，交互过程，以及NETCONF体系结构，RESTCONF体系结构的交互过程，以及与NETCONF的比较。随着5G的大火，SDN、NFV等概念被频繁提及。要更好的理解这些概念，网络协议自然是不可或缺的一部分。
例如，SDN被称为软件定义网络-软件定义网络。从传统网络来看，整体采用分布式架构，控制平面和转发平面位于同一个设备上。在运维上，以及灵活性上都有不小的挑战。
随着SDN的出现，控制平面和转发平面解耦，所有设备统一管理，使得网络具有可编程能力。从面对面服务的角度，可以根据业务需求实时动态调整设备的配置或状态，大大降低了管理难度。
那么NETCONF和RESTCONF的作用是什么呢？
这是关于SDN架构的。SDN主要有三个作用：SDN应用、SDN控制和网络设备。
一般SDN应用会通过HTTP调用SDN控制器的暴露接口，而SDN控制器会通过NETCONF和RESTCONF类似的协议与设备交互，交付服务。
可以看出，类NETCONF协议起到了与设备直接交互的作用。
还有最近流行的DEVOPS概念，也是强调从传统的手动CLI配置过渡到自动网络配置。而NETCONF的类似协议让这些自动操作成为可能，比如ANSIBLE和Python的各种类库。
以下是网络管理协议的实际使用案例，可以看出覆盖的范围已经很广了：
让我们从传统CLI面临的挑战开始，了解这些发挥重要作用的协议的更多信息。
采用传统CLI配置模式主要有以下挑战：
在兼容性方面，如果你是网络工程师，一定要有很深的了解。
以静态路由的配置为例。Cisco设备命令如下：
华为和华三设备的路由器(配置)# IP路由0 . 0 . 0 . 0 0 . 0 10 . 10 . 10 . 1:
router(config)# p route-static 0 . 0 . 0 . 0 . 0 10 . 10 . 1有时候不仅不同厂商的命令不一样，就连同一厂商不同型号的命令也不一样。
例如，思科针对不同的场景区分不同的网络软件系统：
面向企业的IOS，面向运营商的IOS-XR，面向数据中心的NX-OS，面向下一代的IOS-XE，数据层和控制解耦，底层支持Linux。至于出错率，不用说，手动配置远没有机器配置准确快速。
而且现在的网络规模和需求也和以前有很大的不同。比如在实时性方面，运营商需要根据业务需求动态调整EVPN、L3VPN、L2TP等策略。传统CLI手动配置根本无法满足，无法维护管理。现在，常见的解决方案是利用一些现有的SDN控制器进行实时调整，如思科的NSO。
在数据收集方面，传统的人工定期登录设备和材料系统日志来分析情况就更不适用了。在故障响应中，数据收集和分析存在固有的缺陷。比如采集效率低，数据利用率延迟或者不高。
最后，考虑到商业成本，人工维护方案也是更高的产出。
而且对于工程师来说，需要不断学习不同厂商的配置命令，成本高但意义不大。
一般来说，在开始一个项目之前，网络工程师会进行以下四个部分：
了解用户需求，根据用户需求确定相应的具体方案。根据用户的计划，找到并学习相应设备的配置命令，最后申请割接窗口，准备回滚计划并实施。这里的第三步，其实是一个很费时间却毫无意义的过程。因为我们专心学习不同厂商的设备命令，从商业考虑显然可以解决同一个问题。
在发现CLI管理设备的方式存在瓶颈后，它并没有立即过渡到目前流行的网络自动化配置模式，而是首先引入了一种叫做简单网络管理协议(Simple Network Management Protocol)的应用层协议——SNMP，这种协议甚至在一些现有的网络中仍在使用。
SNMP的出现主要想
解决两个问题：设备信息的采集使用 GUI 替代 CLI 的方式进行设备配置下发但由于其读多写少的特点，现被广泛用于设备信息的监控和采集。
SNMP 目前共有三个版本：
SNMP V1，第一个版本。在管理设备上，采用明文的方式，有 read-only , read-write , trap 三种和设备通信的方式。SNMP V2，主要改进了性能，安全性以及设备交流的方式。SNMP V3，主要优化了安全性，增加了一些更强的认证流程。
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 GetSNMP SETSNMP NotificationsSNMP 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 都不需要回复。
性能不足，在下发和读取配置时，采用依次读取，效率低。下发不足，支持写 MIB 的对象相对于读较少。不支持事务机制，在配置下发失败是，无法回滚。拓展性差，提供给外部的接口较少。模型兼容性差，MIB 库混乱，无法适配所有厂商，导致定义各种私有 MIB 库。面对这些问题，06 年由 IETF 领导并开发出了一个新的协议 - NETCONF，网络管理协议。和 SNMP 不同，NETCONF 基于 RPC 的方式，天生就能很好的支持事务回滚等操作，从而更好地处理复杂网络的各种需求。
对于支持 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 分为 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 传输的安全性。
对于 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 文件能约束 XML 的文件格式，原因在于 YANG 和 XML 之间是可以相互转换的，甚至 YANG 还可以转换成 JSON. 在之后的 RESTCONF 中会提到这一点。
到目前为止，对 NETCONF 已经有了一个大体认识：
NETCONF 的出现是为了弥补像 SNMP 这些协议的不足。更好的满足现在网络的需要，在易用性，拓展性等等方面都做出了进一步优化，从而更方便，高效的管理网络。
究其本质，NETCONF 是由多个协议组装而成。数据的产生及校验通过 YANG，数据的格式是 XML. 接口的调用通过 RPC，数据的传输通过 SSH.
# 打开 netconf netconf-yang# 查看 netconf 进程show platform software yang-managementClient 端：测试设备 NETCONF
ssh admin@IP -p 830 -s netconf关于 NETCONF 具体实现编程化操作，可以参见 YANG 这篇。
再回答这个问题前，先来回忆一下什么是 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 = NETCONF / YANG + HTTP(s).
如果拿之前的 NETCONF 协议架构 作为对比，RESTCONF 就是将：
内容层，同样由 YANG 约束生成。RPC 消息层和操作层，换成了 HTTP 的操作层。将 SSH 构成的传输层，换成了 HTTP（s）的传输方式。
图中很好的对比了 RESTCONF 和 NETCONF 的交互过程，都是采用了 C/S 架构，在具体组件上：
NETCONFRESTCONF客户端NETCONF clientHTTP Client配置格式由谁约定YANG module / XSDYANG module发送内容格式XMLXML/JSON交互方式RPCHTTP传输协议SSHHTTP(s)服务端NETCONF serverHTTP server
对于操作来说，将 RPC 操作换成了 HTTP 操作：
# 打开 RESTCONF restconf-yang# 查看 RESTCONF 进程show platform software yang-managementClient 端：
由于已经采用了 REST 风格，可以利用 POSTMAN 等等 HTTP 客户端进行测试。
关于 RESTCONF 具体实现编程化操作和其 URL 的使用是非常重要的一部分，但由于其依赖 YANG 这个概念，这个后面会单独提到，可以参见 YANG 这篇。
当然对网管协议也有了进一步的理解。
下面做一个简单的总结：
传统 CLI 配置方式，已经无法满足当代网络可编程化的需要，而且在兼容性，易用性，正确率存在着诸多问题，进而网管协议应运而生。
SNMP 作为推出的第一代协议，在一定程度上解决了设备管理的问题。但由于其读多写少的特点，以及在兼容性，效率，以及缺乏事务性的不足，在现网中，一般用其作为设备配置采集或监控的工具。
为了更好的满足网络的需要，第二代协议 NETCONF 出现，由于 NETCONF 天生 RPC 支持事务的特点，再加上 YANG 解决了多厂商命令兼容性的问题，现被广泛使用在各种网管平台，SDN 控制器中。
随后 HTTP REST 风格的普及，IETF 又推出了 RESTCONF 协议，将 NETCONF 和 HTTP 整合在一起，以更为流行的方式，实现对设备的管理。
NETCONF - wiki
RFC6241 - NETCONF
NETCONF datestore
通过 NETCONF 实现网络自动化
REST 介绍
RESTCONF - RFC8040
基于Model驱动的自动化网络
RESTCONF 介绍
CISCO 可编程化网络
SDN 和 NFV 的关系
作者：以终为始
出处：https://www.cnblogs.com/michael9/p/14432935.html
