本文通过一次登录交换机失败的问题，挖了下，学到一种基于XML的netconf(Network Configration Protocol)协议，在telnet等客户端通过netconf协议从交换机服务端对交换机配置进行增删改查操作。
https://quickview.cloudapps.cisco.com/quickview/bug/CSCve54024
Description (partial)
Symptom现象:
Netconf locks the configs but never releases it:
Line 973: Apr 18 18:42:34.638 DST: NETCONF:Simultaneous configs not allowed: locked from <user> on vty1 (Source IP)
Conditions条件:
This is happening while CG-NMS is pushing configs via Netconf. However, the issue is likely possible using Netconf with other applications.
Workaround:
Remove all netconf configs. Enable exclusive lock mode then disable it again:
configuration mode exclusive
no configuration mode exclusive
Then re-add the Netconf configs.
遇到的问题(本人不是使用的思科交换机，报错内容类似，这里只是拿过来对比学习下)
交换机配置估计是设置了单用户登录模式，ssh登录只能一个用户登录。
上一次ssh登录没有正常退出，通过串口登录后查看ssh登录连接还在，导致下次无法正常登录。
感觉这块的连接释放不知道有没有问题，这个没有深究，直接将交换机掉电后重启正常了。
思科给的解决方法查下是干嘛的
1) configuration mode exclusive (exclusive lock mode) 这是一个什么模式，什么处理机制
exclusive lock mode翻译为独占锁模式
看华为交换机手册上的解释：configuration exclusive命令用来锁定系统当前配置。在锁定期间，执行锁定配置的用户可以进行查询、配置等动作，其他用户只能进行查询动作。
undo configuration exclusive命令用来解除锁定的配置权限。
缺省情况下，配置权限不锁定。
应用场景：设备允许多用户接入进行配置，但是在多用户登录的情况下，如果用户同时进行手动配置，很可能会出现配置冲突问题，导致业务异常。此时，可执行本命令实现一个用户锁定配置并进行配置动作，其他用户只能查询而不能修改配置。从而保证业务正常。
如果用户需要解除当前锁定的配置权限，可通过如下两种方式实现：
执行undo configuration exclusive命令，解除当前锁定的配置权限。
如果在允许锁定的最长时间间隔内没有任何配置更新，系统将自行解除锁定。允许锁定的最长时间间隔可通过configuration-occupied timeout命令设置。
lock命令的应用场景：为了防止别的用户操作设备，可以使用该命令锁住当前用户界面。用户界面包括Console口和VTY虚拟终端用户界面。用户输入命令lock后，系统提示输入两次屏保密码，如果两次输入的密码相同，则锁定当前用户界面成功。
2) Netconf configs (pushing configs via Netconf)通过Netconf配置交换机
NETCONF协议(Network Configration Protocol)是一个基于XML的交换机配置接口，用于替代CLI、SNMP等配置交换机。
本质上，NETCONF利用XML-RPC的通讯机制实现配置客户端和配置服务端之间的通信，实现对网络设备的配置和管理。
NETCONF通过RPC与交换机通信，协议包含四层
i. 安全传输层，用于跟交换机安全通信，NETCONF并未规定具体使用哪种传输层协议，所以可以使用SSH、TLS、HTTP等各种协议，官方默认使用SSH进行加密及数据传输
ii.消息层，提供一种传输无关的消息封装格式，用于RPC通信，消息层流程如下：NETCONF中定义了三种消息类型，分别是hello， rpc和rpc-reply, notification。
Ø <hello>
<hello>仅用于回话刚刚建立时netconf-server和netconf-client之间进行能力交换。
server和client需要在回话建立后互相发送<hello>消息，并在<hello>消息中携带自身支持的能力，以及支持的netconf协议的版本号，server和client根据自身和对方的能力信息协商使用的netconf版本。
一般来说，C/S双方互发<hello>且协商版本成功后，认为netconf会话建立成功。操作层，定义了一系列的RPC调用方法，并可以通过Capabilities来扩展
几种常用能力：
(1) XPath Capability表示client可以在filter中使用XPath表达式作为过滤条件
(2) Writable-Running Capability表示server支持直接对<running/>库进行修改操作。
(3) Candidate Configuration Capability表示server具有一个candidate数据库，并可以将candidate数据库中的配置提交生效并更新running数据库
(４) Rollback-on-Error Capability表示server在执行client发送的配置数据出错后可以进行回滚
(５) Validate Capability表示server可以校验client发送的配置数据是否正确
(６) Distinct startup Capability表示server有一个startup数据库，用于保存启动配置
Ø rpc和rpc-reply,
<rpc>由netconf-client发起的发送到netconf-server的消息。用于client请求server执行某项具体的操作。<rpc>包含一个强制属性”message-id”，这个id是一个单调递增的正整数，同一会话内不能重复。该id用于<rpc>和<rpc-reply>的配对。
<rpc-reply>是有netconf-server发送给netconf-client的rpc响应。不能主动发起，仅能在收到<rpc>之后回复，切必须携带与收到的rpc相同的message-id。在<rpc-reply>定义了两种默认的元素分别是<ok>和<rpc-error>。<ok>表示未定义响应内容的rpc执行成功，而<rpc-error>表示rpc执行失败。
Ø notification
持Notification上报的netconf-server需在能力交换时上报能力：
1. Netconf的通知采用的是订阅发布机制，server仅会向发送过订阅请求的client发送通知。
2. Netconf的通知是以Stream进行分类的，不同类的Stream以不同的stream-name进行区分。netconf-server默认需要支持的stream-name是”NETCONF”。
3. client不能重复下发订阅，即同一Stream的订阅不能重复下发，也不能同时订阅多个Stream，订阅可以设置定时取消，如果没有设置终止时间，取消订阅需要使用close-session或者kill-session。定时取消的订阅netconf的会话还是激活的，而使用close-session或者kill-session来取消的话，netconf会话会关闭。
iii.操作层，NETCONF提供了九种基本操作：
Ø get-config 用于查询配置数据
Ø edit-config 用于对指定配置数据库的内容进行修改，支持以下几种操作：
merge: 合并操作，此操作为默认操作。
replace: 替换操作，如果对象已经存在则替换，不存在则创建。
create: 创建操作，如果对象已经存在，则报错误“data-exists”。
delete: 删除操作，如果对象存在则删除，不存在则报错 “data-missing”。
remove: 删除操作，如果对象存在则删除，不存在则忽略。
Ø copy-config 将一个库的数据复制到另一个库
Ø delete-config 删除一个数据库。但是<running/>库不能被删除。
Ø lock 获取指定数据库的锁，当某个client获得了指定数据库的锁之后，在其没有释放该锁之前，其余client均不能获得该数据库的锁，也不能对其进行修改操作。同一client也不能在没有释放锁之前，重复申请锁。 获取锁的主要目的就是避免并发导致数据冲突。
Ø unlock释放指定数据库的锁。client只能释放自己持有的锁，不能释放其它client的锁。
Ø get 用于查询状态数据
Ø close-session 优雅关闭netconf会话，netconf-server将释放该client持有的锁和为其分配的资源，并优雅的关闭与该client链接。
Ø kill-session 强制关闭netconf会话。
get-config请求报文解析流程B
iv.内容层，定义RPC调用的数据内容，即配置数据库
NETCONF实现流程：
NETCONF协议使用基于RPC的通信模型。 NETCONF对等体使用<rpc>和<rpc-reply>元素来提供NETCONF请求和响应的传输协议无关帧。
<rpc>元素用于封装从客户端发送到服务器的NETCONF请求。<rpc>元素有一个强制属性“message-id”，它是由RPC的发送者选择的一个字符串，它通常编码一个单调递增的整数。 RPC的接收者不解码或解释这个字符串，只是简单地保存它在任何生成的<rpc-reply>消息中用作“message-id”属性。
<rpc-reply>响应<rpc>操作发送<rpc-reply>消息。<rpc-reply>元素有一个强制属性“message-id”，它等于这是一个响应的<rpc>的“message-id”属性。
响应名称和响应数据被编码为<rpc-reply>元素的内容。 回复的名字是直接在<rpc-reply>元素中的一个元素，任何数据都在这个元素内编码。
如果在处理<rpc>请求期间发生错误，<rpc-error>元素将在<rpc-reply>消息中发送。
如果服务器在处理<rpc>请求期间遇到多个错误，<rpc-reply>可能包含多个<rpc-error>元素。但是，如果请求包含多个错误，则服务器不需要检测或报告多个<rpc-error>元素。
服务器不需要按照特定的顺序检查特定的错误条件。如果在处理期间出现任何错误情况，服务器务必返回一个<rpc-error>元素，并且如果在处理期间出现任何警告条件，应该返回一个<rpc-error>元素。
服务器绝对不能在客户端没有足够访问权限的<rpc-error>元素中返回应用级或数据模型特定的错误信息。
error-type：定义错误发生的概念层，下列类型之一。
Ø transport (layer: Secure Transport)
Ø rpc (layer: Messages)
Ø protocol (layer: Operations)
Ø application (layer: Content)
error-tag：包含识别错误条件的字符串。
error-severity：包含标识错误严重性的字符串，由设备确定。 下列之一：
Ø error
Ø warning
error-app-tag：包含标识数据模型特定或特定于实现的错误条件（如果存在）的字符串。
error-path：包含绝对XPath表达式，用于标识<rpc-error>元素中报告的错误关联的节点的元素路径。 如果没有适当的有效载荷元素或数据存储节点可以与特定的错误条件相关联，则该元素将不存在。
error-message：包含一个适合人类阅读的字符串，用于描述错误情况
error-info：包含协议或数据模型特定的错误内容。
