启动 NETCONF 会话

NETCONF 服务器和客户端应用程序每一个都首先发射一个标记元素，用于指定它们从 NETCONF 规范中定义的操作 <hello> 或功能中支持的操作或功能。标记 <hello> 元素包含 <capabilities> 元素和元素，用于指定 <session-id> 会话 NETCONF 服务器的 UNIX 进程 ID （PID）。在 <capabilities> 元素中， <capability> 每个定义了一个支持的功能。

在 NETCONF 会话期间，客户端应用程序必须先发出标记元素，并且 <hello> 不能发出多次。

在 NETCONF 规范中定义的每个功能都由统一资源名称 <capability> （URN） 在元素中表示。各个供应商定义的功能由统一资源标识符 （URL） 表示，统一资源标识符 （URL） 可以是 URL 或 URL。NETCONF XML 管理协议会发出与以下示例输出类似的元素（某些元素会显示在多行上 <hello> <capability> ，但仅出于易读性）：

该元素中的 <hello> URL 表示以下支持的功能，并非详尽列表：

• urn:ietf:params:netconf:base:1.0— NETCONF 服务器支持基本 NETCONF 规范中定义的基本操作和元素。

• urn:ietf:params:netconf:capability:candidate:1.0—NETCONF 服务器支持在候选配置上操作。

• urn:ietf:params:netconf:capability:confirmed-commit:1.0—NETCONF 服务器支持已确认的提交操作。有关详细信息，请参阅 仅在使用 NETCONF 确认之后提交候选配置。

• urn:ietf:params:netconf:capability:validate:1.0—NETCONF 服务器支持验证操作，从而验证配置的语法正确性，而不实际提交。有关详细信息，请参阅 使用 NETCONF 验证候选配置语法 。

• urn:ietf:params:netconf:capability:url:1.0?protocol=http,ftp,file—NETCONF 服务器接受存储在文件中的配置数据。它可以使用超文本传输协议 （HTTP） 或 FTP（由 URN 中的 和选项指示）从本地文件系统（通过 file http ftp URN 中的选项指示）和从远程计算机检索文件。有关详细信息，请参阅 在 NETCONF 会话中上传和格式化配置数据。

• http://xml.juniper.net/netconf/junos/1.0—NETCONF 服务器支持在 Junos XML API 中定义的操作，用于请求和更改操作信息（Junos XML API 操作开发人员参考中的标记元素）。NETCONF 服务器还支持在 Junos XML 管理协议中用于请求或更改配置信息的操作。

  NETCONF 客户端应用程序应仅使用本机 NETCONF XML 管理协议操作和支持的 Junos XML 管理协议中提供的扩展，用于配置功能。对应 Junos XML 协议操作和 NETCONF XML 协议操作语义不一定相同，因此使用 Junos XML 协议配置操作（非记录支持的扩展）可能会导致意想不到的结果。

• http://xml.juniper.net/dmi/system/1.0—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> 元素：

当客户端应用程序向 NETCONF 服务器发送请求时，会话将继续。除非响应客户端应用程序的请求，否则 NETCONF 服务器在会话初始化后不会发出任何元素。

交换 <hello> 标记元素使客户端应用程序和 NETCONF 服务器能够确定是否它们支持相同的功能。此外，建议客户端应用程序确定在 NETCONF 服务器上Junos OS版本的应用程序。发出其 <hello> 标记后，客户端应用程序会发出 <get-software-information> 标记元素中的 <rpc> 标记元素：

NETCONF 服务器返回标记元素，其中包含 和 标记元素以及每个控制模块 <software-information> <host-name> <product-name> <package-information> Junos OS元素。标记元素中的标记元素指定了 Junos OS 发行号（下例中为 Junos OS 版本 8.2）和构建日期，格式为 <comment> <package-information> 8.2 YYYYMMDD（年、月、日 — 2007 年 1 月 12 日（下例）。某些标记元素显示在多行上，但仅出于易读性：

通常，设备上运行的所有Junos OS版本相同（我们建议此配置实现可预测的路由性能）。因此，仅验证一个模块的版本号通常足以满足要求。

客户端应用程序负责确定如何处理版本或功能的任何差异。为完全自动化的性能，在客户端应用程序中包括代码，用于确定它是否支持与 NETCONF 服务器Junos OS功能和版本。在存在差异时决定以下哪种选项适用，并实施相应的响应：

• 忽略功能和不同版本Junos OS，并且请勿更改客户端应用程序的行为以容纳 NETCONF 服务器。不同版本Junos OS不一定导致服务器和客户端不兼容，因此这通常是一种有效的方法。同样，如果客户端应用程序不支持的功能是始终由客户端启动的操作，如验证配置和确认提交，则这是一种有效的方法。在这种情况下，客户端不会发起操作，以维护兼容性。

• 更改标准行为，以便与 NETCONF 服务器兼容。例如，如果客户端应用程序运行 Junos OS 的更高版本，则只能选择发出 NETCONF 和 Junos XML 标记元素，这些元素表示 NETCONF 服务器版本 Junos OS 中可用的软件功能。

• 结束 NETCONF 会话并终止连接。如果您决定适应 NETCONF 服务器的版本或功能不实用，则这是合适的。有关说明，请参阅 结束 NETCONF 会话并关闭连接。