Netconf协议学习第一期

netconf协议提供一套管理网络设备的机制，用户可以通过netconf增加、修改、删除网络设备的配置，获取网络设备的配置和状态信息。

NETCONF采用的是C/S的模式：

NETCONF协议内部分为4层，由下至上分别是安全传输层，消息层，操作层和内容层。

在详细介绍这四层之前，需要提前建立一个概念，NETCONF认为网络的模型数据可以分为两大类，即状态数据和配置数据。

• 状态数据一般指server（设备）的固有属性数据和当前运行的状态数据等，这类数据仅能查询。
• 而配置数据则是指由用户（以某种方式）配置到server上的数据。配置数据本身又可以存在多个数据库，标准中提到了库用于保存当前已经生效的配置；用于保存可以提交为生效的数据；以及用于保存启动时的配置数据。

NETCONF的第一大优势就是其从协议层面就已经规定其传输层必须使用带有安全加密的通信协议，例如SSH，TLS等。相比与其它也允许明文传输的协议来说其在协议层面就已经对数据安全做了第一道守护。由于NETCONF协议规定必须要支持SSH，所以目前SSH是NETCONF使用最广泛的传输层协议。

NETCONF的协议内容是承载在安全传输层之上的，所以NETCONF本身是一个应用层协议，NETCONF协议中并没有规定建链和保活相关的内容。

NETCONF中定义了三种消息类型，分别是hello， rpc和rpc-reply, notification。

Hello

仅用于回话刚刚建立时netconf-server和netconf-client之间进行能力交换。

server和client需要在回话建立后互相发送消息，并在消息中携带自身支持的能力，以及支持的netconf协议的版本号，server和client根据自身和对方的能力信息协商使用的netconf版本。

一般来说，C/S双方互发且协商版本成功后，认为netconf会话建立成功。

rpc和rpc-reply

是由netconf-client发起的发送到netconf-server的消息。用于client请求server执行某项具体的操作。

包含一个强制属性”message-id”，这个id是一个单调递增的正整数，同一会话内不能重复。该id用于和的配对。

是有netconf-server发送给netconf-client的rpc响应。不能主动发起，仅能在收到之后回复，切必须携带与收到的rpc相同的message-id。

在定义了两种默认的元素分别是和。表示未定义响应内容的rpc执行成功，而表示rpc执行失败。

notification

支持Notification上报的netconf-server需在能力交换时上报能力：

　　“urn:ietf:params:netconf:capability:notification:1.0”

几个关键的知识点：

• Netconf的通知采用的是订阅发布机制，server仅会向发送过订阅请求的client发送通知。
• Netconf的通知是以Stream进行分类的，不同类的Stream以不同的stream-name进行区分。netconf-server默认需要支持的stream-name是”NETCONF”。
• client不能重复下发订阅，即同一Stream的订阅不能重复下发，也不能同时订阅多个Stream，订阅可以设置定时取消，如果没有设置终止时间，取消订阅需要使用close-session或者kill-session。定时取消的订阅netconf的会话还是激活的，而使用close-session或者kill-session来取消的话，netconf会话会关闭。