仅在使用 NETCONF 确认之后提交候选配置
在运行 Junos OS 的设备上提交候选配置时，它将变为路由、交换或安全平台上的活动配置。有关提交操作的详细信息，包括有关操作不同变体之间交互的讨论，请参阅 CLI 用户指南
提交候选配置时，需要明确确认提交将变得永久。确认的提交操作有助于验证配置更改是否正常工作，并且不会阻止对设备的管理访问。如果更改阻止访问或导致其他错误，自动回滚到上一配置将恢复访问权限，而回滚最后期限通过后。如果提交未在指定的时间范围内确认（默认为 600 秒（10 分钟），设备将自动加载并提交（回滚至）先前提交的配置。
在 NETCONF 会话中，与运行 Junos OS 的设备一起提交候选配置，但需要明确确认提交成为永久性，客户端应用程序将空标记括在 和 标记 <confirmed/> <commit> <rpc> 元素中。
<rpc> <commit> <confirmed/> </commit> </rpc> ]]>]]>
要指定与默认值 600 秒不同的回滚最后期限的秒数，应用程序包含标记元素，并指定延迟的秒数，范围为 1 到 <confirm-timeout> 4，294，967，295 秒。
<rpc> <commit> <confirmed/> <confirm-timeout>rollback-delay</confirm-timeout> </commit> </rpc> ]]>]]>
对于临时配置数据库的实例，您无法执行确认的提交操作。
无论哪种情况，NETCONF 服务器都通过返回 中的标记确认其已临时提交候选 <ok/> 配置 <rpc-reply> 。
<rpc-reply xmlns="URN" xmlns:junos="URL"> <ok/> </rpc-reply> ]]>]]>
如果 NETCONF 服务器无法提交候选配置，该元素将包含一个解释故障 <rpc-reply> <rpc-error> 原因的元素。最常见的原因为候选配置中的语义或语法错误。
为了将回滚延迟至比当前回滚最后期限更晚的时间，客户端应用程序在最后期限之前再次发出标记 <confirmed/> <commit> 元素中的标记。或者，它还包含该元素以指定延迟下一次回滚的时间;省略该标记元素以默认 <confirm-timeout> 600 秒（10 分钟）来延迟回滚。通过使用此方式反复发送标记，客户端应用程序可以一直延迟 <confirmed/> 回滚。
要永久提交配置，客户端应用程序在回滚最后期限之前发出标记 <commit/> <rpc> 元素中随附的标签。回滚将取消，并且会立即提交候选配置，如 使用 NETCONF提交候选配置 中所述。如果候选配置仍与临时提交的配置相同，这将有效地重新提交临时提交的配置。
如果另一个应用程序使用标记元素终止应用程序的会话，而确认的提交正在挂起（此应用程序已提交更改，但尚未确认），则提供此会话的 NETCONF 服务器将在发出确认的提交指令之前将配置恢复为其 <kill-session/> 状态。有关会话终止的信息，请参阅 终止 NETCONF 会话。
以下示例显示如何提交报考者配置，最后期限为 300 秒。
客户端应用程序
<rpc>
<commit>
<confirmed/>
<confirm-timeout>300</confirm-timeout>
</commit>
</rpc>
]]>]]>
NETCONF 服务器
<rpc-reply xmlns="URN" xmlns:junos="URL"> <ok/> </rpc-reply> ]]>]]>