NETCONF 会话
了解 Junos 设备上的 NETCONF 会话。
您可以使用网络配置协议 （NETCONF） 管理网络设备。以下各节概述了 Junos 设备上的 NETCONF 会话。
使用 SSH 连接到 NETCONF 服务器
连接到 NETCONF 服务器的最常见方法是使用 SSH。在 NETCONF 客户端可以使用 SSH 连接到 NETCONF 服务器之前，必须满足为 NETCONF 会话建立 SSH 连接中所述的要求。满足先决条件后，NETCONF 客户端可以使用下列方法之一连接到 NETCONF 服务器：
SSH 库例程
NETCONF 客户端使用 SSH 库例程建立与 NETCONF 服务器的 SSH 连接，提供身份验证，并创建用作 NETCONF 会话的 SSH 子系统的通道。提供有关使用库例程的说明超出了本文档的范围。ssh 命令
您可以将 NETCONF 会话建立为具有专用端口的 SSH 子系统。或者，您可以通过默认 SSH 端口建立 NETCONF 会话并使用伪 tty 分配。通过专用端口使用 SSH 子系统可以让设备轻松识别和过滤 NETCONF 流量。但是，使用具有伪 tty 分配的默认 SSH 端口可以提供会话可见性，例如在发出 show system users 作命令时。
应用程序必须包含用于拦截 NETCONF 服务器提示输入密码或密码短语的代码。例如，应用程序可以使用命令等 expect 实用程序。
-
要通过默认的 NETCONF 端口 （830） 将 NETCONF 会话建立为 SSH 子系统，客户机应用程序发出以下命令：
ssh user@hostname -p 830 -s netconf
该
-p选项定义 NETCONF 服务器侦听的端口号。如果通过默认端口启用对 SSH 的访问，则可以省略此选项。该
-s选项会将 NETCONF 会话建立为 SSH 子系统。 -
要通过默认 SSH 端口 （22） 建立 NETCONF 会话并使用伪 tty 分配，客户机应用程序发出以下命令：
ssh user@hostname -t netconf
注意：即使 SSH 没有本地 tty，使用多个
-t选项也会强制进行伪 tty 分配。
启动 NETCONF 会话
每个 NETCONF 会话都以握手开始，在握手中，NETCONF 服务器和客户端应用程序指定它们支持的 NETCONF 功能。以下部分介绍如何启动 NETCONF 会话。
交换 <hello> 标签元素
NETCONF 服务器和客户端应用程序首先发出一个 <hello> 标记元素，以指定它们从 NETCONF 规范中定义的作或功能中支持哪些作或 功能。客户端应用程序必须在任何其他元素之前发出该 <hello> 元素，并且只能发出一次。
标记 <hello> 包含以下元素：
-
<capabilities>- 元素列表，每个元素定义一个受支持的<capability>函数。 -
<session-id>- 会话的 NETCONF 服务器的 UNIX 进程 ID （PID）。
NETCONF 规范中定义的每个功能都以统一资源名称 （URN） 表示。 <capability> 各个供应商定义的功能以统一资源标识符 （URI） 表示，URI 可以是 URN 或 URL。NETCONF 服务器发出 <hello> 类似于以下输出的元素：
<hello>
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
<capability>
urn:ietf:params:netconf:capability:confirmed-commit:1.0
</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>
urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file
</capability>
<capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>
<capability>
urn:ietf:params:xml:ns:netconf:capability:candidate:1.0
</capability>
<capability>
urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0
</capability>
<capability>
urn:ietf:params:xml:ns:netconf:capability:validate:1.0
</capability>
<capability>
urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file
</capability>
<capability>http://xml.juniper.net/netconf/junos/1.0</capability>
<capability>http://xml.juniper.net/dmi/system/1.0</capability>
</capabilities>
<session-id>22062</session-id>
</hello>
元素中的 <hello> URI 指示支持的功能。 表 1 列出了一些常用功能。
| 能力 |
描述 |
|---|---|
|
|
NETCONF 服务器支持基本 NETCONF 规范中定义的基本作和元素。 |
|
|
NETCONF 会话符合 RFC 6242 标准，该标准支持用于消息成帧的分块成帧机制。 |
|
|
NETCONF 服务器支持对候选配置进行作。 |
|
|
NETCONF 服务器支持已确认的提交作。 有关详细信息，请参阅 仅在使用 NETCONF 进行确认后提交候选配置 |
|
|
NETCONF 服务器支持验证作，该作无需实际提交即可验证配置的语法正确性。 有关更多信息，请参阅 使用 NETCONF 验证候选配置语法。 |
|
|
NETCONF 服务器接受存储在文件中的配置数据。它可以使用 HTTP 或 FTP 从其本地文件系统和远程计算机检索文件。 有关详细信息，请参阅 在 NETCONF 会话中上传配置数据并设置其格式化。 |
|
|
NETCONF 服务器支持：
NETCONF 客户端应用程序应仅使用本机 NETCONF作和受支持的 Junos XML 协议扩展来进行配置功能。相应的 Junos XML 协议作和 NETCONF XML 协议作的语义不一定完全相同，因此使用文档支持的扩展以外的 Junos XML 协议配置作可能会导致意外结果。 |
|
|
NETCONF 服务器支持设备管理接口 （DMI） 规范中定义的作。 |
默认情况下，NETCONF 服务器不会在 NETCONF 功能交换中播发受支持的 YANG 模块。要播发受支持的 YANG 模块，请在 [edit system services netconf hello-message yang-module-capabilities] 层次结构级别配置以下一个或多个语句：
advertise-custom-yang-modules- 通告设备上安装的第三方 YANG 模块。advertise-native-yang-modules—通告 Junos OS 原生 YANG 模块。advertise-standard-yang-modules—通告设备支持的标准 YANG 模块，例如 OpenConfig 模块。
为了符合 NETCONF 规范，客户端应用程序还会发出一个 <hello> 元素来定义它支持的功能。它不包括以下 <session-id> 元素：
<hello>
<capabilities>
<capability>first-capability</capability>
<!-- tag elements for additional capabilities -->
</capabilities>
</hello>
]]>]]>
NETCONF 会话使用成帧机制来分离 NETCONF 服务器和客户端在会话中发送的消息。默认情况下，与 Junos 设备的 NETCONF 会话使用字符序列 ]]>]]> 作为消息分隔符。但是，如果配置符合 RFC 6242 的 NETCONF 会话，并且两个对等方都在功能交换中播发该 :base:1.1 功能，则 NETCONF 会话将在会话的剩余时间内使用分块成帧。分块成帧是一种标准化的成帧机制，可确保 XML 元素中的字符序列不会被误解为消息边界。有关详细信息，请参阅 配置符合 RFC 的 NETCONF 会话。
当客户端应用程序向 NETCONF 服务器发送请求时，会话将继续。NETCONF 服务器在会话初始化后不会发出任何元素，除非是为了响应客户端应用程序的请求。
验证兼容性
通过交换 <hello> 标签元素，NETCONF 服务器和客户端可以确定它们是否支持相同的功能。此外，我们建议客户端应用程序确定 NETCONF 服务器上运行的 Junos OS 版本。发出其 <hello> 标记后，客户端应用程序可以发出 <get-software-information> 请求。
<rpc>
<get-software-information/>
</rpc>
]]>]]>
NETCONF 服务器返回该 <software-information> 元素，该元素根据 Junos OS 变体包含不同的标记。Junos OS 返回每个软件模块的 <host-name> 和 <product-name> 标记元素加上一个 <package-information> 元素。这些 <comment> 元素以 YYYYMMDD 格式指定 Junos OS 版本和构建日期。在以下示例中，版本 8.2 适用于Junos OS版本 8.2，构建日期为20070112（2007 年 1 月 12 日）。
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" \
xmlns:junos="http://xml.juniper.net/junos/8.2R1/junos">
<software-information>
<host-name>router1</host-name>
<product-name>m20</product-name>
<package-information>
<name>junos</name>
<comment>JUNOS Base OS boot [8.2-20070112.0]</comment>
</package-information>
<package-information>
<name>jbase</name>
<comment>JUNOS Base OS Software Suite \
[8.2-20070112.0]</comment>
</package-information>
<!-- <package-information> tag elements for additional modules -->
</software-information>
</capabilities>
</rpc-reply>
]]>]]>
通常，设备上运行的所有 Junos OS 模块的版本都是相同的（为了实现可预测的路由性能，我们建议使用此配置）。因此，通常仅验证一个模块的版本号就足够了。
客户端应用程序负责确定如何处理版本或功能上的任何差异。为了实现完全自动化的性能，请在客户端应用程序中包含代码，以确定它是否支持与 NETCONF 服务器相同的功能和 Junos OS 版本。当存在差异时，确定以下哪个选项是合适的，并实施相应的响应：
-
忽略差异 — 忽略功能和 Junos OS 版本方面的差异，并且不要改变客户端应用程序的行为来适应 NETCONF 服务器。Junos OS 版本的差异并不一定意味着服务器和客户端不兼容，因此这通常是一种有效的方法。同样，如果客户端应用程序不支持的功能是始终由客户端启动的作（如配置验证和确认提交），则这是一种有效的方法。在这种情况下，客户端通过不启动作来保持兼容性。
-
更改标准行为以使其与 NETCONF 服务器兼容 - 例如，如果客户端应用程序运行的是更高版本的 Junos OS，则可以选择仅发出 NETCONF 和 Junos XML 标记元素，这些元素表示 NETCONF 服务器的 Junos OS 版本中可用的软件功能。
-
结束 NETCONF 会话并终止连接 - 如果您认为无法适应 NETCONF 服务器的版本或功能，请使用此选项。
向 NETCONF 服务器发送请求
如何发送请求
要向 NETCONF 服务器发起请求，客户端应用程序会发出以下命令：
-
打开
<rpc>标签 -
表示特定请求的一个或多个标记元素
-
结束标记
</rpc>
<rpc>
<!-- tag elements representing a request -->
</rpc>
]]>]]>
应用程序将每个请求包含在其单独的一对开始 <rpc> 和结束 </rpc> 标记中。每个请求必须仅包含符合要求且排序正确的标记元素，从而构成格式正确的 XML 文档。NETCONF 服务器会忽略标记流中标记元素之间出现的任何换行符、空格或其他空格字符，但会保留标记元素中的空格。
或者，客户端应用程序可以在每个请求的开始<rpc>标记中包含窗体attribute-name="value"的一个或多个属性。NETCONF 服务器在包含其响应的开始<rpc-reply>标记中呼应每个属性，保持不变。
客户端应用程序可以使用此功能通过在分配唯一标识符的每个打开 <rpc> 请求标记中包含属性来关联请求和响应。NETCONF 服务器在其开始 <rpc-reply> 标记中回显属性，从而可以轻松地将响应映射到发起请求。NETCONF 规范指定此属性的名称 message-id 。
尽管作请求和配置请求在概念上属于不同的类，但 NETCONF 会话并不具有与 CLI作和配置模式相对应的不同模式。每个请求标记元素都包含在自己的 <rpc> 标记中，因此客户端应用程序可以自由交替作和配置请求。客户端应用程序可以发出三类请求：作请求、配置信息请求和配置更改请求。
作请求
作请求 是有关设备状态的信息的请求。作请求对应于 Junos OS CLI作模式命令。Junos XML API 为许多 CLI 命令定义了一个请求标记元素。例如， <get-interface-information> tag 元素对 show interfaces 应于命令，并且 <get-chassis-inventory> tag 元素请求与 show chassis hardware 命令相同的信息。
以下 RPC 请求有关接口 ge-2/3/0 的详细信息：
<rpc>
<get-interface-information>
<interface-name>ge-2/3/0</interface-name>
<detail/>
</get-interface-information>
</rpc>
]]>]]>
有关作请求的详细信息，请参阅 使用 NETCONF 请求作信息。
有关 Junos XML 请求标记的信息，请参阅 XML API 资源管理器。
配置信息请求
配置信息请求 是请求有关设备的候选配置、专用配置、临时配置或已提交（活动）配置的信息。当候选配置有未提交的更改时，候选配置和提交的配置会有所不同。
NETCONF 协议定义 <get-config> 用于检索配置信息的作。Junos XML API 为配置层次结构中的每个容器和叶语句定义一个标记元素。
以下示例从候选配置的 [edit system login] 层次结构级别请求信息：
<rpc>
<get-config>
<source>
<candidate/>
</source>
<filter type="subtree">
<configuration>
<system>
<login/>
</system>
</configuration>
</filter>
</get-config>
</rpc>
]]>]]>
有关配置信息请求的详细信息，请参阅 使用 NETCONF 请求配置数据。
有关可用配置标记元素的摘要，请参阅 XML API 资源管理器 。
配置更改请求
配置更改请求 是指更改配置的请求，或提交这些更改以在运行 Junos OS 的设备上将其投入使用状态的请求。NETCONF 协议定义用于更改配置信息的 <edit-config> 和 <copy-config> 作。Junos XML API 为配置层次结构中的每个容器和叶语句定义一个标记元素。
以下示例在候选配置的[edit system login]层次结构级别创建一个admin新的 Junos OS 用户帐户：
<rpc>
<edit-config>
<target>
<candidate/>
</target>
<config>
<configuration>
<system>
<login>
<user>
<name>admin</name>
<full-name>Administrator</full-name>
<class>superuser</class>
</user>
</login>
<login/>
</system>
</configuration>
</config>
</edit-config>
</rpc>
]]>]]>
有关配置更改请求的详细信息，请参阅 使用 NETCONF 编辑配置。
有关可用配置标记元素的摘要，请参阅 XML API 资源管理器 。
解析 NETCONF 服务器响应
NETCONF 服务器响应概述
在 NETCONF 会话中，客户端应用程序将 RPC 发送到 NETCONF 服务器，以请求信息和管理设备配置。NETCONF 服务器将其对每个客户端请求的响应包含在一对单独的开始 <rpc-reply> 和结束 </rpc-reply> 标记中。每个响应都构成一个格式正确的 XML 文档。
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" \
xmlns:junos="http://xml.juniper.net/junos/release/junos" \
[echoed attributes]>
<!-- tag elements representing a response -->
</rpc-reply>
]]>]]>
xmlns开始<rpc-reply>标记中的属性定义封闭标记元素的命名空间，这些junos:元素的名称中没有前缀，并且未包含在具有不同值属性的xmlns子容器标记中。
如果在设备上配置该 rfc-compliant 语句，则 NETCONF 服务器会显式声明绑定到 nc 前缀的 NETCONF 命名空间，并使用前缀限定其回复中的所有 NETCONF 标记。
该 xmlns:junos 属性定义由 junos: 前缀限定的封闭 Junos XML 标记元素的默认命名空间。 release URI 中的变量表示在 NETCONF 服务器设备上运行的 Junos OS 版本，例如 20.4R1。
客户端应用程序必须包含用于解析来自 NETCONF 服务器的响应标记元素流的代码，要么在它们到达时对其进行处理，要么在响应完成之前存储它们。NETCONF 服务器返回三类响应：作响应、配置信息响应和配置更改响应。
作响应
作响应 是指对有关交换、路由或安全平台状态的信息请求的响应。它们与 CLI作命令的输出相对应。
Junos XML API 为所有已定义的作请求标记元素定义响应标记元素。例如，NETCONF 服务器返回名为 <interface-information>的响应标记中标记请求<get-interface-information>的信息。类似地，服务器在名为 <chassis-inventory>的响应标记中返回标记请求<get-chassis-inventory>的信息。
默认情况下，服务器以 XML 格式返回作响应。客户端应用程序还可以请求服务器以格式化的 ASCII（包含在元素中 output ）或 JSON 格式返回响应。有关设置作响应格式的详细信息，请参阅 指定 NETCONF 会话中作信息请求的输出格式。
以下示例作响应包含有关接口 ge-2/3/0 的信息：
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"\ xmlns:junos="http://xml.juniper.net/junos/20.4R1/junos"> <interface-information \ xmlns="http://xml.juniper.net/junos/20.4R1/junos-interface"> <physical-interface> <name>ge-2/3/0</name> <!-- other data tag elements for the ge-2/3/0 interface - -> </physical-interface> </interface-information> </rpc-reply> ]]>]]>
有关作响应标记元素的 xmlns 属性和内容的详细信息，请参阅 使用 NETCONF 请求作信息。
配置信息响应
配置信息响应 是对有关设备当前配置的信息请求的响应。Junos XML API 为配置层次结构中的每个容器和叶语句定义一个标记元素。
以下示例响应包括层次结构级别的配置数据 [edit system login] ：
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"\
xmlns:junos="http://xml.juniper.net/junos/20.4R1/junos">
<data>
<configuration attributes>
<system>
<login>
<user>
<name>admin</name>
<full-name>Administrator</full-name>
<!-- other data tag elements for the admin user -->
</user>
</login>
</system>
</configuration>
</data>
</rpc-reply>
]]>]]>
<configuration>标记中属性的信息，请参阅
使用 NETCONF 指定配置信息请求的源。
配置更改响应
配置更改响应 是对更改设备配置状态或内容的请求的响应。NETCONF 服务器通过返回 <ok/> tag 元素中的 <rpc-reply> 标记来指示请求的成功执行。
<rpc-reply xmlns="URN" xmlns:junos="URL">
<ok/>
</rpc-reply>
]]>]]>
如果作失败， <rpc-reply> 则标记元素将包含一个 <rpc-error> 描述失败原因的元素。
在 NETCONF 和 Junos XML 协议会话中使用标准 API 解析响应标记元素
在 NETCONF 或 Junos XML 协议会话中，客户端应用程序可以通过将传入的 XML 标记元素馈送到基于标准 API（如文档对象模型 （DOM） 或简单 API for XML （SAX））的解析器来处理这些元素。描述如何实现和使用分析器超出了本文档的范围。
DOM 中的例程接受传入的 XML，并在客户端应用程序的内存中构建标记层次结构。还有用于作现有层次结构的 DOM 例程。DOM 实现可用于多种编程语言，包括 C、C++、Perl 和 Java。有关详细信息，请参阅万维网联盟 （W3C） 的 文档对象模型 （DOM） 级别 1 规范 ，网址为 http://www.w3.org/TR/REC-DOM-Level-1/ 。更多信息可从 Comprehensive Perl Archive Network （CPAN） 获取，网址为 https://metacpan.org/search?q=dist:XML-DOM+dom。
DOM 的一个潜在缺点是它总是构建标签元素的层次结构，这可能会变得非常大。如果客户端应用程序一次只需要处理一个子层次结构，则可以改用实现 SAX 的分析器。SAX 接受 XML 并将标记元素直接馈送到客户端应用程序，后者必须构建自己的标记层次结构。有关详细信息，请参阅 SAX 官方网站 http://sax.sourceforge.net/ 。
处理 NETCONF 会话中的错误或警告
客户端应用程序将 RPC 发送到 NETCONF 服务器，以请求信息和管理设备配置。NETCONF 服务器为每个客户端请求发送响应。如果服务器遇到错误情况，它将发出一个 <rpc-error> 包含描述错误的子元素的元素。
<rpc-reply xmlns="URN" xmlns:junos="URL">
<rpc-error>
<error-severity>error-severity</error-severity>
<error-path>error-path</error-path>
<error-message>error-message</error-message>
<error-info>
<bad-element>command-or-statement</bad-element>
</error-info>
<rpc-error>
</rpc-reply>
]]>]]>
该 <rpc-error> 元素可以包含以下子元素：
-
<bad-element>标识发生错误或警告时正在处理的命令或配置语句。对于配置语句，<error-path>指定语句的父层次结构级别。 -
<error-message>描述自然语言文本字符串中的错误或警告。 -
<error-path>指定发生错误或警告的 Junos OS 配置层次结构级别的路径。 -
<error-severity>指示导致 NETCONF 服务器返回<rpc-error>标记元素的事件的严重性。两个可能的值是error和warning。
当服务器执行以下任一作时，可能会发生错误，并且在每种情况下，服务器可以发送不同的子标记元素组合：
-
处理客户端应用程序提交的作请求
-
根据客户端应用程序的请求打开、锁定、更改、提交或关闭配置
-
解析客户端应用程序在标记元素中提交的
<edit-config>配置数据
客户端应用程序必须准备好随时接收和处理 <rpc-error> 元素。已接收且与当前请求相关的任何响应标记元素中的信息可能不完整。客户端应用程序可以包含用于决定是放弃还是保留信息的逻辑。
<error-severity>当元素的值error为 时，通常的响应是客户端应用程序放弃该信息并终止。<error-severity>当 tag 元素的值warning为 ，指示问题不太严重时，通常的响应是客户端应用程序记录警告或将其传递给用户，并继续分析服务器的响应。
在[edit system services netconf]层次结构级别配置rfc-compliant语句以强制 NETCONF 服务器的某些行为时，NETCONF 服务器无法返回同时包含元素<rpc-error>和元素<ok/>的 RPC 回复。如果作成功，但服务器回复<rpc-error>除元素外<ok/>还包括一个或多个严重性级别为警告的元素，则将省略警告。
另见
锁定和解锁候选配置
当客户端应用程序请求或更改配置信息时，它可以使用以下方法之一访问候选配置：
-
锁定候选配置，这将阻止其他用户或应用程序更改共享配置数据库，直到应用程序释放锁定。这等同于 CLI
configure exclusive命令。 -
在不锁定的情况下更改候选配置。不建议使用此方法，因为可能会与同时编辑共享配置数据库的其他应用程序或用户所做的更改发生冲突。
如果应用程序只是请求配置信息而不进行更改，则不需要锁定配置。应用程序可以立即开始请求信息。但是，如果返回的信息在会话期间不发生更改很重要，则锁定配置是合适的。
锁定候选配置
锁定候选配置可防止其他用户或应用程序更改候选配置，直到解锁锁定为止。这等同于 CLI configure exclusive 命令。建议在进行更改之前锁定配置，特别是在授权多个用户更改配置的设备上。提交作适用于候选配置中的所有更改，而不仅仅是请求提交的用户或应用程序所做的更改。允许多个用户或应用程序同时进行更改可能会导致意外结果。
要锁定候选配置，客户端应用程序将执行作，<lock><target>并将设置为<candidate/>如下所示：
<rpc>
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
]]>]]>
NETCONF 服务器通过返回 <ok/> 标记来确认它已锁定候选者。
<rpc-reply xmlns="URN" xmlns:junos="URL">
<ok/>
</rpc-reply>
]]>]]>
如果 NETCONF 服务器无法锁定配置， <rpc-reply> 则会将包含一个 <rpc-error> 解释失败原因的元素。失败的原因可能包括以下内容：
-
其他用户或应用程序已锁定候选配置。错误消息报告用户或应用程序的 NETCONF 会话标识符。
-
候选配置已包含尚未提交的更改。
一次只有一个应用程序可以锁定候选配置。当候选配置处于锁定状态时，其他用户和应用程序可以读取候选配置。锁定将持续存在，直到客户端应用程序通过发出 <unlock> 标记元素来解锁配置，或者 NETCONF 会话结束。
如果客户端应用程序在提交更改之前解锁候选配置，或者如果 NETCONF 会话在提交更改之前因任何原因结束，则更改将自动丢弃。候选配置和提交的配置保持不变。
解锁候选配置
只要客户端应用程序锁定候选配置，其他应用程序和用户就无法更改候选配置。要解锁候选配置，客户端应用程序将执行该 <unlock> 作。
<rpc>
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
]]>]]>
NETCONF 服务器通过返回 <ok/> 标记来确认它已解锁候选者。
<rpc-reply xmlns="URN" xmlns:junos="URL">
<ok/>
</rpc-reply>
]]>]]>
如果 NETCONF 服务器无法解锁配置， <rpc-reply> 则会将包含一个 <rpc-error> 解释失败原因的元素。
终止 NETCONF 会话
在 NETCONF 会话中，客户端应用程序尝试锁定候选配置可能会失败，因为其他用户或应用程序已持有锁定。在这种情况下，NETCONF 服务器将返回一条错误消息，其中包含持有现有锁的实体的用户名和进程 ID （PID）。
<rpc-reply xmlns="URN" xmlns:junos="URL"> <rpc-error> <error-severity>error</error-severity> <error-message> configuration database locked by: user terminal (pid PID) on since YYYY-MM-DD hh:mm:ss TZ, idle hh:mm:ss exclusive </error-message> </rpc-error> </rpc-reply> ]]>]]>
如果客户端应用程序具有 Junos OS maintenance 权限，则可以通过执行 <kill-session> 作来结束保持锁定的会话。该 <session-id> 元素指定从错误消息中获取的 PID。
<rpc>
<kill-session>
<session-id>PID</session-id>
</kill-session>
</rpc>
]]>]]>
NETCONF 服务器通过返回 <ok/> 标记来确认它已终止其他会话。
<rpc-reply xmlns="URN" xmlns:junos="URL">
<ok/>
</rpc-reply>
]]>]]>
我们建议应用程序包含逻辑，用于根据持有锁的用户或应用程序的身份或空闲时间的长短等因素来确定是否适合终止另一个会话。
会话终止时，为该会话提供服务的 NETCONF 服务器将回滚在会话期间所做的所有未提交更改。如果已确认的提交处于挂起状态（更改已提交但尚未确认），则 NETCONF 服务器会将配置恢复到发出已确认提交指令之前的状态。
以下示例说明如何终止另一个会话：
结束 NETCONF 会话并关闭连接
当客户端应用程序完成发出请求后，它将通过在元素中<rpc>发出空<close-session/>标记来结束 NETCONF 会话。
<rpc>
<close-session/>
</rpc>
]]>]]>
NETCONF 服务器发出一个<rpc-reply>元素和标记。<ok/>
<rpc-reply xmlns="URN" xmlns:junos="URL">
<ok/>
</rpc-reply>
]]>]]>
由于与 NETCONF 服务器的连接是 SSH 子系统，因此当 NETCONF 会话结束时，该子系统会自动关闭。
变更历史表
是否支持某项功能取决于您使用的平台和版本。使用 功能浏览器 查看您使用的平台是否支持某项功能。
rfc-compliant 语句，NETCONF 服务器会显式声明绑定到
nc 前缀的 NETCONF 命名空间，并在其回复中使用前缀限定所有 NETCONF 标记。