<commit-configuration>

使用

描述

请求 NETCONF 或 Junos XML 协议服务器对候选配置执行提交操作的变体之一、候选配置的专用副本或临时配置数据库的开放式实例。

某些限制适用于候选配置的专用副本和临时配置数据库的提交操作。例如，如果常规候选配置被另一个用户或应用程序锁定，或者包含自创建专用副本以来进行的未提交的更改，则专用副本的提交操作将失败。此外，对临时配置数据库实例的提交操作仅支持该 <synchronize/> 选项。

将适当的标记括在标记元素中 <commit-configuration> ，以指定提交操作的类型：

• 要立即提交配置并将其作为设备上的活动配置，请发出空 <commit-configuration/> 标记。

• 要验证候选配置或专用副本的语法正确性，而不实际提交，请将 <check/> 标记括在标记元素中 <commit-configuration> 。

• 要当关联的提交操作成功时在提交历史日志中记录消息，在标记元素中 <log> 定义日志消息字符串，并将标记元素括在标记元素中 <commit-configuration> 。标记 <log> 元素可以与任何其他标记元素组合。 <log> 当单独发出标记元素时，将立即开始关联的提交操作。

• 要提交候选配置但需要显式确认提交成为永久提交，请将 <confirmed/> 标记括在标记元素中 <commit-configuration> 。

  如果未确认提交，配置在短时间后将回滚到之前的配置。默认情况下，回滚在 10 分钟后进行。要设置不同的回滚延迟，请包括 <confirm-timeout> 标记元素，并指定 1 到 65，535 分钟范围内的值。要再次延迟回滚（超过原始回滚的最后期限），请在 <confirmed/> 最后期限过去之前发出标记（包含在标记元素中 <commit-configuration> ），并可选地包含该 <confirm-timeout> 元素以指定不同于默认的延迟。回滚可以通过这种方式反复延迟。

  要发出标记后 <confirmed/> 立即永久提交配置，可在回滚截止日期过去之前发出空 <commit-configuration/> 标记或 <commit-configuration><check/><commit-configuration> 标记。设备提交候选配置并取消回滚。如果候选配置与当前提交的配置相同，则效果与重新提交当前提交的配置相同。

  注意：

  提交配置的专用副本或临时配置数据库开放实例时，确认的提交操作不可用。

• 在包含两个路由引擎的设备上，提交存储在两个路由引擎上的候选配置、专用副本或临时实例。按以下方式组合标记元素（临时数据库仅支持选项 <synchronize/> ）：

  • 要将存储在本地路由引擎上的开放式瞬时实例中的候选配置或配置数据复制到其他路由引擎，请验证配置语法正确性，并立即在两个路由引擎上提交，将 <synchronize/> 标记括在标记元素中 <commit-configuration> 。

  • 要将存储在本地路由引擎上的候选配置复制到其他路由引擎，请验证候选者的语法正确性，并在确定的未来时间提交到两个路由引擎上，将<synchronize/>或 标记和<at-time>标记元素括在标记元素中<commit-configuration><force-synchronize/>。如前所述，在标记元素中<at-time>设置值，<at-time>以便单独使用标记元素。

  • 要将存储在本地路由引擎上的候选配置复制到其他路由引擎，并验证候选者在每个路由引擎上的语法正确性，请在<synchronize/>标记元素中<commit-configuration>括起或 <force-synchronize/> 和<check/>标记元素。

  • 要将存储在本地路由引擎上的候选配置复制到其他路由引擎，请验证候选者的语法正确性，并同时提交到两个路由引擎上，但需要确认，在标记元素中括 <synchronize/> 起标记和 <confirmed/> 标记元素，并可选地 <confirm-timeout> 将标记元素括起来 <commit-configuration> 。如前所述，在标记元素中 <confirm-timeout> 设置值， <confirmed/> 以便单独使用标记和 <confirm-timeout> 标记元素。

  • 要强制标记调用 <synchronize/> 的相同同步提交操作成功（即使远程机器上有打开的配置会话或未提交的配置更改），请将 <force-synchronize/> 标记括在标记元素中 <commit-configuration> 。

• 要安排将来的提交候选配置，请将 <at-time> 标记元素括在标记元素中 <commit-configuration> 。有三种有效的时间指定符类型：

  • 字符串 reboot，用于在下次设备重新启动时提交配置。

  • 时间值，形式 hh如下：mm[：ss]（小时、分钟和可选秒），以在指定的时间提交配置，该时间必须在发出标记元素当天 <commit-configuration> 的晚上 11：59：59 之前提交配置。将 24 小时时间用于 hh 该值;例如，04：30：00 表示 4：30：00 AM，20：00 表示晚上 8：00。有关设备上的时钟和时区设置，将解释时间。

  • 格式的 yyyy日期和时间值 -mm-dd hh：mm[：ss]（年、月、日期、小时、分钟和可选秒），以在指定的日期和时间提交配置，必须在发出标记元素之后 <commit-configuration> 提交。使用 24 小时时间获取该值 hh 。例如，2005-08-21 15：30：00 表示 2005 年 8 月 21 日下午 3：30。有关设备上的时钟和时区设置，将解释时间。

    注意：

    您指定的时间必须比设备上的当前时间晚 1 分钟以上。

    将立即检查配置，以检查语法的正确性。如果检查成功，则计划在指定时间提交配置。如果检查失败，则不会安排提交操作。

内容

<at-time>	安排未来指定时间的提交操作。
<check>	请求验证配置在语法上正确，但实际未提交。
<confirmed>	请求提交候选配置，并需要明确确认提交成为永久提交。如果未确认提交，则默认在短时间后回滚到之前的配置（默认为 10 分钟）。使用 <confirm-timeout> 标记元素指定不同的时间量。
<confirm-timeout>	指定当标记包含在标记元素中时 <confirmed/> 配置保持活动状态的 <commit-configuration> 分钟数。 范围： 1 到 65，535 分钟 默认： 10 分钟
<log>	提交操作成功时，在提交历史记录日志中记录消息。
<synchronize>	在双控制平面系统上，请求将一个控制平面上的配置复制到另一个控制平面，检查语法是否正确，并在两个路由引擎上提交。
<force-synchronize>	在双控制平面系统上，强制将一个控制平面上的候选配置复制到另一个控制平面。

版本信息

这是一个 Junos XML 管理协议操作。它受 Junos XML 协议会话支持，并在运行 Junos OS 的 NETCONF 会话中作为瞻博网络的专有扩展，这些设备在功能交换中识别 URI http://xml.juniper.net/netconf/junos/1.0。