手册下载
H3C交换机 NETCONF API二次开发指南-6W100-整本手册.pdf (1.73 MB)
H3C 交换机NETCONF API二次开发指南
Copyright © 2022 新华三技术有限公司 版权所有,保留一切权利。
非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。
除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。
本文中的内容为通用性技术信息,某些信息可能不适用于您所购买的产品。
前 言
本文档主用来指导用户使用NETCONF客户端配置和管理设备。
前言部分包含如下内容:
· 读者对象
· 本书约定
· 资料意见反馈
本手册主要适用于如下工程师:
· 具有一定XML和NETCONF技术基础的网络规划人员
· 负责网络配置和维护,且具有一定XML和NETCONF技术基础的网络管理员
格 式 |
意 义 |
粗体 |
命令行关键字(命令中保持不变、必须照输的部分)采用加粗字体表示。 |
斜体 |
命令行参数(命令中必须由实际值进行替代的部分)采用斜体表示。 |
[ ] |
表示用“[ ]”括起来的部分在命令配置时是可选的。 |
{ x | y | ... } |
表示从多个选项中仅选取一个。 |
[ x | y | ... ] |
表示从多个选项中选取一个或者不选。 |
{ x | y | ... } * |
表示从多个选项中至少选取一个。 |
[ x | y | ... ] * |
表示从多个选项中选取一个、多个或者不选。 |
&<1-n> |
表示符号&前面的参数可以重复输入1~n次。 |
# |
由“#”号开始的行表示为注释行。 |
本书还采用各种醒目标志来表示在操作过程中应该特别注意的地方,这些标志的意义如下:
该标志后的注释需给予格外关注,不当的操作可能会对人身造成伤害。 |
|
提醒操作中应注意的事项,不当的操作可能会导致数据丢失或者设备损坏。 |
|
为确保设备配置成功或者正常工作而需要特别关注的操作或信息。 |
|
对操作内容的描述进行必要的补充和说明。 |
|
配置、操作、或使用设备的技巧、小窍门。 |
本书使用的图标及其含义如下:
该图标及其相关描述文字代表一般网络设备,如路由器、交换机、防火墙等。 |
|
该图标及其相关描述文字代表一般意义下的路由器,以及其他运行了路由协议的设备。 |
|
该图标及其相关描述文字代表二、三层以太网交换机,以及运行了二层协议的设备。 |
|
该图标及其相关描述文字代表无线控制器、无线控制器业务板和有线无线一体化交换机的无线控制引擎设备。 |
|
该图标及其相关描述文字代表无线接入点设备。 |
|
该图标及其相关描述文字代表无线终结单元。 |
|
该图标及其相关描述文字代表无线终结者。 |
|
该图标及其相关描述文字代表无线Mesh设备。 |
|
该图标代表发散的无线射频信号。 |
|
该图标代表点到点的无线射频信号。 |
|
该图标及其相关描述文字代表防火墙、UTM、多业务安全网关、负载均衡等安全设备。 |
|
该图标及其相关描述文字代表防火墙插卡、负载均衡插卡、NetStream插卡、SSL VPN插卡、IPS插卡、ACG插卡等安全插卡。 |
由于设备型号不同、配置不同、版本升级等原因,可能造成本手册中的内容与用户使用的设备显示信息不一致。实际使用中请以设备显示的内容为准。
本手册中出现的端口编号仅作示例,并不代表设备上实际具有此编号的端口,实际使用中请以设备上存在的端口编号为准。
如果您在使用过程中发现产品资料的任何问题,可以通过以下方式反馈:
E-mail:[email protected]
感谢您的反馈,让我们做得更好!
2.2 选择NETCONF客户端并确定客户端对设备的访问方式
2.4.2 配置NETCONF over SOAP over HTTP(或HTTPS)访问方式
2.5.2 使用NETCONF API文档构造NETCONF请求报文
2.6.3 客户端使用NETCONF over SSH访问方式连接到设备
2.6.4 客户端使用Telnet/SSH/Console以命令行方式连接到设备
6.3.4 查询(get-bulk/get-bulk-config)
7.1 附录 A Comware系统中NETCONF操作可能返回的错误说明
7.3 附录 C Comware Schema的Boolean/boolean说明
7.4 附录 D Comware NETCONF处理可能会遇到的情况建议
NETCONF(Network Configuration Protocol,网络配置协议)是一种基于XML的网络管理协议,它提供了一种可编程的、对网络设备进行配置和管理的方法。用户可以通过该协议设置属性、获取属性值、获取统计信息等。这使得它在第三方软件的开发上非常便利,很容易开发出在混合不同厂商、不同设备的环境下的特殊定制的网管软件。
NETCONF协议采用分层结构,分为内容层(Content)、操作层(Operations)、RPC(Remote Procedure Call,远程调用)层和通信协议层(Transport Protocol)等。
表1-1 XML分层与NETCONF分层模型对应关系
NETCONF分层 |
XML分层 |
说明 |
内容层 |
配置数据、状态数据、统计信息等 |
被管理对象的集合,可以是配置数据、状态数据、统计信息等 NETCONF协议具体可读写的数据请参见《NETCONF XML API 手册》 |
操作层 |
<get>,<get-config>,<edit-config>… |
在RPC中应用的基本的原语操作集,这些操作组成NETCONF的基本能力 NETCONF全面地定义了对被管理设备的各种基础操作,设备支持的操作请参见“1.6 Comware支持的协议操作” |
RPC层 |
<rpc>,<rpc-reply> |
为RPC模块的编码提供了简单的、传输协议无关的机制。通过使用<rpc>和<rpc-reply>元素分别对NETCONF请求和响应数据(即操作层和内容层的内容)进行封装 |
通信协议层 |
非FIPS模式下:Console/Telnet/SSH/HTTP/HTTPS/TLS FIPS模式下: Console/SSH/HTTPS/TLS |
为NETCONF提供面向连接的、可靠的、顺序的数据链路。 非FIPS模式下: · NETCONF支持Telnet、SSH和Console等CLI登录方式/协议,即NETCONF over SSH、NETCONF over Telnet和NETCONF over Console · NETCONF支持HTTP和HTTPS协议,即NETCONF over HTTP和NETCONF over HTTPS · NETCONF支持封装成SOAP(Simple Object Access Protocol,简单对象访问协议)报文后通过HTTP或HTTPS协议传输,即NETCONF over SOAP over HTTP和NETCONF over SOAP over HTTPS FIPS模式下: · NETCONF支持SSH和Console等CLI方式/协议,即NETCONF over SSH和NETCONF over Console · NETCONF支持HTTPS登录协议,即NETCONF over HTTPS · NETCONF支持封装成SOAP报文后通过HTTPS协议传输,即NETCONF over SOAP over HTTPS |
图1-1 NETCONF基本网络架构
NETCONF网络主要由NETCONF客户端和NETCONF服务器组成:
· 客户端上需要安装NETCONF客户端软件(如ncclient、NetconfBrowser),或运行基于SOAP请求的脚本或程序。客户端的主要作用为:
¡ 通过NETCONF协议对网络设备进行配置和管理。
¡ 主动查询网络设备的状态。
¡ 接收网络设备主动发送的告警和事件,以获知网络设备的当前状态。
· 服务器(即待管理网络设备)上需要运行NETCONF服务端程序,即支持NETCONF功能。服务器主要用于响应客户端的请求,并在发生故障或事件时,主动通告给客户端。
NETCONF命令必须符合XML语言的基本格式,格式遵循RFC 4741。
NETCONF报文分为请求和应答报文两种。NETCONF请求和应答报文的格式有所不同。
执行NETCONF请求前,需要先校验NETCONF报文的数据合法性。如果校验失败,则会向客户端报错。其中,数据合法性校验通过XML Schema的方式完成。
Comware NETCONF请求遵循NETCONF协议,其格式如下:
<rpc message-id =”101” xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<operation>
</rpc>
其中<operation>为“1.6 Comware支持的协议操作”中列举的支持的操作类型:
· 对于get系列操作,filter元素下为H3C自定义部分,以top元素为起点。以get-config操作为例,报文格式为:
<rpc message-id=”101” xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<get-config>
<source>
<running/>
</source>
<filter type=”subtree”>
<top xmlns=”http://www.h3c.com/netconf/config:1.0”>
模块信息
</top>
</filter>
</get-config>
</rpc>
· 对于edit-config操作,config元素下为H3C自定义部分,以top元素为起点。以edit-config操作为例,报文格式为:
<rpc message-id =”101” xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<top xmlns=”http://www.h3c.com/netconf/config:1.0”>
模块信息
</top>
</config>
</edit-config>
</rpc>
NETCONF可操作的数据项,即H3C自定义部分的语法结构,请参见《H3C Comware 7 NETCONF XML API Reference》文档。
如下为一个NETCONF请求报文示例,用于获取设备上所有接口的所有参数:
<?xml version="1.0" encoding="utf-8"?>
<rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-bulk>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface/>
</Interfaces>
</Ifmgr>
</top>
</filter>
</get-bulk>
</rpc>
]]>]]>
在XML视图下进行NETCONF配置时,XML报文最后需要添加“]]>]]>”,否则设备无法识别。为方便识别XML格式,本手册中,除上述举例外,均未添加此结束符。实际操作中,请自行添加。
统一为RFC 4741定义的<rpc-reply>,如:
<rpc-reply xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0” message-id=”101”>
<ok/>
</rpc-reply>
通过NETCONF over SOAP访问设备,NETCONF报文会封装在SOAP报文的BODY元素里,这些报文除了需要遵循纯NETCONF报文的规则外,还需要遵循以下规则:
· SOAP消息必须用XML来编码。
· SOAP消息必须使用SOAP Envelope命名空间和SOAP Encoding命名空间。
· SOAP消息不能包含DTD(Document Type Definition,文件类型定义)引用。
· SOAP消息不能包含XML处理指令。
NETCONF over SOAP请求和应答报文的格式有所不同。
如下为一个NETCONF over SOAP请求报文示例,用于获取设备上所有接口的所有参数:
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<auth:Authentication env:mustUnderstand="1" xmlns:auth="http://www.h3c.com/netconf/base:1.0">
<auth:AuthInfo>100002ea7bd8f3bbb727c5eff9b246d85be6</auth:AuthInfo>
</auth:Authentication>
</env:Header>
<env:Body>
<rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface/>
</Interfaces>
</Ifmgr>
</top>
</filter>
</get>
</rpc>
</env:Body>
</env:Envelope>
<env:Envelope xmlns:env=”http://schemas.xmlsoap.org/soap/envelope/”>
<env:Header>
<auth:Authentication env:mustUnderstand=”true” xmlns:auth=”http://www.h3c.com/netconf/base:1.0”>
<auth:AuthInfo>10027c2abebdb482633f847102fbc890d22a</auth:AuthInfo>
</auth:Authentication>
</env:Header>
<env:Body>
<rpc-reply message-id=”101” xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<data>
<top xmlns=”http://www.h3c.com/netconf/config:1.0”>
<Syslog>
<LogBuffer>
<BufferSize>527</BufferSize>
</LogBuffer>
<LogHosts>
<Host>
<Address>1.1.1.1</Address>
<VRF/>
<Port>123</Port>
<Facility>152</Facility>
</Host>
<Host>
<Address>1.1.1.1</Address>
<VRF>a</VRF>
<Port>123</Port>
<Facility>152</Facility>
</Host>
<Host>
<Address>1.1.1.1</Address>
<VRF>b</VRF>
<Port>123</Port>
<Facility>152</Facility>
</Host>
<Host>
<Address>1.1.1.1</Address>
<VRF>c</VRF>
<Port>123</Port>
<Facility>152</Facility>
</Host>
</LogHosts>
</Syslog>
</top>
</data>
</rpc-reply>
</env:Body>
</env:Envelope>
Comware NETCONF中,CLI操作返回的数据因为是命令行的原始输出,故统一使用CDATA标记来封装,以防止客户端程序解析XML出现错误。使用时,客户端需要从CDATA中抽取返回结果。
Comware NETCONF中,XML请求对注释没有要求,可以随意添加合法的注释。XML应答中不包含XML注释。
请求中,如果要保持两端的空格字符,必须对最开始和最后一个空格进行转义,转义遵循W3C XML规范。如果不进行转义,则两端连续的空格会被忽略。
应答元素的值中,两端最外侧的空格会被Comware NETCONF转义。
如果需要使用一个当前编码不能支持的字符时,可以使用标准的W3C XML规范来进行转义,比如	代表一个Tab键。
Comware NETCONF支持使用gb2312、GB18030、utf-8、utf-16、utf-16BE、utf-16LE、utf-32、utf-32BE、utf-32LE进行传输。默认情况下,如果请求中不指定XML传输格式,将使用utf-8作为默认编码,转换编码过程中,如果出现类似半个汉字之类无法转换的情况,将使用?来替代无法转换的字符。
表1-2 NETCONF相关协议规范
协议号 |
协议名称 |
支持情况 |
RFC 4741 |
NETCONF Configuration Protocol |
支持 |
RFC 4742 |
Using the NETCONF Configuration Protocol over Secure Shell (SSH) |
支持 |
RFC 4743 |
Using NETCONF over the Simple Object Access Protocol (SOAP) |
支持 |
RFC 4744 |
Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) |
不支持 |
RFC 5277 |
NETCONF Event Notifications |
支持 |
RFC 5381 |
Experience of Implementing NETCONF over SOAP |
支持 |
RFC 5539 |
NETCONF over Transport Layer Security (TLS) |
不支持 |
RFC 5717 |
Partial Lock Remote Procedure Call (RPC) for NETCONF |
不支持 |
RFC 6020 |
YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) |
支持 |
RFC 6021 |
Common YANG Data Types |
支持 |
RFC 6022 |
YANG Module for NETCONF Monitoring |
支持 |
RFC 6087 |
Guidelines for Authors and Reviewers of YANG Data Model Documents |
支持 |
RFC 6241 |
Network Configuration Protocol |
支持 |
RFC 6242 |
Using the NETCONF Protocol over Secure Shell (SSH) |
支持 |
RFC 6243 |
With-defaults Capability for NETCONF |
不支持 |
RFC 7950 |
The YANG 1.1 Data Modeling Language |
支持 |
Comware NETCONF支持的能力集如表1-3所示。除RFC中定义的标准能力集外,Comware NETCONF还定义了一些私有能力集。私有能力集没有对应的RFC,因此,私有能力集的RFC列取值为“-”。
表1-3 Comware NETCONF的能力集支持情况
RFC |
能力集 |
支持情况 |
RFC 4741 |
Base 1.0 urn:ietf:params:netconf:base:1.0 |
支持 |
RFC 4741 |
Writable-Running urn:ietf:params:netconf:capability:writable-running:1.0 |
支持 |
RFC 4741 |
Candidate Configuration urn:ietf:params:netconf:capability:candidate:1.0 |
不支持 |
RFC 4741 |
Confirmed Commit 1.0 urn:ietf:params:netconf:capability:confirmed-commit:1.0 |
不支持 |
RFC 4741 |
Rollback on Error urn:ietf:params:netconf:capability:rollback-on-error:1.0 |
支持 |
RFC 4741 |
Validate 1.0 urn:ietf:params:netconf:capability:validate:1.0 |
支持 |
RFC 4741 |
Distinct Startup urn:ietf:params:netconf:capability:startup:1.0 |
不支持 |
RFC 4741 |
URL urn:ietf:params:netconf:capability:url:1.0?scheme={name,...} |
不支持 |
RFC 4741 |
XPATH urn:ietf:params:netconf:capability:xpath:1.0 |
不支持 |
RFC 5277 |
Interleave urn:ietf:params:netconf:capability:interleave:1.0 |
支持 |
RFC 6022 |
Yang urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring |
支持 |
RFC 6241 |
Validate 1.1 urn:ietf:params:netconf:capability:validate:1.1 |
支持 |
RFC 6241 |
Confirmed Commit 1.1 urn:ietf:params:netconf:capability:confirmed-commit:1.1 |
不支持 |
RFC 6242 |
Base 1.1 urn:ietf:params:netconf:base:1.1 |
不支持 |
- |
h3c-netconf-ext:1.0 urn:h3c:params:netconf:capability:h3c-netconf-ext:1.0 |
支持 |
- |
h3c-save-point:1.0 urn:h3c:params:netconf:capability:h3c-save-point:1.0 |
支持 |
- |
h3c-name2index:1.1 urn:h3c:params:netconf:capability:h3c-name2index:1.1 |
支持 |
- |
not-need-top:1.0 urn:h3c:params:netconf:capability:not-need-top:1.0 |
支持 |
- |
module-specified-namespace:1.0 urn:h3c:params:netconf:capability:module-specified-namespace:1.0 |
支持 |
- |
h3c-lightrollback:1.0 urn:h3c:params:netconf:capability:h3c-lightrollback:1.0 |
支持 |
- |
full-replace:1.0 urn:h3c:params:netconf:capability:full-replace:1.0 |
支持 |
Comware NETCONF支持的协议操作如表1-4所示。
表1-4 Comware NETCONF对协议操作的支持情况
RPC操作名称 |
说明 |
支持情况 |
action |
修改、获取运行统计信息之类的动作 |
支持 |
CLI |
作为NETCONF的补充,执行NETCONF尚未提供的命令 |
支持 |
commit |
把候选库的配置提交到生效库 |
不支持 |
cancel-commit |
取消已提交到运行数据库中的候选数据库配置 |
不支持 |
close-session |
关闭当前会话 |
支持 |
copy-config |
配置库拷贝 |
不支持 |
create-subscription |
事件订阅 |
支持 |
delete-config |
删除配置 |
不支持 |
discard-changes |
放弃变更 |
不支持 |
edit-config |
配置修改 |
支持 |
get |
获取设备数据 |
支持 |
get/filter/netconf |
获取系统支持的事件流 |
支持 |
get/filter/netconf-state |
获取系统NETCONF状态信息 |
支持 |
get-bulk |
批量获取设备数据 |
支持 |
get-bulk-config |
批量获取设备配置数据 |
支持 |
get-config |
获取设备配置数据 |
支持 |
get-sessions |
获取NETCONF会话信息 |
支持 |
kill-session |
关闭非当前会话 |
支持 |
load |
配置加载 |
支持 |
lock |
加锁NETCONF |
支持 |
rollback |
配置回滚 |
支持 |
save |
配置保存 |
支持 |
unlock |
解锁NETCONF |
支持 |
validate |
NETCONF请求的XML语法检查 |
支持 |
get-schema |
获取YANG/Schema模型文件 |
有限支持 目前,设备只为部分模块提供了YANG文件 |
cancel-subscription |
取消订阅 |
支持 |
action、CLI、get-bulk、get-bulk-config、get-sessions、load、save、rollback和cancel-subscription为Comware扩展的私有操作。Comware还为get和get-config操作增加了count属性。各操作的详细介绍,请参见“4 执行Comware NETCONF请求”。
管理员通过NETCONF客户端配置和管理设备时,通常需要按照如下流程来操作:
(1) 选择NETCONF客户端并确定客户端对设备的访问方式
Comware支持如下NETCONF访问方式:
¡ NETCONF over Telnet
¡ NETCONF over Console
¡ NETCONF over SSH
¡ NETCONF over SOAP over HTTP
¡ NETCONF over SOAP over HTTPS
需要根据NETCONF客户端的实际组网环境和需求,选择合适的访问方式。
不同访问方式需要的用户权限不同:
¡ NETCONF over SOAP over HTTP访问方式,需要为用户设置HTTP访问权限。
¡ NETCONF over SOAP over HTTPS访问方式,需要为用户设置HTTPS访问权限。
¡ NETCONF over SSH访问方式,需要为用户设置SSH访问权限。
(3) 在设备上进行访问方式相关配置
依据需要使用的访问方式,打开对应的功能。
根据需访问模块的API文档,构造NETCONF XML请求。
(5) 准备NETCONF客户端
按照RFC 4741的描述准备客户端软件、基于SOAP请求的脚本或程序,使其能发送hello和close-session。具体方法请参见客户端软件的操作指导等。
依据需要使用的访问方式,使用准备好的NETCONF客户端连接到设备。
测试建立连接(hello)和断开连接(close-session)的能力,使后续工作能够正常进行。
使用工具或命令行XML方式来验证XML报文的正确性。
(9) 将请求集成到客户端脚本或程序
把测试好的XML报文集成到客户端程序中。
(10) (可选)最佳实践建议
通过NETCONF客户端配置和管理设备时,在某些特殊情况下需要进行特殊处理。例如,容错处理、大数据量处理、并发处理等。
(11) (可选)常见问题及处理方法
完成上述操作后,即可使用NETCONF客户端程序执行NETCONF操作管理设备。Comware支持操作的详细介绍,请参见“4 执行Comware NETCONF请求”。
用户可通过以下方式来使用NETCONF配置和管理设备:
· 通过Telnet、SSH或Console登录到设备并进入XML视图,将合法的NETCONF报文(报文格式请参见“1.3.1 NETCONF”)直接拷贝、粘贴到命令行中执行,即可实现对设备的配置和管理。该方式一般用于研发和测试环境。
· 使用配置工具与设备建立连接并向设备下发NETCONF指令来实现对设备的配置和管理。配置工具支持以下两种传输方式:
¡ NETCONF over SSH传输方式:配置工具采用该方式与设备建立SSH连接后,可下发NETCONF格式报文(报文格式请参见“1.3.1 NETCONF”)配置和管理设备。
¡ NETCONF over SOAP传输方式:该方式通过HTTP/HTTPS与设备建立连接,并将NETCONF指令用SOAP封装成通用格式的报文后发送给设备,报文格式请参见“1.3.2 NETCONF over SOAP”。使用该方式前设备上必须开启NETCONF over SOAP功能。
客户可以根据需要选择NETCONF传输方式,开发和定制自己专用的配置工具软件,也可以使用第三方开发的配置工具。第三方的配置工具有:
· 采用NETCONF over SSH传输方式配置工具:NETCONF Browser等。
· 采用NETCONF over SOAP传输方式配置工具:SOAP UI等。
关于各配置工具的使用方法,请参见配置工具的使用指导文档。
H3C设备目前支持如下访问方式:
非FIPS模式下:
· NETCONF over SSH
· NETCONF over Telnet
· NETCONF over Console
· NETCONF over SOAP over HTTP
· NETCONF over SOAP over HTTPS
FIPS模式下:
· NETCONF over SSH
· NETCONF over Console
· NETCONF over SOAP over HTTPS
使用不同配置方式时,需要使用的访问方式不同:
· 使用Telnet或SSH登录到设备,进入XML视图执行NETCONF配置时,需要使用NETCONF over Telnet访问方式。
· 使用Console登录到设备,进入XML视图执行NETCONF配置时,需要使用NETCONF over Console访问方式。
· 使用SSH配置工具(例如NETCONF Browser)执行NETCONF配置时,需要使用NETCONF over SSH访问方式。
· 使用SOAP配置工具下发NETCONF指令配置设备时,需要使用NETCONF over SOAP over HTTP或NETCONF over SOAP over HTTPS方式。
使用配置工具与设备建立NETCONF连接前,需要确保NETCONF用户具有对应的操作权限。
Comware通过RBAC(Role Based Access Control,基于角色的访问控制)实现基于角色的用户访问权限控制。RBAC对用户权限的控制包括用户角色规则和资源控制策略两个方面:
· 用户角色规则用来控制用户对系统功能的操作权限。例如,定义用户角色规则允许用户配置A功能,或禁止用户配置B功能。
· 资源控制策略用来控制用户对系统资源的操作权限。例如,定义资源控制策略允许用户操作VLAN 10。
在用户角色规则方面,NETCONF用户角色需要具有如下权限:
· 执行NETCONF操作需要具有执行XML元素NETCONF RPC节点的权限,不同NETCONF操作需要的权限不同,具体请参见表2-1。
· 执行NETCONF操作内容的权限,即用户执行XML元素(具体模块或模块中表的Xpath)的权限。例如,配置用户具有执行接口模块XML元素的权限时,需要执行rule number permit read write execute xml-element ifmgr/命令。
在资源策略方面,可以根据实际需要配置用户角色操作接口、VLAN、VPN、安全域的权限。缺省情况下,用户具有操作所有资源的权限。
不同用户角色的操作权限有所不同:
· 缺省用户角色network-admin、mdc-admin、context-admin具有操作对应设备/MDC/Context的所有功能和资源(除安全日志文件管理相关命令display security-logfile summary、info-center security-logfile directory、security-logfile save之外)的权限。如果用户所属角色是这几种,则只需要指定用户角色为network-admin、mdc-admin或context-admin即可。
· 缺省用户角色network-operator、context-operator和mdc-operator默认只有读权限和部分可执行权限,必须事先配置后才有对应的操作权限。
· 其他用户角色必须事先配置后才有对应的操作权限。
NETCONF操作需要权限的详细介绍请见表2-1。
表2-1 执行NETCONF操作需要配置的权限
执行的NETCONF操作 |
需要配置的权限节点 |
需要配置的权限 |
建立NETCONF会话 |
不涉及 |
执行xml命令的权限 对于NETCONF over Telnet、NETCONF over Console访问方式,用户必须具有执行xml命令行的权限,否则无法进入XML视图 |
向设备订阅事件 |
rpc/create-subscription |
execute |
给当前配置加锁 |
rpc/lock |
execute |
给当前配置解锁 |
rpc/unlock |
execute |
使用<get>获取信息 |
rpc/get |
read |
使用<get>获取NETCON状态信息 |
rpc/get/filter/netconf-state |
read |
使用<get-bulk>获取信息 |
rpc/get-bulk |
read |
使用<get-config>获取配置信息 |
rpc/get-config |
read |
使用<get-bulk-config>获取配置信息 |
rpc/get-bulk-config |
read |
使用<get-schema>获取yang文件信息 |
rpc/get-schema |
read |
<edit-config>编辑指定模块数据 |
rpc/edit-config |
write |
执行一个<action>操作 |
rpc/action |
execute |
配置保存 |
rpc/save |
write |
配置回滚 |
rpc/rollback |
write |
配置加载 |
rpc/load |
write |
命令行操作 |
rpc/CLI |
write |
获取会话信息 |
rpc/get-sessions |
read |
关闭另一个会话 |
rpc/kill-session |
execute |
执行语法验证 |
rpc/validate |
read |
配置回滚点 |
rpc/save-point |
write |
候选库配置提交 |
rpc/commit |
execute |
取消已提交的配置 |
rpc/cancel-commit |
execute |
复制数据库 |
rpc/copy-config |
execute |
删除数据库 |
rpc/delete-config |
execute |
删除候选库配置 |
rpc/discard-changes |
execute |
预配置 |
rpc/config-provisioned |
execute |
退出XML视图 |
不涉及 |
执行xml命令的权限 |
取消当前订阅事件 |
rpc/cancel-subscription |
execute |
(1) 进入系统视图。
system-view
(2) 创建用户角色,并进入用户角色视图。
role name role-name
(3) 请根据需要配置用户操作权限的规则。
¡ 配置用户具有执行XML元素NETCONF RPC节点的权限。
rule number permit { execute | read | write } * xml-element rpc/
通过rule number permit { execute | read | write } * xml-element rpc/?可以查看具体操作的列表。不指定具体操作时,表示所有操作。
¡ 配置用户执行XML元素具体模块的权限。
rule number { deny | permit } { execute | read | write } * xml-element [ module-xpath ]
通过rule number { deny | permit } { execute | read | write } * xml-element ?可以查看具体模块列表,通过rule number { deny | permit } { execute | read | write } * xml-element module-name/?可以查看模块中具体表的列表。不指定具体模块和表时表示所有模块/所有表。
本配置用来为NETCONF用户指定如下属性:
· 根据NETCONF访问方式,指定正确的服务类型:使用NETCONF over SSH访问方式时,用户的服务类型为SSH;使用NETCONF over SOAP over HTTP访问方式时,用户的服务类型为HTTP;使用NETCONF over SOAP over HTTPS访问方式时,用户的服务类型为HTTPS。
· 为用户指定用户角色,使其具有所需权限。
本文以本地认证为例,介绍配置过程。使用远程认证的配置方式请参见产品对应版本的AAA配置指导。
(1) 进入系统视图。
system-view
(2) 添加设备管理类本地用户,并进入设备管理类本地用户视图。
local-user user-name class manage
(3) 设置本地用户的密码。
(非FIPS模式)
password [ { hash | simple } string ]
(FIPS模式)
password
在非FIPS模式下,可以不为本地用户设置密码;在FIPS模式下,必须且只能通过交互式方式设置明文密码,否则用户的本地认证不能成功。
(4) 设置本地用户可以使用的服务类型。请根据访问方式选择其中一项进行配置
¡ 使用NETCONF over SSH访问方式:
service-type ssh
¡ 使用NETCONF over SOAP over HTTP或NETCONF over SOAP over HTTPS访问方式:
(非FIPS模式)
service-type { http | https } *
(FIPS模式)
service-type https
缺省情况下,本地用户不能使用任何服务类型。
(5) 设置本地用户的角色。
authorization-attribute user-role role-name
以下配置步骤只介绍采用password方式认证SSH客户端的配置方法,publickey方式的配置方法及SSH的详细介绍,请参见“安全配置指导”中的“SSH”。
(1) 进入系统视图。
system-view
(2) 生成本地密钥对。
(非FIPS模式)
public-key local create { dsa | ecdsa [ secp192r1 | secp256r1 | secp384r1 | secp521r1 ] | rsa } [ name key-name ]
(FIPS模式)
public-key local create { dsa | ecdsa [ secp256r1 | secp384r1 | secp521r1 ] | rsa } [ name key-name ]
(3) (可选)创建SSH用户,并指定SSH用户的服务类型为NETCONF,认证方式为password。
ssh user username service-type netconf authentication-type password
(4) 进入VTY用户线或VTY用户线类视图。
¡ 进入VTY用户线视图。
line vty first-number [ last-number ]
¡ 进入VTY用户线类视图。
line class vty
(5) 配置VTY用户线的认证方式为scheme方式。
(非FIPS模式)
authentication-mode scheme
缺省情况下,VTY用户线的认证方式为password方式。
(FIPS模式)
authentication-mode scheme
缺省情况下,VTY用户线的认证方式为scheme方式。
(1) 进入系统视图。
system-view
(2) 开启NETCONF over SSH。
netconf ssh server enable
缺省情况下,NETCONF over SSH处于关闭状态。
(3) 配置NETCONF over SSH的监听端口。
netconf ssh server port port-number
缺省情况下,NETCONF over SSH的监听端口为830。
(4) (可选)开启NETCONF日志功能。
netconf log source { all | { agent | soap | web } * } { protocol-operation { all | { action | config | get | set | session | syntax | others } * } | row-operation | verbose }
缺省情况下,NETCONF日志功能处于关闭状态。
(5) 通过SSH配置工具与设备建立NETCONF over SSH会话。关于SSH配置工具的使用方法,具体参见SSH配置工具的配置指导。
使用NETCONF over SOAP over HTTP或NETCONF over SOAP over HTTPS访问方式时,配置工具将配置指令封装成SOAP报文后通过HTTP或HTTPS协议传输到设备。
本文仅介绍基本配置,有关SOAP报文的DSCP优先级、NETCONF客户端访问控制、NETCONF用户使用的认证域等相关内容请参见产品对应版本的NETCONF配置、NETCONF命令手册。
(1) 进入系统视图。
system-view
(2) 开启NETCONF over SOAP功能。
(非FIPS模式)
netconf soap { http | https } enable
(FIPS模式)
netconf soap https enable
缺省情况下,NETCONF over SOAP处于关闭状态。
(3) (可选)开启NETCONF日志功能。
netconf log source { all | { agent | soap | web } * } { protocol-operation { all | { action | config | get | set | session | syntax | others } * } | row-operation | verbose }
缺省情况下,NETCONF日志功能处于关闭状态。
(4) 通过配置工具与设备建立NETCONF over SOAP会话。关于配置工具的使用方法,具体参见配置工具的配置指导。
Comware NETCONF API文档描述的是全集,需要结合设备的XSD文件来查看当前设备的支持情况。设备可能不支持某些功能、某些表格或某些列。
NETCONF API文档分属于四个命名空间:
· data命名空间:提供系统的运行状态数据和配置数据,为只读,支持下发get和get-bulk操作。
· config命名空间:提供系统的配置数据信息,可读写,支持下发get-config、get-bulk-config和edit-config操作。
· action命名空间:通常提供系统非配置类的操作(如ping、reset操作),可执行,支持下发action操作。
· event命名空间:提供系统的事件数据信息,支持通过create-subscription操作订阅指定类型的事件。
每一个支持NETCONF的模块都包括一个或者多个NETCONF API文档,分别描述其在data命名空间、config命名空间、action命名空间和event命名空间的功能。文档命名遵循如下格式,其中XXX代表模块名:
· data命名空间:Comware XXX NETCONF XML API Data Reference.docx
· config命名空间:Comware XXX NETCONF XML API Configuration Reference.docx
· action命名空间:Comware XXX NETCONF XML API Action Reference.docx
· event命名空间:Comware XXX NETCONF XML API Event Reference.docx
NETCONF模块可能还存在一个名为Comware XXX NETCONF XML API Error Message Reference.docx的模块错误提示信息参考文档,该文档用来描述模块操作过程中的各种错误。
每一个NETCONF API文档对应一个功能模块,如ARP、DHCP。每个模块由一个或者多个表组成。表以行和列的形式进行组织:
· 行:表示一个对象实例。
· 列:表示每个对象实例中包含的信息。
以ARP表为例,一条ARP表项为一行,ARP表项中的IP地址、MAC地址、所属VLAN等为列。
在NETCONF API文档中,每个表包含下面几个部分的信息:
· 表名称:提供了从模块开始的路径和最终的表名,如:ACL/Base
· 表的XML结构(XML structure):列举了本表从模块开始的XML表示方式,但不包括值信息,例如:
· 表描述(Table description):提供模块名称、表名称、表类型、行名称和约束信息。其中,表类型取值包括:
¡ Multi-instance table:多实例表格,表示该表可以包含多行。
¡ Single-instance table:单实例表格,表示该表能包括一行。
· 列详细信息(Columns):提供列名称、列描述、列数据类型和约束条件等信息。列数据类型取值包括:
¡ Index:表示该列为表格的索引列。
¡ N/A:表示该列不作为索引列。
· 应答的XML结构(Responsed XML structure):列举了本表从模块开始应答消息的XML表示方式,但不包括值信息。客户端可以依据返回结果来判断操作执行的效果。仅action命名空间中可以返回操作结果的表提供此信息。例如:
· 应答列详细信息(Responsed columns):用来描述应答XML结构中的各列。
NETCONF API文档介绍了NETCONF请求报文(参见“1.3 NETCONF报文格式”)中H3C自定义部分的模块信息语法。构造某一请求时,需要先根据操作类型查找对应模块、对应空间的API文档来获取需要的XML结构,如表2-2所示。
表2-2 操作类型与API文档对应关系
操作类型 |
需查询的API文档 |
<get> <get-bulk> |
Comware XXX NETCONF XML API Data Reference.docx 例如,接口管理请查询《Comware Ifmgr NETCONF XML API Data Reference.docx》 |
<get-config> <get-bulk-config> <edit-config> |
Comware XXX NETCONF XML API Configuration Reference.docx 例如,接口管理请查询《Comware Ifmgr NETCONF XML API Configuration Reference.docx》 |
<action> |
Comware XXX NETCONF XML API Action Reference.docx 例如,接口管理请查询《Comware Ifmgr NETCONF XML API Action Reference.docx》 |
<create-subscription> |
Comware XXX NETCONF XML API Event Reference.docx 例如,接口管理请查询《Comware Ifmgr NETCONF XML API Event Reference.docx》 |
获取到所需模块的NETCONF API文档后,应当先确认需要的功能是否已经支持。若已经支持,则可以依据真实需求,构造所需报文。一般情况下,可以从对应的表的XML Structure部分开始,依据如下步骤构造NETCONF请求:
(1) 构造XML请求的协议定义部分,即top外层的部分。
以get操作为例,top以外的部分为协议定义部分,可以直接从现有请求或者本文档拷贝。
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter>
<top xmlns="http://www.h3c.com/netconf/data:1.0">
指定模块,子模块,表名,列名
</top>
</filter>
</get>
</rpc>
其他操作的协议定义部分格式,请参见“4 执行Comware NETCONF请求”。
(2) 构造top元素。
top元素的格式通常为:<top xmlns="http://www.h3c.com/netconf/data:1.0">。其中,http://www.h3c.com/netconf/data:1.0为H3C自定义的命名空间,需要根据需要设置为data、config或action命名空间,即data:1.0也可根据需要设置为config:1.0或action:1.0。
(3) 构造模块操作部分。
拷贝NETCONF API文档中表格XML结构到“指定模块,子模块,表名,列名”部分,然后依据实际情况删除不需要的列或者为已知列赋值。
目前产品发布时,会同步发布该产品支持的XSD文件。用户也可以根据XSD文件构造NETCONF请求。构造方法与NETCONF API类似,本文不再赘述。
Comware NETCONF请求遵循NETCONF协议,可通过get-schema操作获取设备上某个YANG文件内容,通过获取netconf-state操作获取设备上所有YANG文件列表,详细介绍请参见“4.2.10 get-schema 操作”和“4.2.11 获取netconf-state操作”。
用户也可以根据YANG文件构造NETCONF请求。构造方法与NETCONF API类似,本文不再赘述。
Comware目前支持使用NETCONF over Telnet、NETCONF over Console、NETCONF over SSH、NETCONF over SOAP over HTTP、NETCONF over SOAP over HTTPS几种方式访问NETCONF功能。按其访问方式不同,NETCONF的访问方式可以分为下面3类:
· 客户端使用SOAP方式连接到设备:即NETCONF over SOAP over HTTP和NETCONF over SOAP over HTTPS方式。
· 客户端使用NETCONF over SSH访问方式连接到设备:即NETCONF over SSH方式。
· 客户端使用Telnet/SSH/Console以命令行方式连接到设备:即NETCONF over Telnet、NETCONF over Console和NETCONF over SSH方式。
使用前,需要先确定NETCONF客户端选取的访问方式,并在设备上使能对应的功能。使能对应功能后,NETCONF客户端即可使用对应的连接手段访问设备的NETCONF功能。
配置完设备后,客户端通过HTTP/HTTPS协议,向设备的80端口(HTTP)或者832端口(HTTPS)的URL地址/soap/netconf/,发送SOAP包装过的NETCONF xml请求来进行配置。例如,设备地址为192.168.1.1,则请求地址为:
· HTTP方式:http://192.168.1.1/soap/netconf/
· HTTPS方式:https://192.168.1.1:832/soap/netconf/
· HTTP/HTTP URL地址中最后的反斜杠(/)不可省略。
· 80为HTTP方式的缺省端口号,832为HTTPS方式的缺省端口号。可以通过命令行修改端口号。
如图2-1所示,基于SOAP的报文格式,本质是HTTP报文,其格式可分为3个层次:
· 外层:HTTP报文头
· 中间层(HTTP内容):SOAP格式的报文
· SOAP内层(Body部分):NETCONF RPC报文。
图2-1 基于SOAP的报文格式
如图2-1所示,登录时,用户名和密码分别放在元素\Envelope\Header\Authentication\UserName和元素\Envelope\Header\Authentication\Password中。
其中,元素Authentication必须满足原则:
· 属于命名空间http://www.h3c.com/netconf/base:1.0。
· 具有http://www.w3.org/2003/05/soap-envelope命名空间下的mustUnderstand属性,且属性值必须为1或者true。
如图2-2所示,登录成功后,返回的元素\Envelope\Header\Authentication\AuthInfo的值为下次请求的凭据,客户端必须保留此凭据作为下次请求的凭证。
必须使用hello报文返回的凭据作为下次请求的依据,才能成功进行登录后的请求,凭据放在\Envelope\Header\Authentication\AuthInfo中。
设备支持中文和英文,可以通过在请求中指定语言的方式来强迫设备在遇到错误时,返回指定语言的错误提示。如图2-3所示,语言放在元素\Envelope\Header\Authentication\Language中,中文取值为zh-cn,英文取值为en,不提供Language时默认为英文。
Language必须放在元素AuthInfo的后面。
并不是所有的请求应答消息都支持中文。应答消息实际使用的语言,请以返回的属性 xml:lang=”xx”的指示为准。
图2-4 应答消息实际采用的语言
· 第一个Hello报文和认证是同时进行的。
· 连接为短连接,发送每个请求并接收到应答后,断开与服务器的连接。因此不支持事件订阅。
· 所有请求和正常应答都在外层封装一个SOAP层,只有Body层才封装RPC请求。
· 基于SOAP的NETCONF请求支持多线程并行发送请求,但不要在同一个会话中超过4个并发,一个会话超过4个并发的请求会被拒绝并返回资源不足的错误。
在设备上完成NETCONF over SSH连接相关配置后,客户端可通过NETCONF over SSH访问方式来配置和管理设备。访问过程遵循RFC 4742。
一般情况下,客户端需要提供IP地址、用户名、密码、子系统、端口这几个信息。
Banner、欢迎、前置法律告警在下发到NETCONF over SSH之前可能会被传递到客户端,这些信息应当被客户端忽略。
客户端通过Telnet、SSH或Console方式登录设备的命令行终端后,执行xml命令进入XML视图,将合法的NETCONF报文直接拷贝、粘贴到命令行提示符处执行,即可实现对设备的配置和管理。
使用Telnet/SSH/Console/NETCONF over SSH模式连接成功后,会收到服务器发送的hello报文,格式如下,收到后即可确认和设备连接是正常的:
<?xml version=”1.0” encoding=”UTF-8”?><hello xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability><capability>urn:ietf:params:netconf:capability:notification:1.0</capability><capability>urn:ietf:params:netconf:capability:validate:1.0</capability><capability>urn:ietf:params:netconf:capability:interleave:1.0</capability><capability>urn:h3c:params:netconf:capability:h3c-netconf-ext:1.0</capability></capabilities><session-id>1</session-id></hello>
使用SOAP方式连接后,收到如下格式的hello报文,可确认NETCONF客户端和设备连接是正常的:
<env:Envelope xmlns:env=”http://www.w3.org/2003/05/soap-envelope”>
<env:Header>
<auth:Authentication env:mustUnderstand=”true” xmlns:auth=”http://www.h3c.com/netconf/base:1.0”>
<auth:AuthInfo>1001e17d1916e60ef0068f3c6387d4410a1b</auth:AuthInfo>
</auth:Authentication>
</env:Header>
<env:Body>
<hello xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
<capability>urn:h3c:params:netconf:capability:h3c-netconf-ext:1.0</capability>
</capabilities>
<session-id>1</session-id>
</hello>
</env:Body>
</env:Envelope>
建立NETCONF连接后,客户端和设备必须交换各自支持的能力集,双方收到对方的能力集后才可以进行下一步操作。
设备会发送如下报文自动告知客户端支持的NETCONF能力集:
· <capabilities>和</capabilities>之间的内容表示设备支持的能力集,以设备实际返回值为准。
· <session-id>和</session-id>之间的内容表示为本次会话分配的会话ID,用来唯一标识本次会话。
客户端收到设备发送的能力集协商报文后,需要给设备发送如下格式的报文,告知设备客户端支持哪些NETCONF能力集。
Hello协商报文格式如下:
<hello xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<capabilities>
<capability>
capability-set
</capability>
</capabilities>
</hello>
其中,capability-set表示客户端支持的能力集,由用户定义。一个<capability>和</capability>选项对中填写一个能力集,可以使用多个选项对,发送多个能力集。
对于NETCONF over SSH功能,按照协议规定,如果两者都有Base 1.1的能力,将自动使用Base1.1规定的访问方式进行通信,故客户端需要检查服务器返回的能力集,依据能力集进行通信协议调整。
<rpc message-id=”101” xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<close-session/>
</rpc>
对于处于XML视图的用户,要退回到用户视图,使用命令行来配置设备时,需要将以上报文拷贝、粘贴到客户端,才能退出XML视图。
<?xml version=”1.0” encoding=”UTF-8” ?>
<rpc-reply message-id=”101” xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<ok/>
</rpc-reply>
连接到设备后,使用准备好的XML来查看请求是否正确。
推荐使用SOAP UI开源工具或者直接使用命令行XML方式来验证。
SOAP UI执行的结果,如图2-5所示。
图2-5 SOAP UI下发XML请求及返回结果举例
使用命令行方式验证时,需要注意:
· 尽量避免在Console上使用,推荐在Telnet或者SSH下使用命令行的方式进行验证。由于串口上存在速度限制,且XML下无回显,在Console口上使用命令行方式验证很容易出现错误。
· 尽量避免手敲,尽可能拷贝和粘贴准备好的XML脚本。
· 与SOAP方式不同,命令行模式需要]]>]]>作为结束符。
当准备好的XML经过验证是正确的后,可以把验证好的XML集成到自己的客户端程序中。如果是无人值守的程序,需要考虑超时、断线等异常情况,以保证长时间情况下也能正确运行。
客户端应答需要考虑在某些情况下的异常恢复,如连接断开的情况、XML应答结果不是良好格式的情况、长时间不能得到结果的情况。
系统中部分表的数据量可能非常大,不适合在一次请求中把数据全部取出,此时可以考虑使用get-bulk操作配合count属性。每次获取一定量的数据,取完需要下一批数据时,使用最后一条数据的索引为条件,继续使用get-bulk,直到获取到所有的数据为止。
另外,在处理大数据量请求时,请考虑TCP底层超时的情况发生,需要适当放大底层TCP timeout参数的值,最好在客户端部署到生产环境前对最大数据情况进行模拟,以期找到一个合适的超时时间。
系统支持多个用户或者会话同时下发NETCONF请求,但需要注意的是:
· 多个edit-config同时来变更系统时,如果不加锁,系统最终状态不一定是最终要求的状态。如果携带了错误后自动回滚的选项(edit-config携带的error-option取值为rollback-on-error,详细介绍请参见表4-7),则多人情况下,可能会回退他人的修改。如果有可能,应当避免多个NETCONF客户端同时修改系统,或者对所有请求进行加锁后再下发。加锁方法的详细介绍,请参见“4.2.3 lock操作”。
· 通过lock操作对当前NETCONF会话加锁后,用户仅可以通过该NETCONF会话配置设备。无法通过其他NETCONF会话、其他配置方式(如命令行或SNMP)配置设备。
· 多个get系列操作或者edit-config请求并发时,不能保证一定得到线性的性能提升,视请求占用资源的情况,随着请求的数量增加,单个请求响应时间会加长,整体时间的缩短逐渐减小。
通过SOAP发送请求时,当不再使用会话时,建议使用close-session请求关闭当前会话。但需要注意的是:通过close-session关闭会话后,客户端有可能无法收到应答。
当debug开关打开时,设备可能会生成大量的debug日志,导致正常响应滞后。因此,不建议通过NETCONF接收Debug级别的日志。
SOAP同时支持HTTP和HTTPS用户,但不能串用:不能用HTTP登录后,使用HTTP的AuthInfo通过HTTPS访问;反之亦然。
可能的原因是输入没有完成,可以通过手工敲入]]>]]>查看是否真的没有反应。一般情况下,输入]]>]]>后能看到一个应答,提示XML输入错误。为了解决该问题,需要在确认输入XML无误的情况下,使用拷贝粘贴的方式进行,不要手工敲击XML命令片段。
· 由于Console口的速率限制问题,在Console口上即使拷贝粘贴,也可能出现丢失字符导致无法正确解析和应答的情况。除非对Comware系统非常熟悉,否则,不要在Console上直接敲XML命令。
· 如果已经在Console敲了XML命令,可以通过输入]]>]]>之后准备一个close-session消息,拷贝粘贴后等待退出。close-session消息的详细介绍,请参见“2.7.2 断开NETCONF连接”。
因为系统中某些请求可能耗时很长,对于SOAP方式的请求,客户端软件可能设置了服务器的应答超时时间。当响应时间超过超时时间时,客户端软件直接返回失败。
为避免上述情况发生,建议:
· 逐渐调整客户端socket的超时时间,使之处于一个合适的数值。
· 通过过滤功能对需要获取的数据进行过滤,尽量避免获取整机数据。过滤功能的详细介绍,请参见“5 Comware NETCONF数据过滤功能”。
设备上可使用表2-3和表2-4中的命令辅助调试NETCONF功能。
命令 |
目的 |
display tcp |
查看设备是否监听指定端口,是否存在对应服务的连接 |
命令 |
目的 |
display tcp |
查看设备是否监听指定端口,是否存在对应服务的连接 |
display ssh server session |
查看是否存在活跃的NETCONF over SSH会话 |
netconf log |
查看NETCONF请求的日志和处理结果 |
对于基于SOAP的会话,从第一个hello报文建立连接开始建立会话,在以下情况下关闭会话:
· 发送close-session主动断开会话。
· 被其他用户通过kill-session关闭会话。
· 会话闲置时间超期。
会话期间,属于此会话的每一个请求都是一个新的TCP连接,应答完成后,TCP连接关闭。后续请求依赖第一个hello报文返回的AuthInfo来标识其身份。如果最后一个请求之后会话闲置时间超过NETCONF会话超时时间(可通过netconf idle-timeout命令配置,缺省为10分钟),则此会话自动被关闭。如果希望保持会话,可以每隔一段时间,发送一个使用AuthInfo来标识的hello报文给服务器,服务器返回和第一个hello相同的应答报文。
对于基于NETCONF over Console/NETCONF over Telnet/NETCONF over SSH的会话,从连接建立开始建立会话,在以下情况下关闭会话:
· 发送close-session主动断开会话。
· 被其他用户通过kill-session关闭会话。
· 会话的底层连接断开。
· 会话闲置时间超期。缺省情况下,会话从建立到关闭期间,一直有效,且不会过期。通过netconf idle-timeout命令配置NETCONF会话超时时间后,如果会话闲置时间超过NETCONF会话超时时间,则该会话会被关闭。
基于SOAP的会话可以通过多个线程,使用相同的AuthInfo来发送请求而互不干扰,但并发数量存在限制。不建议使用这个方式来进行并发。
基于其他方式连接的请求不支持同一个会话进行并发。
Comware NETCONF中,权限分为3个部分,分别为协议级权限控制、模块级权限控制和实例级权限控制。其中:
· 协议级权限指的是rpc-operation需要的权限。
· 模块级权限指的是用户是否对模块、表、行、组、列具有访问权限。
· 实例级权限指的是具体到某个VPN、Interface、VLAN、Secure Zone的访问权限。
一个完整的请求如果要通过RBAC,必须确保3部分都有权限才能继续。
例如,下面edit-config例子中:
· 协议级权限:要求用户具有rpc/edit-config/config/top的写权限。
· 模块级权限:要求用户具有 Ifmgr/Interfaces/Interface表的写权限。
· 实例级权限:要求用户具有接口索引为3的接口的写权限。
<rpc message-id =”101” xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<edit-config>
<target>
<running/>
</target>
<default-operation> merge</default-operation>
<test-option>set</test-option>
<error-option>continue-on-error</error-option>
<config xmlns:xc=”urn:ietf:params:xml:ns:netconf:base:1.0”>
<top xmlns=”http://www.h3c.com/netconf/config:1.0”>
<Ifmgr xc:operation=”delete”>
<Interfaces>
<Interface>
<IfIndex>3</IfIndex>
</Interface>
</Interfaces>
</Ifmgr>
</top>
</config>
</edit-config>
</rpc>
为了使NETCONF用户具有上述权限,需要为NETCONF用户赋予如下权限:
#
role name netconf
rule 1 permit write xml-element rpc/edit-config/config/top
rule 2 permit write xml-element ifmgr/interfaces/interface
interface policy deny
permit interface GigabitEthernet2/0/1
#
Comware NETCONF的锁遵循RFC 4741中的描述,当一个NETCONF客户端持有锁时,其它的NETCONF客户端或非NETCONF客户端(命令行、SNMP等)均不可以执行系统配置操作。
NETCONF over SOAP(over HTTP和over HTTPs)、NETCONF over Telnet、NETCONF over Console和NETCONF over SSH访问方式下,每一种访问方式支持的最大NETCONF会话个数均依赖于AAA会话最大个数的配置。
Comware NETCONF支持的操作如表4-1所示。
表4-1 Comware NETCONF支持的操作速览表
操作系列 |
操作名称 |
说明 |
获取业务数据 |
get |
获取设备数据 |
get-bulk |
批量获取设备数据 |
|
get-config |
获取设备配置数据 |
|
get-bulk-config |
批量获取设备配置数据 |
|
配置动作 |
edit-config |
修改系统配置 |
非配置动作 |
action |
修改、获取运行统计信息之类的动作 |
事件相关 |
get/filter/netconf |
获取系统支持的事件流 |
create-subscription |
订阅事件 |
|
cancel-subscription |
取消订阅事件 |
|
会话管理 |
close-session |
关闭当前会话 |
kill-session |
关闭非当前会话 |
|
get-sessions |
获取已经建立的会话 |
|
lock |
锁定配置数据库 |
|
unlock |
解锁配置数据库 |
|
执行非交互命令行命令 |
CLI |
作为NETCONF的补充,执行NETCONF尚未提供的命令 |
配置管理 |
rollback |
配置回滚 |
save |
配置保存 |
|
load |
配置加载 |
|
save-point |
提供配置回滚点功能 |
|
请求验证 |
validate |
NETCONF请求的XML语法验证 |
YANG操作 |
get/filter/netconf-state/capabilities |
获取设备能力集 |
get/filter/netconf-state/datastores |
获取设备中的数据库 |
|
get/filter/netconf-state/schemas |
获取设备中的YANG文件名称列表 |
|
get/filter/netconf-state/sessions |
获取设备中的会话信息 |
|
get/filter/netconf-state/statistics |
获取NETCONF的统计信息 |
|
get-schema |
获取YANG文件的内容 |
|
预配置 |
config-provisioned |
开启预配置功能 |
NETCONF支持用户对设备进行业务操作,包括对指定信息的获取和修改。基本标签有<get>、<get-bulk>、<get-config>、<get-bulk-config>和<edit-config>,分别用来获取所有数据、获取配置数据和编辑指定模块的数据。详细规则参见各个模块的NETCONF XML API 手册。
<get-config>和<get-bulk-config>用来获取系统中所有可配置的变量的值,配置的方式包括CLI、MIB、Web等。<get-config>和<get-bulk-config>操作报文中可以包含子标签<filter>,用来对要获取的信息进行过滤。
<get-config>和<get-bulk-config>的通用报文格式如下:
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<datastore/>
</source>
<filter>
<top xmlns="http://www.h3c.com/netconf/config:1.0">
指定模块,子模块,表名,列名
</top>
</filter>
</get-config>
</rpc>
其中,datastore可以为running:
参数 |
说明 |
running |
操作的源数据库为设备的当前运行配置数据库 |
设备收到配置获取请求报文后会将相应配置通过如下报文反馈给客户端:
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
所有指定filter内的数据
</data>
</rpc-reply>
默认情况下,当NETCONF正在执行rollback操作时,不允许下发edit-config请求。如需关闭这个限制,请使用action操作,详细介绍请参见“4.3.3 action操作”。
<edit-config>支持如下选项:merge、create、replace、remove、delete、默认操作选项、默认错误处理选项、测试处理,关于这些选项的详细描述请参见表4-7。
对于有子结构的数据表,子结构下发后,系统会把所有子结构看作一个列进行处理。
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<datastore/>
</target>
<error-option>
失败时默认操作
</error-option>
<config>
<top xmlns="http://www.h3c.com/netconf/config:1.0">
指定模块名,子模块名,列名,表名
</top>
</config>
</edit-config>
</rpc>
其中,datastore可以为running:
参数 |
说明 |
running |
操作的源数据库为设备的当前运行配置数据库 |
设备收到edit-config请求后会回应客户端,当客户端收到如下报文时,表示设置成功:
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
用户还可以通过<get>操作可以查看参数的当前值是否和edit-config操作设置的值一致。
# 进入XML视图。
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
</capabilities>
</hello>
# 获取所有模块所有配置数据。请将以下报文拷贝、粘贴到客户端。
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>
# 如果客户端收到类似如下的报文,则表示操作成功。
<data>
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<Ifmgr>
<Interfaces>
<Interface>
<IfIndex>1307</IfIndex>
<Shutdown>1</Shutdown>
</Interface>
<Interface>
<IfIndex>1308</IfIndex>
<Shutdown>1</Shutdown>
</Interface>
<Interface>
<IfIndex>1309</IfIndex>
<Shutdown>1</Shutdown>
</Interface>
<Interface>
<IfIndex>1311</IfIndex>
<VlanType>2</VlanType>
</Interface>
<Interface>
<IfIndex>1313</IfIndex>
<VlanType>2</VlanType>
</Interface>
</Interfaces>
</Ifmgr>
<Syslog>
<LogBuffer>
<BufferSize>120</BufferSize>
</LogBuffer>
</Syslog>
<System>
<Device>
<SysName>H3C</SysName>
<TimeZone>
<Zone>+11:44</Zone>
<ZoneName>beijing</ZoneName>
</TimeZone>
</Device>
</System>
<Fundamentals>
<WebUI>
<SessionAgingTime>98</SessionAgingTime>
</WebUI>
</Fundamentals>
</top>
</data>
</rpc-reply>
获取Syslog模块的所有配置数据。
# 进入XML视图。
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
</capabilities>
</hello>
# 获取Syslog模块的所有配置数据。请将以下报文拷贝、粘贴到客户端。
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<Syslog/>
</top>
</filter>
</get-config>
</rpc>
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<data>
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<Syslog>
<LogBuffer>
<BufferSize>120</BufferSize>
</LogBuffer>
</Syslog>
</top>
</data>
</rpc-reply>
# 进入XML视图。
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>
# 取接口表的一条数据。请将以下报文拷贝、粘贴到客户端。
<get-bulk>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/data:1.0" xmlns:web="http://www.h3c.com/netconf/base:1.0">
<Ifmgr>
<Interfaces web:count="1">
</Interfaces>
</Ifmgr>
</top>
</filter>
</get-bulk>
</rpc>
# 如果客户端收到类似如下的报文,则表示操作成功。
<data>
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface>
<IfIndex>3</IfIndex>
<Name>GigabitEthernet1/0/2</Name>
<AbbreviatedName>GE1/0/2</AbbreviatedName>
<PortIndex>3</PortIndex>
<ifTypeExt>22</ifTypeExt>
<ifType>6</ifType>
<Description>GigabitEthernet 1/0/2 Interface</Description>
<AdminStatus>2</AdminStatus>
<OperStatus>2</OperStatus>
<ConfigSpeed>0</ConfigSpeed>
<ActualSpeed>100000</ActualSpeed>
<ConfigDuplex>3</ConfigDuplex>
<ActualDuplex>1</ActualDuplex>
</Interface>
</Interfaces>
</Ifmgr>
</top>
</data>
</rpc-reply>
将Syslog模块中的日志缓冲区可存储的信息条数修改为512。
# 进入XML视图。
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>
# 把Syslog模块LogBuffer表中的BufferSize列改成512。请将以下报文拷贝、粘贴到客户端。
<edit-config>
<target>
<running/>
</target>
<config>
<top xmlns="http://www.h3c.com/netconf/config:1.0" web:operation="merge">
<Syslog>
<LogBuffer>
<BufferSize>512</BufferSize>
</LogBuffer>
</Syslog>
</top>
</config>
</edit-config>
</rpc>
# 如果客户端收到类似如下的报文,则表示操作成功.
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
因为设备同时最多能建立32个NETCONF连接,即最多支持32个用户同时使用NETCONF功能管理和监控设备。所以,当用户管理、维护设备或者定位网络问题时,为防止其他NETCONF用户修改当前配置、引入干扰,可以使用本特性为当前配置加锁。为当前配置加锁后,只有持有锁的用户可以修改设备的当前配置,其他NETCONF用户、CLI、WEB等只能读取,不能修改当前配置。
只有持有锁的用户可以解锁,解锁后其他用户才可以修改设备的当前配置或另外加锁。如果持有锁的用户的当前连接断开,系统会自动解锁。
目前设备只支持对当前配置加锁,不能对具体的功能模块进行加锁。请将以下报文拷贝、粘贴到客户端,用户即能完成加锁操作。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<datastore/>
</target>
</lock>
</rpc>
其中,datastore可以为running:
参数 |
说明 |
running |
操作的源数据库为设备的当前运行配置数据库 |
设备收到加锁报文后会回应客户端,当客户端收到如下报文时,表示加锁成功。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
# 进入XML视图。
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
</capabilities>
</hello>
# 对当前配置加锁。请将以下报文拷贝、粘贴到客户端。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
# 如果客户端收到如下报文,则表示加锁成功。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
用户加锁成功后,另一客户端发送加锁报文,设备会返回如下报文。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>lock-denied</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">Lock failed, lock is already held.</error-message>
<error-info>
<session-id>1</session-id>
</error-info>
</rpc-error>
</rpc-reply>
以上报文表明:加锁失败,session-id是1的用户已经持有锁。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<datastore/>
</target>
</unlock>
</rpc>
其中,datastore可以为running:
参数 |
说明 |
running |
操作的源数据库为设备的当前运行配置数据库 |
设备收到解锁报文后会回应客户端,当客户端收到如下报文时,表示解锁成功。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<get>操作用来获取数据,包括运行状态数据和配置数据。
<get>操作会返回所有符合条件的数据,在某些情况下,会导致获取数据效率不高。此时可以考虑使用Comware扩展的<get-bulk>操作。<get-bulk>允许用户从固定数据项开始,向后获取指定条目的数据记录,具体可参见“4.3.1 get-bulk操作”。
<get>报文的通用格式如下:
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter>
<top xmlns="http://www.h3c.com/netconf/data:1.0">
指定模块,子模块,表名,列名
</top>
</filter>
</get>
</rpc>
<filter>选项用于过滤信息。过滤条件和过滤结果,请参见“5 Comware NETCONF数据过滤功能”。<filter>中可包括模块名、子模块名、表名和列名。
<get>操作报文中还可以携带count参数,如下为一个携带了count参数的<get>操作报文示例:
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc="http://www.h3c.com/netconf/base:1.0">
<get >
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/data:1.0" xmlns:base="http://www.h3c.com/netconf/base:1.0">
<Syslog>
<Logs xc:count="5">
<Log>
<Index></Index>
</Log>
</Logs>
</Syslog>
</top>
</filter>
</get >
</rpc>
其中,<get>操作报文中的count属性遵循如下约定:
· count属性的位置可以从top下的节点(<Syslog>)开始,到表节点(<Logs>)为止,这几个位置都能放置count属性。如果在其他位置放置count属性,则会报告错误。
· count放在模块节点上时,如果报文中指定的子孙节点(表)中没有count属性,则这些节点的count属性与模块节点的count属性一致。
· 如果count放在多级表节点上,只有父节点上的count生效;如果count放在子表节点上,则必须指定其祖先节点的所有索引列。
· 如果不指定count,则获取从指定索引开始的所有数据。
设备收到配置获取请求报文后,会将相应参数的值通过如下报文反馈给客户端。
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
全部配置数据和状态数据
</data>
</rpc-reply>
close-session操作用来关闭当前会话。
请将以下报文拷贝、粘贴到客户端,用户即能关闭当前的会话。
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>
设备收到会话关闭请求后会回应客户端,当客户端收到如下报文时,表示当前会话已经被关闭。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
kill-session操作用来关闭除自己外的另一个NETCONF会话,被关闭会话的用户退回到用户视图。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<kill-session>
<session-id>
指定session-ID
</session-id>
</kill-session>
</rpc>
设备收到会话关闭请求后会回应客户端,当客户端收到如下报文时,表示指定会话已经被关闭。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
当前有两个NETCONF登录用户,session ID分别是1和2。session ID为1的用户要关闭另一个用户的会话。
# 进入XML视图。
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
</capabilities>
</hello>
# 关闭session ID为2的用户会话。请将以下报文拷贝、粘贴到客户端。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<kill-session>
<session-id>2</session-id>
</kill-session>
</rpc>
如果客户端收到如下报文,则表明session ID为2的NETCONF会话已经被关闭。建立该会话的用户会从XML视图退回到用户视图。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
NETCONF支持Syslog事件、监控事件及模块上报事件三种类型的事件订阅。基于NETCONF over Telnet/NETCONF over SSH模式的连接支持事件订阅。
用户向设备订阅事件后,设备上发生用户订阅的事件时,设备会自动向订阅的客户端发送事件的相关信息,信息内容包括事件的code、group、severity以及发生时间和描述信息。此处可订阅的事件是指系统支持的日志信息。具体可以订阅哪些模块的事件,请参见《日志信息参考手册》。
· 通过在订阅报文中包括多个事件过滤选项,可以订阅多个事件。
· Comware目前不支持事件回放。
· 在当前订阅存在的情况下,不支持继续订阅或者变更当前订阅。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>NETCONF</stream>
<filter>
<event xmlns="http://www.h3c.com/netconf/event:1.0">
<Code>code</Code>
<Group>group</Group>
<Severity>severity</Severity>
</event>
</filter>
<startTime>start-time</startTime>
<stopTime>stop-time</stopTime>
</create-subscription>
</rpc>
· stream表示支持的事件流,目前只支持NETCONF。
· event表示订阅的事件。
· code表示日志信息中的助记符。
· group表示日志信息中的模块名。
· severity表示日志信息中的安全级别。
· start-time表示订阅的开始时间。
· stop-time表示结束订阅的时间。
设备收到订阅报文后会回应客户端,当客户端收到如下报文时,表示订阅成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply >
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>error-type</error-type>
<error-tag>error-tag</error-tag>
<error-severity>error-severity</error-severity>
<error-message xml:lang="en">error-message</error-message>
</rpc-error>
</rpc-reply>
订阅监控事件后,NETCONF每隔指定时间获取一次所订阅事件,并将符合订阅条件的信息发送给用户。
事件订阅报文格式如下:
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription xmlns='urn:ietf:params:xml:ns:netconf:notification:1.0'>
<stream>NETCONF_MONITOR_EXTENSION</stream>
<filter>
<NetconfMonitor xmlns='http://www.h3c.com/netconf/monitor:1.0'>
<XPath>XPath</XPath>
<Interval>interval</Interval>
<ColumnConditions>
<ColumnCondition>
<ColumnName>ColumnName</ColumnName>
<ColumnValue>ColumnValue</ColumnValue>
<ColumnCondition>ColumnCondition</ColumnCondition>
</ColumnCondition>
</ColumnConditions>
<MustIncludeResultColumns>
<ColumnName>columnName</ColumnName>
</MustIncludeResultColumns>
</NetconfMonitor>
</filter>
<startTime>start-time</startTime>
<stopTime>stop-time</stopTime>
</create-subscription>
</rpc>
表4-2 订阅监控事件属性说明
属性 |
说明 |
Stream |
订阅的事件流,监控事件流的名称为NETCONF_MONITOR_EXTENSION |
NetconfMonitor |
监控事件的过滤信息 |
XPath |
监控事件的路径,格式为:模块名[/子模块名]/表名 |
Interval |
监控的时间间隔,取值范围为1~4294967,缺省值为300,单位为秒,即每隔300秒获取一次符合订阅条件的信息 |
ColumnName |
监控列的名称,格式为:[组名称.]列名称 |
ColumnValue |
监控列的过滤值 |
ColumnCondition |
监控列的过滤条件: · more:大于 · less:小于 · notLess:不小于 · notMore:不大于 · equal:等于 · notEqual:不等于 · include:包含 · exclude:不包含 · startWith:开始于 · endWith:结束于 请根据监控列的过滤值的类型填写过滤条件 |
start-time |
订阅的开始时间 |
stop-time |
订阅的结束时间 |
请求报文中必须按元素顺序组织请求报文。
设备收到订阅报文后会回应客户端,当客户端收到如下报文时,表示订阅成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="100" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
订阅模块上报事件后,所订阅模块发生用户所订阅事件时,将主动上报NETCONF,NETCONF将事件消息发送给用户。
事件订阅报文格式如下:
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xs="http://www.h3c.com/netconf/base:1.0">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>XXX_STREAM</stream>
<filter type="subtree">
<event xmlns="http://www.h3c.com/netconf/event:1.0/xxx-features-list-name:1.0">
<ColumnName xs:condition="Condition">value</ColumnName>
</event>
</filter>
<startTime>start-time</startTime>
<stopTime>stop-time</stopTime>
</create-subscription>
</rpc>
表4-3 订阅模块上报事件属性说明
属性 |
说明 |
Stream |
订阅的事件流,请根据设备实际支持情况填写模块上报事件流的名称 |
Event |
订阅的事件的名称,一个事件流中包括多个事件,请根据事件流下的事件填写,命名空间为事件流的命名空间 |
ColumnName |
当前事件下需要过滤的列的名称 |
Condition |
事件列的过滤条件: · more:大于 · less:小于 · notLess:不小于 · notMore:不大于 · equal:等于 · notEqual:不等于 · include:包含 · exclude:不包含 · startWith:开始于 · endWith:结束于 请根据事件列的过滤值的类型填写过滤条件 |
Value |
当前事件下需要过滤的列的值 |
start-time |
订阅的开始时间 |
stop-time |
订阅的结束时间 |
设备收到订阅报文后会回应客户端,当客户端收到如下报文时,表示订阅成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="100" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
客户端订阅没有时间限制的全部事件。订阅后在断开连接之前,设备发生的所有事件都会发送给客户端。
# 进入XML视图。
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
</capabilities>
</hello>
¡ 订阅Syslog事件举例
# 订阅全部Syslog事件,不限制订阅时间。请将以下报文拷贝、粘贴到客户端。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription xmlns ="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>NETCONF</stream>
</create-subscription>
# 如果客户端收到如下报文,则表示订阅成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<ok/>
</rpc-reply>
当设备上的风扇1有问题时,设备会发送如下报文来通知订阅客户端。
<?xml version="1.0" encoding="UTF-8"?>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2011-01-04T12:30:46</eventTime>
<event xmlns="http://www.h3c.com/netconf/event:1.0">
<Group>DEV</Group>
<Code>FAN_DIRECTION_NOT_PREFERRED</Code>
<Slot>6</Slot>
<Severity>Alert</Severity>
<context>Fan 1 airflow direction is not preferred on slot 6, please check it.</context>
</event>
</notification>
当用户(IP地址为192.168.100.130)登录设备时,设备会发送如下报文来通知订阅客户端。
<?xml version="1.0" encoding="UTF-8"?>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2011-01-04T12:30:52</eventTime>
<event xmlns="http://www.h3c.com/netconf/event:1.0">
<Group>SHELL</Group>
<Code>SHELL_LOGIN</Code>
<Slot>6</Slot>
<Severity>Notification</Severity>
<context>VTY logged in from 192.168.100.130.</context>
</event>
</notification>
¡ 订阅监控事件举例
# 以1s为周期订阅Device/Base表。请将以下报文拷贝、粘贴到客户端。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>NETCONF_MONITOR_EXTENSION</stream>
<filter>
<NetconfMonitor xmlns="http://www.h3c.com/netconf/monitor:1.0">
<XPath>Device/Base</XPath>
<Interval>1</Interval>
<ColumnConditions>
<ColumnCondition>
<ColumnName>HostName</ColumnName>
<ColumnValue>H3C</ColumnValue>
<ColumnCondition>include</ColumnCondition>
</ColumnCondition>
</ColumnConditions>
</NetconfMonitor>
</filter>
</create-subscription>
</rpc>
# 如果客户端收到如下报文,则表示订阅成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<ok/>
</rpc-reply>
之后设备以1s周期间隔发送如下报文通知订阅客户端。
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2020-02-22T09:28:14</eventTime>
<NetconfMonitor xmlns="http://www.h3c.com/netconf/monitor:1.0">
<Device xmlns="http://www.h3c.com/netconf/data:1.0">
<Base>
<HostName>H3C</HostName>
</Base>
</Device>
</NetconfMonitor>
</notification>
¡ 订阅模块上报事件举例
# 订阅Ifmgr模块的所有事件。请将以下报文拷贝、粘贴到客户端。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0" xmlns:xs="http://www.h3c.com/netconf/base:1.0">
<stream>Ifmgr</stream>
</create-subscription>
</rpc>
# 如果客户端收到如下报文,则表示订阅成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<ok/>
</rpc-reply>
当接口deactive时,设备会发送如下报文通知订阅客户端。
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2020-02-22T09:32:10</eventTime>
<InterfaceEvent xmlns="Ifmgr:1.0">
<Interface>
<Name>GigabitEthernet2/0/2</Name>
<Status>IF_DEACTIVE</Status>
<IfIndex>286</IfIndex>
<AdminStatus>ADMIN_UP</AdminStatus>
<OperStatus>OPER_DOWN</OperStatus>
<Description>The Interface GigabitEthernet2/0/2 occurred IF_DEACTIVE event,the administration status is ADMIN_UP,operation status is OPER_DOWN.</Description>
</Interface>
</InterfaceEvent>
</notification>
当接口active时,设备会发送如下报文通知订阅客户端:
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2020-02-22T09:32:10</eventTime>
<InterfaceEvent xmlns="Ifmgr:1.0">
<Interface>
<Name>GigabitEthernet2/0/2</Name>
<Status>IF_ACTIVE</Status>
<IfIndex>286</IfIndex>
<AdminStatus>ADMIN_UP</AdminStatus>
<OperStatus>OPER_DOWN</OperStatus>
<Description>The Interface GigabitEthernet2/0/2 occurred IF_ACTIVE event,the administration status is ADMIN_UP,operation status is OPER_DOWN.</Description>
</Interface>
</InterfaceEvent>
</notification>
validate操作用来验证指定的XML请求格式和其他约束是否正确。Comware系统中,只进行基本的格式检查,不下发到后台模块进行进一步的约束检查。故即使validate检查通过,不代表此请求一定能成功。因为其他操作也会进行格式检查,所以客户端可以直接使用其他操作进行下发,不必使用validate来保证格式的正确性。
<get-schema>操作用来获取设备上指定NETCONF模型文件内容,目前仅支持YANG文件的获取。
<get-schema>报文的通用格式如下:
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-schema xmlns='urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring'>
<identifier>syslog-data</identifier>
<version>2015-05-07</version>
<format>yang</format>
</get-schema>
</rpc>
其中,Identifier、version、format三列请参见“4.2.11 获取netconf-state操作”。
设备收到请求报文后,会将指定YANG文件的内容通过如下报文反馈给客户端。
<?xml version="1.0"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
指定yang文件内容数据
</data>
</rpc-reply>
获取netconf-state可返回下面五种类型的数据:
· <netconf-state><capabilities/></netconf-state>用来获取设备支持的能力集列表。
· <netconf-state><datastores/></netconf-state>用来获取设备上的NETCONF配置库信息列表。
· <netconf-state><schemas/></netconf-state>用来获取设备支持的schemas文件信息列表。
· <netconf-state><sessions/></netconf-state>用来获取设备上的NETCONF会话信息列表。
· <netconf-state><statistics/></netconf-state>用来获取设备NETCONF全局统计信息。
获取netconf-state报文的通用格式如下:
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type='subtree'>
<netconf-state xmlns='urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring'>
<getType/>
</netconf-state>
</filter>
</get>
</rpc>
其中:
· getType可以为capabilities、datastores、schemas、sessions或者statistics。如果不指定getType,则表示获取<netconf-state>下全部类型的neconf-state数据。
· 此操作目前不支持过滤。
(1) 客户端发送报文
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type='subtree'>
<netconf-state xmlns='urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring'>
<capabilities/>
</netconf-state>
</filter>
</get>
</rpc>
(2) 结果验证
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
</capabilities>
</netconf-state>
<data>
</rpc-reply>
其中,能力集列表以设备实际返回值为准。
(1) 客户端发送报文
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type='subtree'>
<netconf-state xmlns='urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring'>
<datastores/>
</netconf-state>
</filter>
</get>
</rpc>
(2) 结果验证
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<datastores>
<datastore>
<name>running</name>
<locks>
<global-lock>
<locked-by-session>1</locked-by-session>
<locked-time>2015-07-30T12:54:45</locked-time>
</global-lock>
</locks>
</datastore>
</datastores>
</netconf-state>
<data>
</rpc-reply>
其中:
¡ 设备目前仅支持running库。
¡ locks表示用户是否持有锁及锁信息。
(1) 客户端发送报文
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type='subtree'>
<netconf-state xmlns='urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring'>
<schemas/>
</netconf-state>
</filter>
</get>
</rpc>
(2) 结果验证
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<schemas>
<schema>
<identifier>syslog-data</identifier>
<version>2015-05-07</version>
<format>yang</format>
<namespace>http://www.h3c.com/netconf/data:1.0</namespace>
<location>NETCONF</location>
</schema>
</schemas>
</netconf-state>
<data>
</rpc-reply>
其中:
¡ identifier、version、format作为<get-schema>操作的输入参数可获取相应文件的具体内容。
¡ format列目前仅支持YANG格式。
¡ namespace表示本文件的命名空间。
¡ location表示文件的存放位置,目前仅支持NETCONF,即存放于设备磁盘上。
(1) 客户端发送报文
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type='subtree'>
<netconf-state xmlns='urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring'>
<sessions/>
</netconf-state>
</filter>
</get>
</rpc>
(2) 结果验证
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<sessions>
<session>
<session-id>1</session-id>
<transport>netconf-soap-over-http</transport>
<username>test</username>
<source-host>192.168.100.68</source-host>
<login-time>2015-07-30T09:44:03</login-time>
<in-rpcs>0</in-rpcs>
<in-bad-rpcs>0</in-bad-rpcs>
<out-rpc-errors>0</out-rpc-errors>
<out-notifications>0</out-notifications>
</session>
</sessions>
</netconf-state>
<data>
</rpc-reply>
其中:
¡ session-id表示用户会话ID信息。
¡ transport表示本会话使用的传输协议。
¡ username表示用户登录使用的用户名。
¡ source-host表示本会话请求的源地址。
¡ login-time表示本会话登录时间。
¡ in-rpcs表示本会话收到的合法RPC个数。
¡ in-bad-rpcs表示本会话收到的不合法RPC个数。
¡ out-rpc-errors表示本会话输出的rpc-error个数。
¡ out-notifications表示本会话输出的通知事件个数。
(1) 客户端发送报文
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type='subtree'>
<netconf-state xmlns='urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring'>
<statistics/>
</netconf-state>
</filter>
</get>
</rpc>
(2) 结果验证
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<statistics>
<netconf-start-time>2015-07-30T09:44:01</netconf-start-time>
<in-bad-hellos>0</in-bad-hellos>
<in-sessions>2</in-sessions>
<dropped-sessions>0</dropped-sessions>
<in-rpcs>1</in-rpcs>
<in-bad-rpcs>0</in-bad-rpcs>
<out-rpc-errors>0</out-rpc-errors>
<out-notifications>0</out-notifications>
</statistics>
</netconf-state>
<data>
</rpc-reply>
其中:
¡ netconf-start-time表示NETCONF管理系统启动时间。
¡ in-bad-hellos表示本系统收到的不合法hello报文总数。
¡ in-sessions表示本系统曾建立的会话个数。
¡ dropped-sessions表示本系统曾因超时丢弃的会话个数。
¡ in-rpcs表示本系统收到的合法RPC请求总个数。
¡ in-bad-rpcs表示本系统收到的不合法RPC请求总个数。
¡ out-rpc-errors表示本系统输出的rpc-error总个数。
¡ out-notifications表示本系统输出的通知事件总个数。
<get-bulk>操作用来从指定索引的下一条开始批量获取后续N条数据(索引行数据不返回),包括运行状态数据和配置数据。用户通过index属性指定索引,通过count属性指定N。如未指定索引,则以第一条为索引;如未指定N,或者数据表中符合条件的数据记录不足N条,则返回表中所有剩余的数据条目。
<get>操作会返回所有符合条件的数据,在某些情况下,会导致获取数据效率不高。<get-bulk>允许用户从固定数据项开始,向后获取指定条目的数据记录。
和<get>的报文类似,<get-bulk>报文的通用格式如下:
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-bulk>
<filter>
<top xmlns="http://www.h3c.com/netconf/data:1.0">
指定模块,子模块,表名,列名
</top>
</filter>
</get-bulk>
</rpc>
<filter>选项用于过滤信息。过滤条件和过滤结果,请参见“5 Comware NETCONF数据过滤功能”。<filter>中可包括模块名、子模块名、表名和列名。
<get-bulk>操作报文中还可以携带count和索引参数,如下为一个携带了count和索引参数的<get-bulk>操作报文示例:
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc="http://www.h3c.com/netconf/base:1.0">
<get-bulk>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/data:1.0" xmlns:base="http://www.h3c.com/netconf/base:1.0">
<Syslog>
<Logs xc:count="5">
<Log>
<Index>10</Index>
</Log>
</Logs>
</Syslog>
</top>
</filter>
</get-bulk>
</rpc>
其中,<get-bulk>操作报文中的count属性遵循如下约定:
· count属性的位置可以从top下的节点(<Syslog>)开始,到表节点(<Logs>)为止,这几个位置都能放置count属性。如果在其他位置放置count属性,则会报告错误。
· count放在模块节点上时,如果报文中指定的子孙节点(表)中没有count属性,则这些节点的count属性与模块节点的count属性一致。
· 如果count放在多级表节点上,只有父节点上的count生效;如果count放在子表节点上,则必须指定其祖先节点的所有索引列。
· 如果不指定count,则获取从指定索引开始的所有数据。
设备收到配置获取请求报文后,会将相应参数的值通过如下报文反馈给客户端。
<?xml version="1.0"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
全部配置数据和状态数据
</data>
</rpc-reply>
<get-bulk-config>用来获取系统中所有可配置的变量的值,请求的标签格式和<get-config>一致。其差别在于:get-bulk-config操作在指定完整索引后,返回从指定索引的下一条开始的数据(指定的索引行本身不返回)。
get-bulk-config同样支持count操作属性,指定count后,每个表返回的数据最多不超过count行。
<get-config>和<get-bulk-config>的通用报文格式如下:
<?xml version="1.0"?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<datastore/>
</source>
<filter>
<top xmlns="http://www.h3c.com/netconf/config:1.0">
指定模块,子模块,表名,列名
</top>
</filter>
</get-config>
</rpc>
其中,datastore可以为running:
参数 |
说明 |
running |
操作的源数据库为设备的当前运行配置数据库 |
设备收到配置获取请求报文后,会将相应配置通过如下报文反馈给客户端。
<?xml version="1.0"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
所有指定filter内的数据
</data>
</rpc-reply>
action提供了一种非配置操作的手段,例如,执行ping操作、清除指定接口的统计数据等。
action的返回结果包括成功、成功并返回结果、失败并返回提示信息3种。
<action>的通用报文格式如下:
<?xml version="1.0"?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action>
<top xmlns="http://www.h3c.com/netconf/action:1.0">
指定模块,子模块,表名,列名
</top>
</action>
</rpc>
设备收到配置获取请求报文后,会将相应配置通过如下报文反馈给客户端。
成功不返回数据的格式:
<?xml version="1.0"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
成功并返回结果的格式:
<?xml version="1.0"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action-result>
Action处理结果的数据
</action-result>
</rpc-reply>
(1) 组网需求
设置当前会话允许在rollback时下发edit-config请求。
(2) 配置步骤。
# 进入XML视图
<Sysname> xml
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>
# 设置允许在rollback时下发edit-config请求。请将以下报文拷贝、粘贴到客户端。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action>
<error-option>stop-on-error</error-option>
<top xmlns="http://www.h3c.com/netconf/action:1.0">
<Fundamentals>
<CurrentSessionOpt>
<DisableEditConfigWhenRollback>false</DisableEditConfigWhenRollback>
</CurrentSessionOpt>
</Fundamentals>
</top>
</action>
</rpc>
(3) 结果验证
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>。
# 如果需要开启会话内的限制,将上述请求报文中false改为true即可。
<load>操作执行后,指定文件中的配置会被合并到设备的当前配置中。设备会将指定文件中的配置和当前配置进行比较:对于指定文件中有,但当前配置中没有的配置,直接运行;对于指定文件中和当前配置中不一致的配置,则用指定文件中的配置替换当前配置中的对应配置。
加载文件相当于在设备上运行此段配置,对于需要先回滚才能成功的配置,用load操作不能成功。
请将以下报文拷贝、粘贴到客户端,用户即可将指定文件中的配置追加到当前配置中。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<load>
<file>指定文件的名称</file>
</load>
</rpc>
其中,“指定文件的名称”必须以存储介质的名称开头,后缀为.cfg。如果不指定文件名,则缺省保存到主用下次启动配置文件中。
设备收到配置加载请求后会回应客户端,当客户端收到如下报文时,表示配置加载成功。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
save操作用来将设备的当前配置保存到指定名称的文件中。
请将以下报文拷贝、粘贴到客户端,用户即可将设备的当前配置保存到指定名称的文件中。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save OverWrite=”false” VsysName=”vsys-name”>
<file>指定文件的名称</file>
</save>
</rpc>
· “指定文件的名称”必须以存储介质的名称开头,后缀为.cfg。当报文中存在<file>列时,必须输入指定文件的名称,不能为空;如果不存在该列,则设备会自动将当前配置保存到缺省的主用下次启动配置文件中。
· OverWrite属性的默认取值为true。缺省情况下,当指定的配置文件名与原有配置文件名相同时,原文件将被覆盖,当前配置保存成功。如果指定OverWrite的值为false,则当指定的配置文件名与原有配置文件名相同时,当前配置保存失败,同时返回错误提示信息。
· VsysName属性仅在支持vSystem的系统有效。用户vSystem下不允许指定VsysName,且不允许指定save的文件名称。管理vSystem下根据该属性指定的vsys-name,将指定vSystem的配置保存到指定的文件中。指定VsysName属性的同时支持OverWrite,不支持Binary-only属性。
设备收到配置保存请求后会回应客户端,当客户端收到如下报文时,表示保存成功。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
# 进入XML视图。
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
</capabilities>
</hello>
# 将设备的当前配置保存到配置文件my_config.cfg。请将以下报文拷贝、粘贴到客户端。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save>
<file> my_config.cfg</file>
</save>
</rpc>
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
rollback操作用来将设备的当前配置恢复到指定配置文件中的配置。
请将以下报文拷贝、粘贴到客户端,用户即可将设备的当前配置恢复到指定配置文件中的配置。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rollback>
<file>指定文件的名称</file>
</rollback>
</rpc>
设备收到配置回滚请求后会回应客户端,当客户端收到如下报文时,表示配置回滚成功。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
通过NETCONF功能,用户可以将命令行封装在XML报文中对设备进行操作。
CLI包括Open-channel、Close-channel、Execution和Configuration四种子操作:
· Open-channel:打开当前会话的保留channel。
· Close-channel:关闭当前会话的保留channel。
· Execution:只在用户视图下进行操作,不能通过system命令切换进入系统视图。
· Configuration:默认在系统视图下进行操作,可以通过system和quit命令进行视图切换。使用channel方式下发CLI时,不可以通过quit命令退回到用户视图,且除首次下发命令是在系统视图,其余所在视图为上一条命令执行完成时所在的视图。
表4-4 CLI标签的介绍
操作 |
说明 |
举例 |
<Open-channel> |
打开保留channel,并将当前channel所对应的视图置为系统视图。如果创建保留channel时,保留channel已存在,则返回失败 |
打开保留channel,且当前视图为系统视图: |
<Close-channel> |
关闭保留channel,如果关闭失败,则返回失败 |
关闭保留channel: |
<Configuration> |
当前标签增加了exec-use-channel属性,用户下发命令时必须携带该属性,该属性取值包括: · false:不使用channel下发执行命令,同原有的下发方式 · true:使用临时channel下发执行命令 · persist:使用保留channel下发执行命令 |
在系统视图/保留channel当前视图下执行display this命令: |
<Execution> |
与原有实现保持一致,只能执行用户视图下的命令 |
在用户视图下执行display this命令: |
Configuration支持exec-use-channel属性,取值包括false、true和persist,具体的使用方法请如表4-5所示。
表4-5 Configuration支持exec-use-channel属性的介绍
属性值 |
说明 |
举例 |
false |
使用原有的exec comsh方式执行命令。由于需要启动comsh执行速度稍慢 |
在系统视图下执行display this命令: |
true |
使用一个临时channel下发执行命令。此时执行命令对比原有exec comsh的方式稍快。但对于命令行本身就会使用exec comsh方式的命令执行效率无明显提升 |
在系统视图下执行display this命令: |
persist |
使用保留channel下发执行命令 如果保留channel不存在,则先自行创建保留channel,并直接从系统视图开始执行命令 如果保留channel存在,则直接在保留channel当前所处的视图执行本次下发的命令 |
在系统视图下执行display this命令: |
当需要给设备发送命令时,请使用格式如下的NETCONF报文:
· 不使用channel下发执行命令
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<CLI>
<Execution>
命令行
</Execution>
</CLI>
</rpc>
或
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<CLI>
<Configuration exec-use-channel="false">
命令行
</ Configuration>
</CLI>
</rpc>
· 使用临时channel方式下发执行命令
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<CLI>
<Configuration exec-use-channel="true">
命令行
</ Configuration>
</CLI>
</rpc>
· 使用保留channel方式下发执行命令
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<CLI>
<Configuration exec-use-channel="persist">
命令行
</ Configuration>
</CLI>
</rpc>
· 打开保留channel方式
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<CLI>
<Open-channel/>
</CLI>
</rpc>
· 关闭保留channel
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<CLI>
<Close-channel/>
</CLI>
</rpc>
一对<Execution>或者<Configuration>子标签中可以包含多个命令行,一条命令输入完毕后,换行,再输入下一条命令即可。
· 所有交互式命令,即需要等待用户输入的命令,都不能保证在CLI模式下可以正确执行。
· Channel方式下发的命令行回显不能超过4K否则会导致channel挂死,且channel不能通过quit等命令直接退出。
设备收到命令行指令后会回应客户端,当客户端收到如下报文时,表示命令行执行成功(注意命令响应被CDATA节点包含)。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<CLI>
<Execution>
<![CDATA[对应命令行响应]]>
</Execution>
</CLI>
</rpc-reply>
对于Open-channel、Close-channel操作成功返回如下报文:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101235" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
对于Open-channel、Close-channel、Configuration的channel下发方式操作失败返回如下报文(XXX为失败原因):
<?xml version="1.0" encoding="UTF-8"?>
<rpc-error xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>application</error-type>
<error-tag>data-missing</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">失败错误提示</error-message>
</rpc-error>
# 进入XML视图。
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
</capabilities>
</hello>
# 向设备发送显示当前配置命令。请将以下报文拷贝、粘贴到客户端。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<CLI>
<Execution>
display current-configuration
</Execution>
</CLI>
</rpc>
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<CLI>
<Execution><![CDATA[
#
version 7.1.052, Demo 2501005
#
sysname ab
#
ftp server enable
ftp update fast
ftp timeout 2000
#
irf mac-address persistent timer
irf auto-update enable
undo irf link-delay
#
domain default enable system
#
telnet server enable
#
vlan 1
#
vlan 1000
#
radius scheme system
primary authentication 127.0.0.1 1645
]]>
</Execution>
</CLI>
</rpc-reply>
使用get-sessions操作,用户可以获取当前设备的所有NETCONF会话信息。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-sessions/>
</rpc>
设备收到命令行指令后会回应客户端,当客户端收到如下报文时,表示命令行执行成功。
<?xml version="1.0" encoding="UTF-8" ?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-sessions>
<Session>
<SessionID>用户会话ID信息 </SessionID>
<Line> line信息</Line>
<UserName>用户登陆名称</UserName>
<Since>用户登录时间</Since>
<LockHeld>用户是否持有锁</LockHeld>
</Session>
</get-sessions>
</rpc-reply>
其中:
· SessionID表示用户会话ID信息,返回值为一个从1开始的数字。
· Line表示用户登录的用户线信息,通过SOAP方式登录的用户的用户线为空。
· UserName表示登录用户的用户名。
· Since表示用户登录时间,返回值为一个标准的Schema的DateTime类型的时间。
· LockHeld表示用户是否持有锁,返回值为true、false。
# 进入XML视图。
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
</capabilities>
</hello>
# 获取设备上当前存在的NETCONF会话的信息。请将以下报文拷贝、粘贴到客户端。
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-sessions/>
</rpc>
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<get-sessions>
<Session>
<SessionID>1</SessionID>
<Line>vty0</Line>
<UserName></UserName>
<Since>2011-01-05T00:24:57</Since>
<LockHeld>false</LockHeld>
</Session>
</get-sessions>
</rpc-reply>
以上信息表明:目前有一个NETCONF连接,SessionID是1,登录用户类型vty0,登录时间是2011-01-05T00:24:57,此用户不持有锁。
设备支持配置自动回滚,配置回滚点后,设备可以在如下场景下进行配置回滚:
· NETCONF客户端主动下发配置回滚指令。
· NETCONF客户端在指定的时间内无任何指令,即NETCONF会话空闲时间超过配置的回滚空闲超时时间。
· NETCONF客户端和设备间的连接异常断开。
配置回滚步骤如下:
(1) 对当前系统加锁。
(2) 下发<save-point>/<begin>操作进行配置回滚点标记。
(3) 下发<edit-config>操作,对设备进行所需配置。
(4) 下发<save-point>/<commit>进行配置确认,可分多次修改配置并确认。
(5) 下发<save-point>/<rollback>进行配置回滚。可选择对应的一次commit进行配置回滚,或者等待NETCONF会话空闲时间超过配置回滚空闲超时时间时,自动将配置回滚到最近使用的commit的配置。
(6) 下发<save-point>/<end>结束配置回滚功能。
(7) 对当前系统解锁。
如果存在多个NETCONF会话同时配置设备,建议配置回滚前先用<lock>锁定系统,否则可能导致设备运行配置与回滚前配置不一致。
(1) 客户端发送报文
请将以下报文拷贝、粘贴到客户端:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save-point>
<begin>
<confirm-timeout>100</confirm-timeout>
</begin>
</save-point>
</rpc>
回滚空闲超时时间<confirm-timeout>为可选,取值范围为1~65535,单位为秒,缺省为600秒。
(2) 结果验证
当客户端收到如下报文时,表示配置回滚点成功。
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<save-point>
<commit>
<commit-id>1</commit-id>
</commit>
</save-point>
</data>
</rpc-reply>
(1) 客户端发送报文
请将以下报文拷贝、粘贴到客户端:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save-point>
<rollback>
<commit-id/>
<commit-index/>
<commit-label/>
</rollback>
</save-point>
</rpc>
<commit-id/>,<commit-index/>,<commit-label/>任选一个,或者不选时,回滚此前最近使用的commit的配置。其中:
¡ commit-id为系统唯一标识的commit编号。
¡ commit-index表示最近50次的commit,0表示最近一次下发commit,49表示最远一次commit。
¡ commit-label为标签,不同的commit标签不能一样,可以没有标签。
(2) 结果验证
当客户端收到如下报文时,表示主动下发配置回滚成功。
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok></ok>
</rpc-reply>
下发<save-point>/<commit>操作接受当前配置。使能save-point后,系统可支持最近50个commit回滚点的配置回滚。超过50次,commit需指定force属性强制覆盖最早的记录。
(1) 客户端发送报文
请将以下报文拷贝、粘贴到客户端:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save-point>
<commit>
<label>SUPPORT VLAN<label>
<comment>vlan 1 to 100 and interfaces. Each vlan used for different custom as follows: ……</comment>
</commit>
</save-point>
</rpc>
其中,<label/>和<comment/>可选。
(2) 结果验证
当客户端收到如下报文时,表示主动下发配置确认成功。
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<save-point>
<commit>
<commit-id>2</commit-id>
</commit>
</save-point>
</data>
</rpc-reply>
下发<save-point>/<end>操作可以取消配置回滚。
(1) 客户端发送报文
请将以下报文拷贝、粘贴到客户端:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save-point>
<end/>
</save-point>
</rpc>
(2) 结果验证
当客户端收到如下报文时,返回对应的end结果成功。
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
下发<save-point>/<get-commits>操作可以获取commit的操作记录。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save-point>
<get-commits>
<commit-id/>
<commit-index/>
<commit-label/>
</get-commits>
</save-point>
</rpc>
其中,<commit-id>、<commit-index>、<commit-label>任选一个,也可以都不选。都不选时,表示显示所有的commit记录。
(1) 客户端发送报文
请将以下报文拷贝、粘贴到客户端。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save-point>
<get-commits>
<commit-label>SUPPORT VLAN</commit-label>
</get-commits>
</save-point>
</rpc>
(2) 结果验证
当客户端收到如下报文时,返回对应的commit操作记录。
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<save-point>
<commit-information>
<CommitID>2</CommitID>
<TimeStamp>Thu Oct 30 11:30:28 1980</TimeStamp>
<UserName>test</UserName>
<Label>SUPPORT VLAN</Label>
</commit-information>
<commit-information>
<CommitID>1</CommitID>
<TimeStamp>Wed Nov 8 18:26:28 1972</TimeStamp>
<UserName>test</UserName>
</commit-information>
</save-point>
</data>
</rpc-reply>
下发<save-point>/<get-commits>操作可以获取对应的commit操作时的配置。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save-point>
<get-commit-information>
<commit-information>
<commit-id/>
<commit-index/>
<commit-label/>
</commit-information>
<compare-information>
<commit-id/>
<commit-index/>
<commit-label/>
</compare-information
</get-commit-information>
</save-point>
</rpc>
其中,<commit-id/>、<commit-index/>、<commit-label/>任选一个。<compare-information/>可选。<commit-information>不输入参数时,显示最近使用的commit配置。
(1) 客户端发送报文
请将以下报文拷贝、粘贴到客户端。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save-point>
<get-commit-information>
<commit-label>SUPPORT VLAN</commit-label>
</get-commit-information>
</save-point>
</rpc>
(2) 结果验证
当客户端收到如下报文时,显示对应的配置信息。
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<save-point>
<commit-information>
<content>
…
interface vlan 1
…
</content>
</commit-information>
</save-point>
</data>
</rpc-reply>
Comware提供索引替换功能,在某些表中,执行get、get-config、edit-config、action操作时可以使用名称来替换索引。比如,假定接口Ethernet1/0/1的索引是1,则可以用Ethernet0/0/0来替换接口索引1。具体哪些表具有上述能力,请参考对应的NETCONF API文档。
例如:假定接口GigabitEthernet1/0/1是Trunk接口,要允许VLAN 2、3通过,可以下发下面的XML:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://www.h3c.com/netconf/config:1.0"> xmlns:base=”http://www.h3c.com/netconf/base:1.0”
<VLAN>
<TrunkInterfaces>
<Interface>
<IfIndex>GigabitEthernet1/0/1</IfIndex>
<PermitVlanList>2-3</PermitVlanList>
</Interface>
</TrunkInterfaces>
</VLAN>
</top>
</config>
</edit-config>
</rpc>
为了区分数字是名称还是索引,从h3c-name2index1.1版本后(版本信息从能力集中获取,能力集的详细介绍请参见“2.7 测试NETCONF客户端和设备的连通性”),可以使用valuetype属性指定该值的类型。valuetype取值为:
· Name:值为名称类型。
· index:值为索引类型。
· auto:设备先按名称类型匹配,如果没有匹配到任何信息,再按照索引类型匹配。如果不指定valuetype属性,缺省为auto。
例如,假定IfIndex元素为index类型,值为1,可以下发下面的XML:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<getoperation>
<filter>
<top xmlns="http://www.h3c.com/netconf/config:1.0" xmlns:base=”http://www.h3c.com/netconf/base:1.0”>
<VLAN>
<TrunkInterfaces>
<Interface>
<IfIndex base:valuetype="index">1</IfIndex>
</Interface>
</TrunkInterfaces>
</VLAN>
</top>
</filter >
</getoperation>
</rpc>
· 对于get-bulk、get-bulk-config操作,当替换的索引是表的索引,并且当前位置起定位作用时,不能使用一对多转换的功能。
· 对于match过滤,不支持名称到索引的转换功能。
· 对于非索引列,edit-config时不能进行一对多转换。
· 对于不同的类型,支持的转换语法不一定完全相同。比如,接口管理支持GigabitEthernet1/0/1 to GigabitEthernet1/0/24这样的表示大量名称的写法,但VPN只支持一次加入一个VPN名称。
某些表的列本身是一个列表,比如VLAN TrunkInterface,其PermitVlanList的表示形式形如2,3,5-8,9,10-100。在这个情况下,可能需要在不修改原有取值的情况下,增量下发新的取值。比如,不知道原来有哪些VLAN被permit了,需要在原来的基础上增加一个VLAN 105,此时就需要下发增量的操作。增量下发的操作方式为:在支持增量下发的节点上指定incremental=”true”属性。
要进行增量下发,必须在要增量下发的列上显式指定增量下发属性。例如,当前VLAN 100的permit List为10,增量下发VLAN 2和3,使用如下XML:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://www.h3c.com/netconf/config:1.0">
xmlns:base=”http://www.h3c.com/netconf/base:1.0”
<VLAN xc:operation="operXXX">
<TrunkInterfaces>
<Interface>
<IfIndex>100</IfIndex>
<PermitVlanList base:incremental=”true”>2-3</PermitVlanList>
</Interface>
</TrunkInterfaces>
</VLAN>
</top>
</config>
</edit-config>
</rpc>
对于不同操作类型,增量下发VLAN后的操作结果如表4-6所示。
表4-6 增量下发VLAN后对于不同操作类型的操作结果
操作(OperXXX) |
有增量属性时的操作结果 |
说明 |
create |
PermitVlanList变为2,3,10 |
如果要增加的部分(2-3)中的一个或者多个已经存在,则报告已经存在,否则返回成功 |
delete |
操作失败,返回配置不存在,因为2不存在 |
delete有增量属性时,会下发增量删除的值;delete有增量属性、无增量属性时,只要指定的要删除的任意部分不存在,均会返回配置不存在 |
merge |
PermitVlanList变为2,3,10 |
- |
replace |
不支持relace操作 |
- |
remove |
操作成功,因为2-3不存在,PermitVlanList不变 |
remove有增量属性时,会下发增量删除的值;没有增量属性时,会删除当前列的全部配置 |
cancel-subscription操作用来取消订阅。在用户向设备订阅事件后,用户可以使用此操作取消已订阅的事件。
取消事件订阅的请求报文格式如下:
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<cancel-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>XXX_STREAM</stream>
</cancel-subscription>
</rpc>
属性 |
说明 |
stream |
订阅的事件流的名称 |
设备收到请求报文后会回应客户端,当客户端收到如下报文时,表示取消订阅成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="100">
<ok/>
</rpc-reply>
如果要取消的已订阅事件流不存在,设备会返回如下错误信息。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">The subscription stream to be canceled doesn't exist: Stream name=XXX_STREAM.</error-message>
</rpc-error>
</rpc-reply>
Comware支持的所有用来获取和设置数据的操作如表4-7所示。其中,包括get、get-config、get-bulk、get-bulk-config、edit-config、action操作。
表4-7 Comware支持的获取和设置数据操作
XML格式样例 |
||
获取Syslog模块的全部数据的XML请求如下: |
||
获取配置数据,和get不同,它只返回非缺省的配置数据。如果没有配置数据,则返回一个空的<data> |
获取接口表内所有配置的XML请求如下: |
|
从指定索引的下一条开始批量获取后续N条数据(索引行数据不返回),包括运行状态数据和配置数据。用户通过index属性指定索引,通过count属性指定N。如未指定索引,则以第一条为索引;如未指定N,或者数据表中符合条件的数据记录不足N条,则返回表中所有剩余的数据条目 get操作会返回所有符合条件的数据,这在某些情况下会导致效率问题。get-bulk允许用户从固定数据项开始,向后获取指定条目的数据记录 |
获取全部接口数据的XML请求如下: |
|
从指定索引的下一条批量获取配置数据。和get-config类似,只返回非默认配置;其它约束类似get-bulk |
获取全部接口配置信息的XML请求如下: |
|
merge操作必须指定具体的操作对象(行): · 如果指定的对象不存在且不允许创建,则返回merge失败 |
将BufferSize设置为120的XML请求如下: |
|
创建指定对象。create操作必须指定配置对象。create操作的XML数据格式和merge类似,只是operation属性需要指定为“create” · 如果当前配置表支持创建对象,且当前对象不存在,则先创建配置对象,再创建指定的配置 · 如果配置对象下对应的配置项已经存在,则返回data-exist错误 |
同上,把merge修改为create即可 |
|
· 如果指定的对象不存在,但允许创建,则先创建再配置该对象为当前配置 · 如果指定对象不存在且不允许创建,则不进行replace操作,返回invalid-value错误,提示用户配置对象不存在 |
同上,把merge修改为replace即可 |
|
· 当指定的删除对象中只有表索引时,则删除此配置指定对象的所有配置,同时删除指定对象 · 当指定的删除对象中不仅仅有表索引还存在配置项时,则删除此对象下面的指定配置 · 如果系统中指定对象不存在,或者XML消息未指定对象,则直接返回成功 |
同上,把merge修改为remove即可 |
|
· 当指定的删除对象中只有表索引时,则删除此配置指定对象的所有配置,同时删除指定对象 |
同上,把merge修改为delete即可 |
|
edit-config 默认操作选项 |
edit-config操作用于修改当前系统配置。NETCONF定制了五种修改配置的方式:merge、create、delete、remove和replace。当XML消息中未指定修改配置方式的时候,则使用默认操作做为当前指令的操作方式,不会修改默认操作的缺省值 默认操作的缺省值是merge,在XML消息中可以通过<default-operation>节点来设置默认操作,取值为: · merge:当配置方式和默认操作方式均未指定时,使用该方式 · replace:当配置方式未指定,默认操作指定为replace的时候,edit-config操作默认为replace操作 · none:当配置方式未指定,默认操作指定为none的时候,edit-config操作默认为none操作。none操作主要用来检查,下发为none操作的配置仅仅做Schema校验,不进行真正的配置下发。语法检查通过,就返回ok成功,否则失败 |
|
edit-config默认错误处理选项 |
edit-config将指定的配置设置到系统上,完成配置设置的操作。在执行edit-config的过程中,如果遇到一个实例配置出错,默认情况下会直接返回错误,但是为了使应用更加灵活,edit-config提供了错误选项,通过错误选项取值的不同,在发生错误的时候进行不同的处理操作 <error-option>节点用于设置一个实例配置出错后,后续实例配置的处理方式,缺省值为stop-on-error,全部取值为: · stop-on-error:停止处理,返回错误。此选项为默认选项 · continue-on-error:继续处理,但是报告错误 · rollback-on-error:停止并回滚配置 |
|
edit-config测试处理选项 |
在真正执行edit-config操作时,可指定一个测试选项,使用<test-option>节点来决定当前配置是否真正下发。该节点的缺省值为test-then-set,全部取值为: · test-then-set:如果没有错误则将配置设置到系统 · set:将配置设置到系统 · test-only:只测试,并不下发配置到系统。语法检查通过,就返回ok成功,否则失败 |
下发一个接口的配置,仅测试,XML请求如下: |
清除全部接口的统计信息,XML请求如下: |
获取数据系列操作包括get、get-bulk、get-config和get-bulk-config。本节介绍这些get系列操作的返回值。
<get>和<get-bulk>报文的通用格式如下:
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<getoperation>
<filter>
<top xmlns="http://www.h3c.com/netconf/data:1.0">
指定模块,子模块,表名,列名
</top>
</filter>
</getoperation>
</rpc>
<get-config>和<get-bulk-config>报文的通用格式如下:
<?xml version="1.0" encoding="UTF-8" ?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<getoperation>
<source>
<running/>
</source>
<filter>
<top xmlns="http://www.h3c.com/netconf/data:1.0">
指定模块,子模块,表名,列名
</top>
</filter>
</getoperation>
</rpc>
其中,getoperation可以为get、get-bulk、get-config或者get-bulk-config。<filter>选项用于过滤信息,<filter>中可包括模块名、子模块名、表名和列名。指定不同的<filter>,返回值可以是表、行和列:
· 返回值为表:
¡ 如果<filter>中不指定模块(子模块),则表示全部模块(子模块)。一旦指定模块(子模块),则返回数据只包含指定模块(子模块)。
¡ 如果模块下不指定表,则表示全部表。一旦指定表,则返回数据只包含指定表。
· 返回值为行:
¡ 如果表下不指定列名,则表示该表的全部行。
¡ 如果<filter>中只指定索引列,则返回与该索引列匹配的行的全部列。如果同时指定了索引列之外的其他列,则返回与索引列匹配的行的索引列和指定的列。
· 返回值为列:
¡ 如果<filter>中只指定索引列,则返回的数据包括全部的列。如果同时指定了索引列之外的其他列,则返回的数据仅包含索引列和指定的列。
¡ 对于多于一个索引的情况,索引列缺失,则返回的数据仅仅包括全部的索引
¡ 对于get-bulk操作,前面的连续索引的值作为定位依据,后续不连续索引的值作为过滤条件存在。比如,一个多实例表存在A、B、C、D、E 5个索引,如果提供A、B、D、E 4个索引,则A、B的值作为定位条件,取满足A、B条件的第一个C、D、E的数据,同时,D、E的值作为过滤条件存在。
¡ 对于get操作,索引不全时,所有的索引列都作为过滤条件存在。
下列情况可能导致返回空数据:
· 配置模块未启动。
· 无访问对应对象的RBAC权限。
· 过滤条件过滤掉全部数据。
· 发生其他非格式约束类的错误。
· 对于get-config系列操作,指定表中只有默认配置。
· 在当前设备上,不支持指定的表。
如果表没有授予read权限,get返回结果不包括此表数据。
如果列没有授予read权限,那么请求中一定不包括此列。如果请求不明确包括此列,则能返回其他列数据;如果显式包括此列,则此表没有数据可以返回。
对于表中行的实例,如果索引代表的对象没有权限,则对于get和get-config操作,获取不到此数据;对于get-bulk和get-bulk-config操作,会跳过此行。
某些模块可能提供自定义的过滤,用来提供更复杂的查询条件,比如Route模块的Ipv4Routes表,其过滤条件出现在行(多实例表),或者表(单实例表)上。其表现形式如下:
<Route>
<Ipv4Routes>
<RouteEntry h3c:filter=' ip 1.1.1.1' xmlns:h3c='http://www.h3c.com/netconf/base:1.0' >
</RouteEntry>
</Ipv4Routes>
</Route>
如果同时出现模块自定义的过滤条件,则此过滤条件会和其他get系列的过滤条件共同作用,即模块提供的过滤条件会使返回的过滤结果进一步缩小。
具体哪些模块会提供自定义的过滤条件,需要查看对应的模块的XML API编程手册。
当用户执行<get>、<get-bulk>、<get-config>或者<get-bulk-config>操作时,在XML语言中增加过滤条件,可以使用户只看到自己关心的数据。数据过滤包括严格匹配、正则表达式匹配和条件匹配三种。
同时指定多种过滤条件时,只有一种过滤条件可以生效。过滤条件按照优先级从高到底的顺序,依次为:严格匹配、正则表达式匹配和条件匹配。
严格匹配包括两种匹配方式:元素值方式和属性名方式。当两者都指定时,优先使用元素值方式。
用户在XML语言中直接指定对应的元素值,设备将对这些值进行严格匹配。如果指定了多个元素的值,则返回同时符合这几个条件的数据。只有完全匹配条件才返回成功。
例如,如下为一个NETCONF报文示例,用于获取所有状态为UP的接口的配置信息。
<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface>
<AdminStatus>2</AdminStatus>
</Interface>
</Interfaces>
</Ifmgr>
</top>
</filter>
</get>
</rpc>
当用户在行的位置上放置的某个属性的名称和当前表的某个列的名称一致,则这个属性的值将与用户下发配置中同名称的列的值进行严格匹配。例如,上面例子用属性名方式的等价XML请求为:
<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/data:1.0" xmlns:data="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface data:AdminStatus="2" />
</Interfaces>
</Ifmgr>
</top>
</filter>
</get>
</rpc>
以上两个NETCONF报文示例说明:通过两种严格匹配方式均可以获取所有状态为UP的接口配置信息。
当过滤条件比较复杂时,可以在指定元素上设置regExp属性为一个正则表达式,以达到过滤的目的。支持正则表达式匹配的数据类型包括:各种整数、各种日期和时间、各种字符串、IPv4地址、IPv4掩码、IPv6地址、MAC地址、OID、时区。
Comware系统中,正则表达式依赖ucLibC、gLibC等库实现,不同库的实现可能存在某些差异。为防止出现设备无法解析正则表达式的情况,XML请求中应当避免出现特别复杂的正则表达式。
如下为一个NETCONF报文示例,用于获取接口的描述信息,并要求这些描述信息全部为大写字母,不能有其它字符。
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<Ifmgr>
<Interfaces>
<Interface>
<Description h3c:regExp="^[A-Z]*$" />
</Interface>
</Interfaces>
</Ifmgr>
</top>
</filter>
</get-config>
</rpc>
正则表达式中常用的特殊字符匹配规则如表5-1所示。
特殊字符 |
含义 |
举例 |
^ |
匹配以指定字符开始的行 |
^u只能匹配以u开始的行,不能匹配以Au开始的行 |
$ |
匹配以指定字符结束的行 |
u$只能匹配以u结尾的行,不能匹配以uA结尾的行 |
. |
通配符,可代表任何一个字符 |
.s可以匹配as和bs等 |
* |
匹配星号前面的字符或字符串零次或多次 |
· zo*可以匹配z以及zoo · (zo)*可以匹配zo以及zozo |
+ |
匹配+前面的字符或字符串一次或多次 |
zo+可以匹配zo以及zoo,但不能匹配z |
| |
匹配|左边或右边的整个字符串 |
def|int只能匹配包含def或者int的字符串所在的行 |
( ) |
表示字符串,一般与“+”或“*”等符号一起使用 |
(123A)表示字符串123A;408(12)+可以匹配40812或408121212等字符串,但不能匹配408 |
\index |
表示重复一次指定字符串,字符串是指\前用()括起来的字符串,index对应\前字符串的顺序号按从左至右的顺序从1开始编号:如果\前面只有一个字符串,则index只能为1;如果\前面有n个字符串,则index可以为1到n中的任意整数 |
(string)\1表示把string重复一次,匹配的字符串必须包含stringstring;(string1)(string2)\2表示把string2重复一次,匹配的字符串必须包含string1string2string2;(string1)(string2)\1\2表示先把string1重复一次,再重复一次string2,匹配的字符串必须包含string1string2string1string2 |
[ ] |
表示字符选择范围,将以选择范围内的单个字符为条件进行匹配,只要字符串里包含该范围的某个字符就能匹配到 |
· [16A]表示可以匹配到的字符串只需要包含1、6或A中任意一个 · [1-36A] 表示可以匹配到的字符串只需要包含1、2、3、6或A中任意一个(-为连接符) 如果]需要作为普通字符出现在[ ]内时,必须把]写在[ ]中字符的最前面,形如[]string],才能匹配到]。[没有这样的限制 |
[^] |
表示选择范围外的字符,将以单个字符为条件进行匹配,只要字符串里包含该范围外的某个字符就能匹配到 |
[^16A]表示可匹配的字符串只需要包含1、6和A之外的任意字符,该字符串也可以包含字符1、6或A,但不能只包含这三个字符。例如[^16A]可以匹配abc、m16,不能匹配1、16、16A |
{n} |
n是一个非负整数,匹配n次 |
o{2}不能匹配Bob,但是能匹配food |
{n,} |
n是一个非负整数,至少匹配n次 |
o{2,}不能匹配Bob,但能匹配foooood |
{n,m} |
m和n均为非负整数,其中n小于等于m。只要字符串里包含n到m个某字符就能匹配到 |
o{1,3}能匹配fod、food、foood、foooood,但不能匹配fd |
\< |
匹配包含指定字符串的字符串,字符串前面如果有字符则不能是数字、字母和下划线 |
\<do匹配单词domain,还可以匹配字符串doa |
\> |
匹配包含指定字符串的字符串,字符串后面如果有字符则不能是数字、字母和下划线 |
do\>匹配单词undo,还可以匹配字符串cdo |
\b |
匹配一个单词边界,也就是指单词和空格间的位置 |
er\b可以匹配never,但不能匹配verb \ber可以匹配erase,但不能匹配verb |
\B |
匹配非单词边界 |
er\B能匹配verb,但不能匹配never |
\w |
\w等效于[A-Za-z0-9_],是数字、字母或下划线 |
v\w能匹配vlan,v\w还能匹配service |
\W |
\W等效于[^A-Za-z0-9_],是除了数字、字母和下划线之外的任意字符 |
\Wa可以匹配-a,但是不能匹配2a和ba等 |
\ |
转义操作符,\后紧跟本表中罗列的单个特殊字符时,将去除特殊字符的特定含义 |
· \\可以匹配包含\的字符串 · \^可以匹配包含^的字符串 · \\b可以匹配包含\b的字符串 |
获取Ifmgr模块Interfaces表下Description列包含冒号的所有数据。
# 进入XML视图。
<Sysname> xml
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
</capabilities>
</hello>
# 获取Ifmgr模块Interfaces表下Description列包含冒号的所有数据。请将以下报文拷贝、粘贴到客户端。
<?xml version="1.0"?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:reg="http://www.h3c.com/netconf/base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface>
<Description reg:regExp=":" />
</Interface>
</Interfaces>
</Ifmgr>
</top>
</filter>
</get>
</rpc>
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:reg="http://www.h3c.com/netconf/base:1.0" message-id="100">
<data>
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface>
<IfIndex>2681</IfIndex>
<Description>Ten-GigabitEthernet1/0/49:1 Interface</Description>
</Interface>
<Interface>
<IfIndex>2682</IfIndex>
<Description>Ten-GigabitEthernet1/0/49:2 Interface</Description>
</Interface>
<Interface>
<IfIndex>2683</IfIndex>
<Description>Ten-GigabitEthernet1/0/49:3 Interface</Description>
</Interface>
<Interface>
<IfIndex>2684</IfIndex>
<Description>Ten-GigabitEthernet1/0/49:4 Interface</Description>
</Interface>
<Interface>
<IfIndex>2685</IfIndex>
<Description>Ten-GigabitEthernet1/0/50:1 Interface</Description>
</Interface>
<Interface>
<IfIndex>2686</IfIndex>
<Description>Ten-GigabitEthernet1/0/50:2 Interface</Description>
</Interface>
<Interface>
<IfIndex>2687</IfIndex>
<Description>Ten-GigabitEthernet1/0/50:3 Interface</Description>
</Interface>
<Interface>
<IfIndex>2688</IfIndex>
<Description>Ten-GigabitEthernet1/0/50:4 Interface</Description>
</Interface>
<Interface>
<IfIndex>2689</IfIndex>
<Description>Ten-GigabitEthernet1/0/51:1 Interface</Description>
</Interface>
<Interface>
<IfIndex>2690</IfIndex>
<Description>Ten-GigabitEthernet1/0/51:2 Interface</Description>
</Interface>
<Interface>
<IfIndex>2691</IfIndex>
<Description>Ten-GigabitEthernet1/0/51:3 Interface</Description>
</Interface>
<Interface>
<IfIndex>2692</IfIndex>
<Description>Ten-GigabitEthernet1/0/51:4 Interface</Description>
</Interface>
</Interfaces>
</Ifmgr>
</top>
</data>
</rpc-reply>
由于正则表达仅能够完成字符匹配,对于数值逻辑的判断过滤实现起来比较麻烦。此时,可使用条件匹配过滤功能。
条件匹配通过在元素中增加match属性完成,属性的值(即过滤条件)可以为数字、字符串。
值大于value,支持的数据类型为:各种日期和时间、各种数字、各种字符串、IPv4地址、IPv4掩码、IPv6地址、MAC地址、时区 |
||
值小于value,支持的数据类型为:各种日期和时间、各种数字、各种字符串、IPv4地址、IPv4掩码、IPv6地址、MAC地址、时区 |
||
值不小于value,支持的数据类型为:各种日期和时间、各种数字、字符串、IPv4地址、IPv4掩码、IPv6地址、MAC地址、时区 |
||
值不大于value,支持的数据类型为:各种日期和时间、各种数字、各种字符串、IPv4地址、IPv4掩码、IPv6地址、MAC地址、时区 |
||
值等于value,支持的数据类型为:所有类型 |
||
值不等于value,支持的数据类型为:所有类型 |
||
包含字符串string,支持的数据类型为:各种字符串、IPv4地址、IPv4掩码 |
||
不能包含字符串string,支持的数据类型为:各种字符串、IPv4地址、IPv4掩码、 |
||
以字符串string开头,支持的数据类型为:各种字符串、OID、IPv4地址、IPv4掩码、 |
||
以字符串string结束,支持的数据类型为:各种字符串、IPv4地址、IPv4掩码、 |
如下为一个NETCONF报文示例,用于获取实体扩展信息中CPU利用率大于50%的实体。
<get>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Device>
<ExtPhysicalEntities>
<Entity>
<CpuUsage h3c:match="more:50"></CpuUsage>
</Entity>
</ExtPhysicalEntities>
</Device>
</top>
</filter>
</get>
</rpc>
获取Ifmgr模块Interfaces表下IfIndex值大于等于5000的Name列信息。
# 进入XML视图。
<Sysname> xml
# 进行能力交换。请将以下报文拷贝、粘贴到客户端。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
</capabilities>
</hello>
# 获取Ifmgr模块Interfaces表下IfIndex值大于等于5000的Name列信息。请将以下报文拷贝、粘贴到客户端。
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="http://www.h3c.com/netconf/base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface>
<IfIndex nc:match="more:5000"/>
<Name/>
</Interface>
</Interfaces>
</Ifmgr>
</top>
</filter>
</get>
</rpc>
# 如果客户端收到类似如下的报文,则表示操作成功。
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="http://www.h3c.com/netconf/base:1.0" message-id="100">
<data>
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface>
<IfIndex>7241</IfIndex>
<Name>NULL0</Name>
</Interface>
<Interface>
<IfIndex>7243</IfIndex>
<Name>Register-Tunnel0</Name>
</Interface>
</Interfaces>
</Ifmgr>
</top>
</data>
</rpc-reply>
可重复的列在明确指定过滤条件进行数据过滤时,会只罗列出本行本列中符合过滤条件的列,本行本列中不符合过滤条件的列不会输出,如果一个记录都没有,则本行不输出。
具有可重复的数据结构的情况中,结构分组的成员在明确指定过滤条件进行数据过滤时,会只罗列出所有成员都符合过滤条件的分组,不符合过滤条件或者只有部分符合过滤条件的分组不会输出,如果本行中一个符合输出的分组记录都没有,则本行不输出。
本节以ncclient为例,介绍开源工具作为NETCONF客户端,与设备(作为NETCONF服务器)建立NETCONF会话的方法。
ncclient是一个可以用作NETCONF客户端的Python库。它为使用者提供了非常直观的API,并将NETCONF的XML编码特性映射到Python构造和习语,使得网络管理脚本的编写更加容易。
该库包含的主要功能有:
· 支持RFC 6241定义的所有NETCONF特性和功能。
· 流水线式请求。
· 支持异步RPC请求。
· 与标准XML方式一致。除非真正需要,否则无需变更。
· 扩展性强,可以根据需要,灵活添加新的传输映射和功能/操作。
ncclient所需的Python版本为Python 2.7或Python 3.5+。
ncclient的运行依赖如下库:
· setuptools 0.6+
· Paramiko 1.7+
· lxml 3.3.0+
· libxml2
· libxslt
如果操作系统为Debian/Ubuntu,则还需要通过aptitude或者apt-get等方式安装如下的库:
· libxml2-dev
· libxslt1-dev
可以通过如下方式安装ncclient:
· 解压安装包后安装ncclient。以ncclient-0.6.10.tar.gz为例,具体过程为:
a. 解压下载后的安装包。
b. 打开cmd,切换到解压后setup.py文件所在的目录下。
c. 执行python setup.py build命令。
d. 执行python setup.py install命令。
· pip方式,即执行pip install ncclient命令安装ncclient。该方式需要确保主机可以访问到目标lib仓库(开发环境可能对默认仓库或公网仓库有访问限制,需要和网络管理员确认)。
安装完成后,需要按照如下步骤检查是否安装成功:
(1) 打开cmd,进入python视图。
(2) 输入import ncclient命令。如果没有报错,则表示已经安装成功了。
如果需要切换ncclient版本,需要先执行pip uninstall ncclient命令卸载ncclient。
通过python命令执行脚本时,需要指定脚本文件所在的路径。例如,脚本文件*.py保存在C/desktop/examples目录下,在C/desktop下执行的python命令形式如下:
[ncclient] $ python examples/*.py
本节以NETCONF over SSH访问方式为例,介绍如何通过运行Python脚本建立NETCONF会话。建立NETCONF会话的过程通常为:
(1) 配置NETCONF访问方式。
(2) 创建一个*.py脚本,并import依赖库。
(3) 调用connect方法,通过SSH创建NETCONF会话。
选用NETCONF over SSH访问方式时,需要在服务端配置SSH用户,并开启NETCONF over SSH服务。具体配置方法可参见“2.4.1 配置NETCONF over SSH访问方式”。
配置完成后,设备上将具有可用的SSH服务(用户名和密码)用于和客户端建立连接。本例中,假设用户名为ssh,密码为00password00connect 。
在建立NETCONF会话之前,需要先检查NETCONF客户端和NETCONF服务器之间能否ping通,确保ncclient和设备(Server)三层互通。
在ncclient上创建到设备的SSH连接。该连接使用基于用户名和密码的身份认证方式,用户名为ssh,密码为00password00connect 。执行脚本调用connect函数时,客户端连接到设备,并自动建立一个NETCONF会话。
脚本运行过程中,如果出现类似“No module named XXX”的提示,则使用pip install xxx命令安装所需要的模块即可。
可以采用如下两种脚本建立NETCONF会话:
· 在脚本执行时提供连接相关的参数,具体过程为:
a. 新建demo1.py文件,将以下内容复制到文件中。
# -*- coding:utf-8 -*-
import sys
from ncclient import manager
from ncclient import operations
def h3c_connection(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name':"h3c"},
allow_agent = False,
look_for_keys = False)
def test_connect(host, port, user, password):
with h3c_connection(host,port=port,user=user,password=password) as m:
n = m._session.id
print("This session id is %s."%(n))
if __name__ == '__main__':
# test_connect("192.168.56.120", 830, "ssh", "00password00connect ")
test_connect(sys.argv[1],sys.argv[2],sys.argv[3],sys.argv[4])
其中,各参数的含义为:
- host:运行NETCONF服务器的设备的IP地址,推荐使用设备上管理口的IP地址。此例中,IP地址为192.168.56.120。
- port:建立SSH连接的端口号。默认为830。
- username:SSH用户的用户名。此例中,用户名为ssh。
- password:SSH用户的密码。此例中,密码为00password00connect 。
b. 进行cmd,并切换到demo1.py文件所在的目录,执行以下命令。
>python demo1.py 192.168.56.120 830 ssh 00password00connect
c. 脚本运行结果如图6-1所示。
· 在脚本文件中提供连接相关的参数,具体过程为:
a. 新建demo2.py文件,将以下内容复制到文件中。
# -*- coding:utf-8 -*-
import sys
from ncclient import manager
from ncclient import operations
def h3c_connection(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name':"h3c"},
allow_agent = False,
look_for_keys = False)
def test_connect(host, port, user, password):
with h3c_connection(host,port=port,user=user,password=password) as m:
n = m._session.id
print("This session id is %s."%(n))
if __name__ == '__main__':
test_connect("192.168.56.120", 830, "ssh", "00password00connect ")
b. 进入cmd,并切换到demo2.py文件所在的目录,执行以下命令。
>python demo2.py
本节介绍如何在NETCONF会话上,执行配置管理、状态查询和事件订阅等基本操作。执行ncclient基本操作的过程可以概括为:
(1) 根据需要,构造不同的RPC报文。
(2) 执行该Python脚本,以完成配置、查询、订阅等操作。
(1) 构造RPC报文,本例为创建新的VLAN。RPC请求报文的XML结构可参见《H3C Comware 7 NETCONF XML API Reference》文档。
VLAN_RPC = """<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<VLAN xc:operation="create">
<VLANs>
<VLANID>
<ID>3</ID>
<Name>3</Name>
<Description>2</Description>
</VLANID>
</VLANs>
</VLAN>
</top>
</config>
"""
(2) 根据配置的生效模式,选择不同的操作方式。
¡ 立即生效模式:执行edit-config操作,指定对服务器端<running/>配置集进行修改,并校验返回报文。
rpc_obj = m.edit_config(target='running', config=VLAN_RPC)
_check_response(rpc_obj,'VLAN_MERGE')
¡ 二阶段生效模式:执行edit-config操作,指定对服务器端<candidate/>配置集进行修改,并校验返回报文。
rpc_obj = m.edit_config(target=' candidate ', config=VLAN_RPC)
_check_response(rpc_obj,'VLAN_MERGE')
完成edit-config操作后,通过如下命令执行commit操作。
m.commit()
¡ 试运行模式:执行edit-config操作,指定对服务器端<candidate/>配置集进行修改,并校验返回报文。
rpc_obj = m.edit_config(target=' candidate ', config=VLAN_RPC)
_check_response(rpc_obj,'VLAN_MERGE')
完成edit-config操作后,通过如下命令将配置提交试运行,并设置运行时间。
m.commit(confirmed=True, timeout=' 300 ')
完成edit-config操作后,也可以执行以下命令丢弃<candidate/>中未提交的数据,即放弃配置。
m.discard_changes()
上述命令中的m为with h3c_connection(host,port=port,user=user,password=password) as m:
(1) 以下为通过edit-config操作创建VLAN的Python程序:
# -*- coding:utf-8 -*-
import sys
import logging
from ncclient import manager
from ncclient import operations
log = logging.getLogger(__name__)
# 用于创建VLAN的RPC报文。
VLAN_RPC = """<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<VLAN xc:operation="create">
<VLANs>
<VLANID>
<ID>3</ID>
<Name>3</Name>
<Description>2</Description>
</VLANID>
</VLANs>
</VLAN>
</top>
</config>
"""
# 建立与设备的连接。
def h3c_connection(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name':"h3c"},
allow_agent = False,
look_for_keys = False)
# 检查RPC回复报文。
def _check_response(rpc_obj, snippet_name):
print("RPC reply for %s is %s" % (snippet_name, rpc_obj.xml))
xml_str = rpc_obj.xml
if "<ok/>" in xml_str:
print("%s successful"%snippet_name)
else:
print("Cannot successfully execute: %s" % snippet_name)
def test_edit_config_running(host, port, user, password):
# 创建NETCONF会话。
with h3c_connection(host,port=port,user=user,password=password) as m:
# 发送RPC请求并检查RPC回复报文。
rpc_obj = m.edit_config(target='running', config=VLAN_RPC)
_check_response(rpc_obj,'VLAN_MERGE')
if __name__ == '__main__':
test_edit_config_running("192.168.56.120", 830, "ssh", "00password00connect ")
(2) 以下为通过edit-config操作删除VLAN的Python程序:
# -*- coding:utf-8 -*-
import sys
import logging
from ncclient import manager
from ncclient import operations
log = logging.getLogger(__name__)
# 用于删除VLAN的RPC报文。
VLAN_RPC_DELETE = """<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<VLAN xc:operation="delete">
<VLANs>
<VLANID>
<ID>4</ID>
</VLANID>
</VLANs>
</VLAN>
</top>
</config>
"""
# 建立与设备的连接。
def h3c_connection(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name':"h3c"})
# 检查RPC回复报文。
def _check_response(rpc_obj, snippet_name):
print("RPC reply for %s is %s" % (snippet_name, rpc_obj.xml))
xml_str = rpc_obj.xml
if "<ok/>" in xml_str:
print("%s successful" % snippet_name)
else:
print("Cannot successfully execute: %s" % snippet_name)
def test_edit_config_running(host, port, user, password):
# 创建NETCONF会话。
with h3c_connection(host, port=port, user=user, password=password) as m:
# 发送RPC请求并检查RPC回复报文。
rpc_obj = m.edit_config(target='running', config=VLAN_RPC_DELETE)
_check_response(rpc_obj, 'VLAN_DELETE')
if __name__ == '__main__':
test_edit_config_running("192.168.56.120", 830, "ssh", "00password00connect")
(1) 构造过滤条件,不同操作方式,报文格式不同:
¡ get操作需要指定的命名空间为xmlns=http://www.h3c.com/netconf/data:1.0。以获取接口信息为例,RPC报文如下:
IF_GET_RPC = """
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface></Interface>
</Interfaces>
</Ifmgr>
</top>
"""
¡ get-config操作需要指定的命名空间为xmlns=http://www.h3c.com/netconf/config:1.0。以获取接口信息为例,RPC报文如下:
IF_GET_CONFIG_RPC = """
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<Ifmgr>
<Interfaces>
<Interface></Interface>
</Interfaces>
</Ifmgr>
</top>
"""
(2) 调用对应接口,发送<get>或<get-config>报文到服务器端,查询当前运行数据和配置数据。
¡ 调用get接口,发送get操作RPC请求,并将回复报文写入到xml文件中。
get_reply = m.get(("subtree", IF_GET_RPC)).data_xml
print(get_reply)
with open("%s_get.xml" % host, 'w') as f:
f.write(get_reply)
¡ 调用get或get-config接口,发送get-config操作RPC请求,并将回复报文写入到xml文件中。
通过调用get和get-config接口,均可以执行get-config操作。调用get接口时,设备通过请求报文中的命令空间判断当前请求是get类型还是get-config类型。
调用get接口,执行get-config操作的方法为:
get_reply2 = m.get(("subtree", IF_GET_CONFIG_RPC)).data_xml
print(get_reply2)
with open("%s_getconfig.xml" % host, 'w') as f:
f.write(get_reply2)
调用get-config接口,执行get-config操作的方法为:
c = m.get_config(source='running',filter=('subtree',IF_GET_CONFIG_RPC)).data_xml
with open("%s_getconfig2.xml" % host, 'w') as f:
f.write(c)
以下为通过get或get-config操作获取接口信息的Python程序:
# -*- coding:utf-8 -*-
import sys
import logging
from ncclient import manager
from ncclient import operations
log = logging.getLogger(__name__)
# 获取接口信息的RPC报文。
IF_GET_RPC = """
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface></Interface>
</Interfaces>
</Ifmgr>
</top>
"""
IF_GET_CONFIG_RPC = """
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<Ifmgr>
<Interfaces>
<Interface></Interface>
</Interfaces>
</Ifmgr>
</top>
"""
# 建立与设备的连接。
def h3c_connection(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name':"h3c"},
allow_agent = False,
look_for_keys = False)
def test_get(host, port, user, password):
# 创建NETCONF会话。
with h3c_connection(host,port=port,user=user,password=password) as m:
n = m._session.id
print("This session id is %s."%(n))
# 发送get操作RPC请求,并将回复报文写入到xml文件中。
get_reply = m.get(("subtree", IF_GET_RPC)).data_xml
print(get_reply)
with open("%s_get.xml" % host, 'w') as f:
f.write(get_reply)
# 通过get接口发送get-config操作RPC请求,并将回复报文写入到xml文件中。
get_reply2 = m.get(("subtree", IF_GET_CONFIG_RPC)).data_xml
print(get_reply2)
with open("%s_getconfig.xml" % host, 'w') as f:
f.write(get_reply2)
# 通过get-config接口发送get-config操作RPC请求,并将回复报文写入到xml文件中。
c = m.get_config(source='running',filter=('subtree',IF_GET_CONFIG_RPC)).data_xml
with open("%s_getconfig2.xml" % host, 'w') as f:
f.write(c)
if __name__ == '__main__':
test_get("192.168.56.120", 830, "ssh", "00password00connect ")
get-bulk和get-bulk-config操作为H3C自行定义的私有操作类型。在ncclient中get-bulk/get-bulk-config接口和get接口的使用方法类似。
(1) 构造过滤条件。
以获取接口数据为例,RPC_GET_BULK使用get-bulk方法,获取接口索引为<IfIndex>1536</IfIndex>之后的所有接口的数据,RPC报文为:
RPC_GET_BULK = """
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface>
<IfIndex>1536</IfIndex>
</Interface>
</Interfaces>
</Ifmgr>
</top>
"""
使用get-bulk-config方法获取所有接口的配置数据,其报文格式为(RPC_GET_BULK_CONFIG的RPC请求中未指定索引):
RPC_GET_BULK_CONFIG = """
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<Ifmgr>
</Ifmgr>
<GRPC>
</GRPC>
</top>
"""
(2) 调用对应接口,发送<get-bulk>或<get-bulk-config>报文到服务器端,批量查询当前运行数据和配置数据。
¡ 调用get-bulk接口,发送get-bulk操作RPC请求。
reply = m.get_bulk(filter=('subtree',RPC_GET_BULK))
print(reply)
¡ 调用get-bulk-config接口,发送get-bulk-config操作RPC请求。
reply = m.get_bulk_config(source= "running", filter=('subtree', RPC_GET_BULK_CONFIG))
print(reply)
以下为通过get-bulk或get-bulk-config操作批量获取接口信息的Python程序:
# -*- coding:utf-8 -*-
import sys
import logging
from ncclient import manager
from ncclient import operations
log = logging.getLogger(__name__)
# 通过get-bulk操作获取接口信息的RPC报文。
RPC_GET_BULK = """
<top xmlns="http://www.h3c.com/netconf/data:1.0">
<Ifmgr>
<Interfaces>
<Interface>
<IfIndex>1536</IfIndex>
</Interface>
</Interfaces>
</Ifmgr>
</top>
"""
# 通过get-bulk-config操作获取接口信息的RPC报文。
RPC_GET_BULK_CONFIG = """
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<Ifmgr>
</Ifmgr>
<GRPC>
</GRPC>
</top>
"""
# 建立与设备的连接。
def h3c_connection(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name':"h3c"},
allow_agent = False,
look_for_keys = False)
def test_get_bulk(host, port, user, password):
# 创建NETCONF会话。
with h3c_connection(host,port=port,user=user,password=password) as m:
# 发送get-bulk请求。
reply = m.get_bulk(filter=('subtree',RPC_GET_BULK))
print(reply)
# 发送get-bulk-config请求。
reply = m.get_bulk_config(source= "running", filter=('subtree', RPC_GET_BULK_CONFIG))
print(reply)
if __name__ == '__main__':
test_get_bulk("192.168.56.120", 830, "ssh", "00password00connect ")
(1) 构造RPC action报文。
以清除全部接口的统计信息为例,RPC报文如下:
ACTION_RPC = """
<rpc message-id="{}" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action>
<top xmlns="http://www.h3c.com/netconf/action:1.0">
<Ifmgr>
<ClearAllIfStatistics>
<Clear>
</Clear>
</ClearAllIfStatistics>
</Ifmgr>
</top>
</action>
</rpc>
"""
(2) 下发action报文。
msgid = 100
rpc = ACTION_RPC.format(msgid)
m._session.send(rpc)
time.sleep(2)
以下为通过action操作清除全部接口统计信息的Python程序。
# -*- coding:utf-8 -*-
import sys
import logging
import time
from ncclient import manager
from ncclient import operations
log = logging.getLogger(__name__)
# 通过action操作清除全部接口统计信息的RPC报文。
ACTION_RPC = """
<rpc message-id="{}" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action>
<top xmlns="http://www.h3c.com/netconf/action:1.0">
<Ifmgr>
<ClearAllIfStatistics>
<Clear>
</Clear>
</ClearAllIfStatistics>
</Ifmgr>
</top>
</action>
</rpc>
"""
# 建立与设备的连接。
def h3c_connection(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name':"h3c"},
allow_agent = False,
look_for_keys = False)
def test_action(host, port, user, password):
# 创建NETCONF会话。
with h3c_connection(host,port=port,user=user,password=password) as m:
n = m._session.id
print("This session id is %s."%(n))
# 发送action报文。
msgid = 100
rpc = ACTION_RPC.format(msgid)
m._session.send(rpc)
time.sleep(2)
if __name__ == '__main__':
test_action("192.168.56.120", 830, "ssh", "00password00connect ")
(1) 构造订阅报文,RPC报文如下:
# 创建netconf订阅报文。
Rpc4Subscription = """<rpc message-id="{}" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>NETCONF</stream>
</create-subscription>
</rpc>
"""
# 订阅ifmgr事件。
RPC4Ifmgr = """
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xs="http://www.h3c.com/netconf/base:1.0">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>Ifmgr</stream>
</create-subscription>
</rpc>
"""
(2) 下发事件订阅报文。
# 为rpc设置Message ID。
msgid = 100
rpc = Rpc4Subscription.format(msgid)
# 发送订阅报文。
m._session.send(rpc)
m._session.send(RPC4Ifmgr))
(3) 等待事件信息上报。
m.take_notification(block=True,timeout=100)
以下为订阅设备上接口管理事件的Python程序:
# -*- coding:utf-8 -*-
import sys
import logging
import time
from ncclient import manager
from ncclient import operations
from ncclient.operations import CreateSubscription
log = logging.getLogger(__name__)
# 创建netconf订阅的RPC报文。
Rpc4Subscription = """<rpc message-id="{}" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>NETCONF</stream>
</create-subscription>
</rpc>
"""
# 订阅ifmgr事件的RPC报文。
RPC4Ifmgr = """
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xs="http://www.h3c.com/netconf/base:1.0">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>Ifmgr</stream>
</create-subscription>
</rpc>
"""
# 建立与设备的连接。
def h3c_connection(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name':"h3c"},
allow_agent = False,
look_for_keys = False)
def test_notification(host, port, user, password):
# 创建NETCONF会话。
with h3c_connection(host,port=port,user=user,password=password) as m:
n = m._session.id
print("This session id is %s."%(n))
# 为RPC设置Message ID。
msgid = 100
rpc = Rpc4Subscription.format(msgid)
# 发送订阅报文。
m._session.send(rpc)
m._session.send(RPC4Ifmgr)
# 等待事件信息上报。
m.take_notification(block=True,timeout=100)
if __name__ == '__main__':
logging.basicConfig(level=logging.DEBUG)
test_notification("192.168.56.120", 830, "ssh", "00password00connect ")
· XML中如果存在Schema错误,则请求不继续处理,直接返回错误。Schema错误检查中,有些检查可能被多种形式的约束条件来检查,此时返回的错误信息与XSD的约束条件有关,具体情况,请参考对应的XSD文件。
· 本节列举的错误是常规情况下的返回值。依据模块不同,返回的错误信息可能更加详细。
· 如果Schema错误中的值过长,则该值有可能被截断。比如,如下XML报文中时间“2014-13-18T17:03:”是被截断的,此时请使用Xpath确认错误元素或者属性位置。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>NETCONF</stream>
<filter>
<event xmlns="http://www.h3c.com/netconf/event:1.0">
<Code>SHELL_LOGIN</Code>
</event>
</filter>
<startTime>2014-07-13T17:00:59</startTime>
<stopTime>2014-13-18T17:03:05</stopTime>
</create-subscription>
</rpc>
<error-message xml:lang="en">
The value of element '/rpc/create-su
bscription[1]/stopTime[1]' is invalid. 2014-13-18T17:03: is an invalid value of
datetime type value.
</error-message>
Comware根据Schema对用户XML请求进行基本的格式验证,保证在大部分情况下请求格式是无误的。
表7-1 Schema错误说明
错误提示 |
场景说明 |
错误样例 |
Expecting element 'path'. |
必须的元素缺失,其Xpath路径为path |
|
The element 'a' should have an attribute 'b'. |
元素a必须的属性b缺失 |
|
The value of element 'a' is invalid. reason |
元素的a值无效,具体原因是:reason。reason可能取值请参见表7-2 |
|
The value of attribute 'a' for element 'b' is invalid. reason |
元素b的属性a的值无效,具体原因是:reason。reason可能取值请参见表7-2 |
|
The number of occurrences of element '%s/%s' is invalid. |
元素出现的次数不正确 |
|
Unexpected element '%s'. |
%s元素不应在此出现 |
|
Unexpected attribute '%s' of element '%s'. |
元素%s中不应出现%s属性 |
|
The child elements of '%s' are invalid. |
指定位置元素下的子元素出现次数不正确 |
|
Element '%s' can not have a textual child element. |
元素%s不能包含文本 |
|
Element '%s' can not have a child element. |
元素%s不能包含子节点 |
表7-2 Schema元素或者属性值错误的具体情况
错误原因 |
场景说明 |
错误样例 |
value is an invalid value of type type value. |
元素或者属性的值不是一个有效的XSD类型的值 · value:XML中元素或者属性的值,如果值过长,将被截断 · type:当前错误位置的数据类型,报告的类型是XSD的数据类型名称 |
|
%s cannot be empty. |
元素值不能为空 |
|
The value does not match the regular expression. |
元素值和XSD定义的正则表达式不匹配 |
|
The value does not match the enumeration. |
元素值和XSD定义的enumeration枚举值不匹配 |
|
The length must be equal to %s. |
元素长度和XSD定义的长度不相等 |
|
The total digit length must be equal to %s. |
元素的数字总长度和XSD定义的长度不相等 |
|
The length must be less than or equal to %s. |
元素的长度大于XSD定义的maxLength最大长度 |
|
The length must be greater than or equal to %s. |
元素的长度小于XSD定义的minLength最小长度 |
|
The value must be less than %s. |
元素的值大于等于XSD定义的maxExclusive最大值 |
|
The value must be greater than %s. |
元素的值小于等于XSD定义的minExclusive最小值 |
|
The value must be less than or equal to %s. |
元素的值大于XSD定义的maxInclusive最大值 |
|
The value must be greater than or equal to %s. |
元素的值小于XSD定义的minInclusive最小值 |
表7-3 NETCONF处理中的错误说明
错误提示 |
场景说明 |
错误样例 |
Invalid value. |
设置操作的值不符合模块要求 |
|
Can't issue the configuration because of configuration conflict. |
设置操作的配置与系统现有配置冲突 |
视具体模块而定 |
Configuration already exists. |
执行Create操作时,要创建的配置已存在(配置不是默认值) |
|
Configuration target does not exist. |
SET的对象不存在 |
|
Configuration does not exist. |
执行Delete操作,要删除的配置不存在(配置为默认配置) |
|
Current session has held the lock. |
在同一个会话中,对当前配置重复加锁 |
|
Unlock failed because no NETCONF lock exists. |
在同一个会话中,对当前配置重复解锁 |
|
Unlock Failed because the lock is not held by current session. |
在非当前会话中,对已加锁的配置进行解锁 |
|
Lock failed because the NETCONF lock is held by another session. |
在非当前会话中,对已加锁的配置进行加锁 |
|
Can not edit tables with only table names. |
执行Delete操作,请求报文中只指定到表 |
|
When the delete or remove operation is issued, data cannot be assigned to non-index columns. |
执行Delete或Remove操作时,普通列不能带值 |
|
When the delete or remove operation is issued, data cannot be assigned to non-index columns. |
下发删除操作时,索引列不可以不指定值 |
|
When the create, merge, or replace operation is issued, empty data cannot be assigned to columns. |
下发create/merge/replace等操作时,列不可以不指定值 |
|
For a <get-bulk> or <get-bulk-config> operation request, a table can't contain both non-index columns and subtables, and it can contain only one subtable. |
执行get-bulk操作或get-bulk-config操作时,请求报文中同时包含了普通列和子表 |
|
When the create, merge, or replace operation is issued, empty data cannot be assigned to columns. |
执行create、merge或replace操作时,普通列带空值 |
|
The configuration not supported on the specified target. |
当前对象不支持此配置 在一个只支持二层接口的表里,下发了一个三层接口来进行设置操作,也会返回此错误 |
|
The session does not have the privilege to process the request. |
当前用户对当前对象没有RBAC权限 |
|
Resources are insufficient for processing the request. |
系统资源不足,不能完成本次操作。比如,配置资源已经达到了系统规格上限 |
|
The system does not support this operation. |
不支持当前操作 |
视具体模块而定 |
Operation failed. |
上面所述场景之外的错误 |
|
The session cannot kill itself. |
在当前会话中删除当前会话 |
|
Hello is required before any other operation. |
创建订阅时没有先发送hello报文 |
|
Event subscription already exists. |
重复创建相同事件流的订阅 |
|
The event stream name can't be empty. |
创建订阅时,<stream>标签中没有填写事件流名称 |
|
You don't have the privilege to perform this NETCONF operation. |
当前用户没有创建订阅的RBAC权限 |
|
You don't have the privilege to subscribe the event-name event. |
当前用户没有订阅指定事件流中具体事件的RBAC权限,创建订阅失败 |
|
The element stopTime is required. |
创建订阅时指定了startTime而没有指定stopTime |
|
The startTime should be earlier than the current system time. |
创建订阅时,startTime晚于当前时间 |
|
The startTime should be earlier than the stopTime. |
创建订阅时,startTime晚于stopTime |
|
The stopTime should be later than the current system time. |
创建订阅时,stopTime早于当前时间 |
|
Maximum number of NETCONF sessions exceeded. |
创建NETCONF会话的个数达到上限 |
|
Operation failed. flash:/startup.cfg can't be overwritten because the OverWrite flag is false. |
执行NETCONF的save操作时,OverWrite属性值为false |
|
Failed to set HTTPS server status because the specified SSL server policy doesn't exist. |
设置一个不存在的ssl server-policy |
|
The replace operation does not support incremental-edit. |
增量下发不支持replace操作 |
|
The incremental column must have value. |
增量下发的列必须有值 |
|
The value of attribute 'count' is invalid. Ancestor node index is incomplete. |
执行get或get-bulk操作时,子表节点指定count,其祖先节点索引列不全 |
|
The NETCONF_MONITOR_EXTENSION stream must include filter information. |
订阅监控事件必须包含过滤信息 |
|
The NETCONF_MONITOR_EXTENSION stream must have NetconfMonitor information. |
订阅监控事件必须包含NetconfMonitor信息 |
|
Incorrect name for Stream NETCONF_MONITOR_EXTENSIO. |
创建订阅时,流名称错误 |
|
The subscribing to event time must be in the range of 1970 to 2035. |
创建订阅时,startTime或stopTime的时间不在1970年-2035年之间 |
|
The value %s of attribute 'match' is invalid. |
match属性指定的值不正确。 |
|
The value of the ColumnValue parameter for column HostName can't be empty. |
下发事件订阅报文时指定的列的值不能为空。 |
|
Unexpected element: |
报文中的元素位置错误。可能是未定义的元素,或该元素前的元素缺失等原因导致。 |
|
Incorrect column name for column %s of XPath %s. |
NetconfMonitor订阅报文中ColumName值指定错误,指定XPATH下没有该列。 |
|
XPath %s is wrong. Valid format is ModuleName[/SubmoduleName]/TableName. |
事件订阅报文中指定的XPATH错误。 |
Comware系统中,部分数据类型难以使用Schema标准方式简单描述。为了方便检查使用,这些类型的检查被作为内置实现,在外表现为string类型,但其逻辑检查不是执行的string类型。内置类型都定义在basetype.xsd中。Comware支持的内置类型如表7-4所示。
表7-4 Schema内置类型
名称 |
检查逻辑说明 |
OID |
点分的32位整数,最多128个分节 |
_Ipv6Address |
按照IPv6地址规范来检查 |
IPV6_ADDR_PREFIX |
按照IPv6地址前缀规范来检查 |
_PortRange |
用连字符(-)和逗号(,)分割的多段范围字符串,形如1,3-9,11,12。两端和中间不能有空格,不能有其他字符,数字必须从小到大排列,数字范围是0~65535 |
_VlanRange |
连字符(-)和逗号(,)分割的多段范围字符串,形如1,3-9,11,12。两端和中间不能有空格,不能有其他字符,数字必须从小到大排列,数字范围是1~4094 |
_Ipv4Mask |
按照IPv4的掩码逻辑来检查 |
_IfIndexRange |
用连字符(-)和逗号(,)分割的多段范围字符串,形如1,3-9,11,12。两端和中间不能有空格,不能有其他字符,数字必须从小到大排列,数字范围是1~0xBFFFFFFF |
Schema中的boolean在不同系统中的实现有所不同。有些系统中取值为true、false,而有些系统中除true、false外,还支持取值1和0。在Comware系统中,为了保持兼容,Boolean/boolean的有效值为true、false、1和0。其中,true和1都是真,false和0都为假。
NETCONG API文档中,对于boolean/Boolean只列举了true和false取值,但其实它们也可能支持1和0。
某些表中,存在某些列在部分情况下支持、部分情况下不支持的情况。此时,对于delete/remove操作,这些列会返回成功,以便于只下发索引时能够不返回错误。
同时存在IP和掩码时,为了不出现错误的结果,建议不要下发IP和Mask作用后的结果导致IP变化的请求。比如,不建议下发如下请求,因为Mask影响IP的结果,导致IP实际为192.168.0.0。IP:192.168.1.1 Mask:255.255.0.0
默认情况下,get、get-config、get-bulk、get-bulk-config、edit-config、action中的元素可以按照任意顺序下发。但某些表存在可以重复的分组元素,此时这些表中的列必须按照顺序下发。为了保证下发请求时不出现错误,请尽量按照NETCONF API文档中XML结构里罗列的XML出现顺序进行下发。
举例:IRF/IRFPorts表的xml api如下:
<IRF>
<IRFPorts>
<IRFPort>
<MemberID></MemberID>
<Port></Port>
<Interface>
<IfName></IfName>
<MDCName></MDCName>
<Mode></Mode>
</Interface>
</IRFPort>
</IRFPorts>
</IRF>
其中,IfName、MDCName 、Mode列均属一个同一个可重复组“Interface”,因此客户端下发报文时需要按照xml api规定的顺序下发:
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://www.h3c.com/netconf/config:1.0">
<IRF>
<IRFPorts xc:operation="merge">
<IRFPort>
<MemberID>1</MemberID>
<Port>2</Port>
<Interface>
<IfName>Ten-GigabitEthernet1/0/48</IfName>
<Mode>1</Mode>
</Interface>
<Interface>
<IfName>Ten-GigabitEthernet1/0/49</IfName>
<Mode>1</Mode>
</Interface>
</IRFPort>
</IRFPorts>
</IRF>
</top>
</config>
</edit-config>
</rpc>