|
NETCONF是基于XML的网络配置和管理协议，使用简单的基于RPC机制实现客户端和服务器之间通信。管理员可通过NETCONF协议实现本地管理，对远端设备的配置进行安装、修改和删除等操作。 协议架构NETCONF协议采用分层结构，划分为4层。每层分别对协议的某一方面进行包装，并向上层提供相关服务。分层结构使每层只关注协议的一个方面，实现起来更简单，同时使各层之间的依赖、内部实现的变更对其他层的影响降到最低。 | | | | | 传输层为NETCONF提供面向连接、可靠的、顺序的数据链路，NETCONF可以使用任何符合基本要求的传输层协议承载。 | | <rpc> <rpc-reply> <rpc-error> | 消息层提供了一种简单的、不依赖于传输协议的RPC请求和响应机制，通过使用<rpc>和<rpc-reply>元素分别对NETCONF请求和响应数据（操作层和内容层的内容）进行封装。 | | <get-config><edit-config><notification> | 操作层定义了一系列在RPC中应用的基本操作，这些操作组成了NETCONF基本能力。 | | | 内容层由管理数据内容的数据模型定义，描述了网络管理相关的配置数据和状态数据，这些数据依赖于各制造商设备，因此内容层是唯一没有被标准化的层。主流的数据模型有Schema、YANG。 |
会话建立过程- NETCONF Client和Server之间使用RPC机制进行通信。
- Client必须和Server成功建立一个安全的、面向连接的会话才能进行通信。
- Client向Server发送一个RPC请求，Server处理完请求后，给Client发送一个回应消息。
- Client的RPC请求和Server的回应消息全部使用XML编码。
- Client触发NETCONF会话建立，完成SSH连接建立，并进行认证与授权。
- Client和Server完成NETCONF会话建立和能力协商。
- Client发送请求给Server，进行RPC交互，如：
报文结构 | | | 信息码，由发起RPC请求的Client指定，Server收到RPC请求报文后保存message-id属性，在生成<rpc-reply>消息时使用。 | | | | | | | | | | 设置<edit-config>操作出现错误后，后续操作的处理方式 | | | | XML格式报文最后必须添加结束符]]>]]>，否则设备无法识别。 |
配置数据库介绍： - 配置数据库是关于设备的一套完整的配置参数的集合
- NETCONF基本模型中只存在<running/>配置数据库， 其他配置数据库可以由能力集定义
- 各数据库间可支持配置数据迁移
| | | 存放当前设备上运行的生效配置、状态信息等。该数据库必须存在，有且仅有一个。对该数据库进行修改操作，需支持writable-running能力。 | | 存放设备将要运行的配置数据，如需使用此数据库，需支持candidate能力，且对该数据库的任何改变不会直接影响网络设备。 | | 存放设备启动时所加载的配置数据，相当于已保存的配置文件。如需使用此数据库，则必须支持Distinct Startup能力。 |
能力集介绍： - 能力集是一组基于NETCONF协议实现的基础功能和扩展功能的集合。
- 每个能力使用一个唯一的URI进行标识。
- NETCONF协议允许Client与Server交互各自支持的能力集，Client只能发送Server支持的能力集范围内的操作请求。
分类： NETCONF基本能力定义的操作是NETCONF必须实现的功能的最小集合，包括9个基本操作： | | | 从<running>、<candidate/>和<startup/>配置数据库中获取配置数据， 通过<source>指定不同的配置数据库 | | 从<running/>配置数据库中获取设备配置数据和状态数据 | | | | | | |
标准能力集使NETCONF在容错性、可扩展性等方面得到加强，如 | | | 设备可以向客户端上报告警和事件，以便客户端及时感知设备配置等的变更 | | 设备可在<filter>元素中使用XPath表达式作为查询条件 |
设备制造商自己定义的能力集。
| 
发表于 2025-1-6 16:55:57