网络自动化与NETCONF

英文原文

https://medium.com/@k.okasha/network-automation-and-the-rise-of-netconf-e96cc33fe28

阅读小记

传统的网络管理主要使用snmp或cli方式，snmp主要用于查询，cli（telnet、ssh）可读取或配置数据。
存在问题：1、cli操作的数据是非结构化的，以编程的方式运行非常麻烦；2、修改设备配置时，需要自定义验证步骤以确保配置正常。

IETF组织2003年时在RFC3535中，对新的网络配置协议提出了新的要求。

• 使用方便
• 配置模式与运行模式进行隔离
• 具备备份与恢复功能
• 提供错误检查功能
  这几项要求在传统的网络管理中是做不到的，如果说备份、恢复、错误检查，各大厂商自身的NMS系统或运营商自身的综合管理系统能够封装一二的话，配置模式与运行模式的隔离，则必须需要硬件的自身支持了。而且，基于SNMP、CLI做的封装，其复杂度与面临的问题都是相当庞大。

2006年，NETCONF诞生于RFC4741，NETCONF提要一下功能：

• 区分配置与状态数据
• 多个配置数据库（运行、启动、候选）
• 带过滤的选择性数据检索

• 支持配置事务
  其通信模式见下图：

  
  image.png

1. 客户端发起请求有两种方式：A、直接与NETCONF PORT的830服务端口建立ssh会话，B、建立SSH会话后请求NETCONF子系统。
2. 服务端或代理返回自身支持的功能。
3. 最后，客户端通过hello包的形式声明自身功能，然后向服务端或代理发起RPC调用，以查询或修改设备配置。

NETCONF协议栈

image.png

• 使用SSH作为传输协议
• 面向连接和面向会话
• 使用XML编码和表示数据
• 定义了与多个设备交互的操作
• 使用RPC在远程网络设备上调用这些操作

NETCONF标准中并没有定义描述数据的数据结构/模型，所以早期NETCONF使用XML Schema文件模拟NETCONF正在传输的数据。在RFC6020时，YANG模型被标准化，配置和操作数据均使用YANG模块建模。

image.png

设备数据库的几种模式：

1. 运行：设备上当前正在运行的配置
2. 候选：修改配置但未commit

3. 启动：设备启动时使用的配置

   
   image.png

NETCONF真正的力量：

• 如果你需要同时在多台设备上进行配置操作，如添加VPN，向BGP添加地址等，使用NETCONF，可以在所有设备上发送配置，并根据设备上返回的配置信息进行验证，如果一切正常，可以在单个事务中对所有设备的配置操作进行提交。
  使用ssh或telnet是永远做不到这一点。
• 另一种情况时，如果对多台设备进行了提交，在运行一段时间后，发现需要还原配置，NETCONF可以让这些设备回滚到其原始状态。

NETCONF是SDN控制器在南向控制网络设备上使用的关键API之一。