Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

提交配置

配置 commit 模式命令允许您将设备配置更改保存到配置数据库,并激活设备上的配置。

配置的提交模型

设备配置使用提交模型保存 — 候选配置将根据需要修改,然后提交到系统。提交配置时,设备会检查配置以发现语法错误,如果未发现错误,配置将作为保存 juniper.conf.gz 并激活。以前的活动配置文件保存为第一个回滚配置文件 (juniper.conf.1.gz),其他任何回滚配置文件都增量为 1。例如, juniper.conf.1.gz 增量为 juniper.conf.2.gz,使其成为第二个回滚配置文件。设备可在系统上保存最多 49 个回滚配置(编号为 1 到 49)。

在设备上,当前配置文件和前三个回滚文件 (juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3) 位于目录中 /config 。(其余回滚文件,4 至 49,位于 /var/db/config。)

如果存在恢复配置文件 rescue.conf.gz ,此文件也位于目录中 /config 。出厂默认文件位于目录中 /etc/config

有两种机制用于在设备中的路由引擎之间传播配置:

  • 同步:将配置从一个路由引擎传播到同一设备机箱内的第二个路由引擎。

    要同步配置,请使用 commit synchronize CLI 命令。如果其中一个路由引擎锁定,同步将失败。如果由于配置文件锁定而同步失败,则可以使用 命令 commit synchronize force 。此命令覆盖锁定并同步配置文件。

  • 分布:在多机箱设备上的路由平面上传播配置。自动分配。没有可用的用户命令来控制分配过程。如果配置在配置分配期间锁定,则锁定配置不会接收分布式配置文件,因此同步失败。您需要在配置之前清除锁定并重新同步路由平面。

    注:

    在多机箱平台上使用 commit synchronize force CLI 命令时,强制同步配置文件不会影响配置文件在路由平面上的分配。如果配置文件锁定在来自发布命令的设备远程的设备上,则远程设备上的同步失败。您需要清除锁定并重新发出 synchronization 命令。

提交设备配置

要将设备配置更改保存到配置数据库中并激活设备上的配置,请使用 commit 配置模式命令。您可以从任何层次结构级别发出 commit 命令:

输入 commit 命令时,将首先检查配置是否存在语法错误 (commit check)。然后,如果语法正确,配置将被激活,并成为当前的操作设备配置。

注:

当路由器上启用平滑路由引擎切换时,我们不建议在备份路由引擎上执行提交操作。

出于以下任何原因,配置提交可能失败:

  • 配置中包含错误的语法,导致提交检查失败。

  • 您尝试提交的候选配置大于 700 MB。

  • 该配置被输入 configure exclusive 命令的用户锁定。

如果配置包含语法错误,则消息将指示错误的位置,并且配置未激活。错误消息的格式如下:

例如:

重新开始配置之前,您必须纠正错误。要快速返回到错误所在的层次结构级别,请从错误的第一行复制路径,然后将其粘贴在层次结构级别的 [edit] 配置模式提示符中。

未提交的候选配置文件为 /var/rundb/juniper.db。它限于 700 MB。如果提交在消息 configuration database size limit exceeded出现故障时,请输入 命令 run file list /var/rundb detail,从配置模式查看文件大小。您可以使用通配符创建配置组或在防火墙过滤器中定义不太具体的匹配策略,从而简化配置并缩小文件大小。

注:

层级配置更改显示的 [edit interfaces] CLI 提交时间警告将被删除,并作为系统日志消息记录。

这也适用于以下层次结构级别的 VRRP 配置:

  • [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

提交配置时,请以当前格式提交整个配置。

注:
  • 当设备上启用 平滑路由引擎切换 时,我们不建议在备份路由引擎上执行提交操作。

  • 如果为管理接口或内部接口(如 fxp0 外部物理接口)配置相同的 IP 地址,例如 ge-0/0/1,启用平滑路由引擎切换 (GRES) 时,CLI 会显示适当的提交错误消息,即在私有接口和公共接口上已找到相同的地址。在这种情况下,您必须为具有重复地址的两个接口分配唯一 IP 地址。

当多个用户配置软件时提交操作

最多可以有 32 个用户处于配置模式,同时对配置进行更改。所有用户所做的所有更改都对编辑配置的每个人都可见 — 一旦用户在命令末尾按 Enter 键更改配置(如 setedit, 或 delete) 时,这些更改就会变得可见。

当任何编辑配置的用户发出 commit 命令时,CLI 会检查所有用户并激活所有更改。

如果使用 命令进入配置模式 configure private ,则每个用户都有一个专用候选配置来独立于其他用户进行编辑。提交配置时,CLI 仅提交自己的更改。要在其他用户提交更改后同步配置副本,您可以在配置模式下运行 update 命令。提交操作还会更新所有专用候选配置。例如,假设用户 X 和用户 Y 均处于 configure private 模式,而用户 X 提交配置更改。当用户 Y 执行后续提交操作,然后查看新配置时,用户 Y 看到的新配置包括用户 X 执行的更改。

如果使用 命令进入配置模式 configure exclusive ,请在保持配置模式时锁定候选配置。这样您就可以在不受到其他用户干扰的情况下进行更改。其他用户可以进入和退出配置模式,但无法提交配置。即使其他用户在输入 configure exclusive 命令之前进入配置模式,这一点也是如此。例如,假设用户 X 已处于 configure privateconfigure 模式。假设用户 Y 进入模式 configure exclusive 。用户 X 无法对配置提交任何更改,即使用户 X 在用户 Y 登录之前输入了这些更改。如果用户 Y 退出configure exclusive模式,则用户 X 可提交在或configure模式下configure private执行的更改。

提交准备和激活概述

您可以分两步完成提交流程。通过两步提交功能,您可以配置多个设备并同时激活配置。两步提交提供了确定提交在系统上有效的时间窗口。您可在提交准备完成后进入提交模式,但您将收到一条消息,表示提交正在等待激活。

在第一步准备阶段,提交将经过验证,并生成具有必要文件的新数据库。如果配置包含任何语法错误,将显示适当的错误消息,并且未准备配置。如果在准备阶段出现故障,将显示错误消息 commit check-out failed

在第二步的激活阶段,先前准备的配置将激活。接下来,如果您需要清除已准备的配置,则可以使用 clear system commit prepared 命令来完成此操作。成功清除待决提交时,将生成日志消息。

注:

您不能在准备和激活阶段之间执行提交操作。

双步提交流程优于时间关键型提交的单步流程。在单步流程中,准备时间可能因设备上的现有配置而异。在两步式流程中,更有效地处理复杂的准备工作。

提供配置命令,允许您准备配置缓存并激活配置。您可以使用新配置来准备设备,并按所需的确切时间将其激活。

命令 commit prepare 验证配置,命令 commit activate 激活配置。这些命令具有以下配置选项:

  • and-quit

  • no-synchronize

  • peers-synchronize

  • synchronize

commit activatecommit prepare命令仅适用于私有、独家和共享提交。这些命令不适用于动态和临时模式。此功能适用于多机箱设备,但不适用于批量提交。

为了使用网络配置协议 (NETCONF) 支持此功能,提供以下新的远程过程调用 (RPC):

  • <commit-configuration>< prepare/></commit-configuration>

  • <commit-configuration><activate/></commit-configuration>

  • <clear-system-commit><prepared/></clear-system-commit>

注:
  • 在 MX 系列虚拟机箱设置中,以下应用:当 commit prepare 在一个路由引擎上发布,然后切换时,将重新启动发出切换命令的路由引擎。因此,准备的缓存在该路由引擎中清除。

  • 在 MX 系列虚拟机箱设置中,建议仅在 VC 主设备上执行 clear system commit prepared 命令。

分两步提交设备配置:准备和激活

您可以分两步完成提交流程。这使您能够配置多个设备,并且配置可以同时激活。在第一步(称为准备阶段)中,提交将经过验证,并且会生成新的数据库以及必要的文件。如果配置包含任何语法错误,将显示适当的错误消息,并且未准备配置。在第二步(称为激活阶段)中,先前准备的配置将被激活,并成为当前的操作设备配置。

要准备配置:

  1. 在配置模式的 [edit] 层次结构级别上,对配置进行必要的更改。

    例如,要配置系统的脚本,请发出以下命令:

    例如:

  2. commit prepare发出 命令。

    commit prepare successful消息将显示。

    如果准备阶段发生故障,将显示错误消息 commit check-out failed

  3. 要在发出命令后commit prepare验证命令的show system commit输出,请使用以下命令:

要激活已准备的配置:

  1. commit activate使用 命令

    commit complete消息将显示。

  2. 要验证激活系统配置,请使用以下命令:

要在发出后commit activate验证和show system commit revision detail命令的show system commit输出,请发出以下命令。

激活设备配置并确认

提交当前候选配置时,可能需要显式确认才能使提交永久化。如果您要验证配置更改是否正确且不妨碍对设备的访问,这很有用。如果更改阻止访问或导致其他错误,设备将自动返回到之前的配置,并在回滚确认超时通过后恢复访问。此功能称为自动回滚。

要提交当前候选配置,但提交成为永久提交需要显式确认,请使用 commit confirmed 配置模式命令:

验证更改是否正确运行后,可在命令发出或命令后 10 分钟内输入 commitcommit check 命令,从而保持新配置处于活动状态 commit confirmed 。例如:

如果提交未在一定时间内(默认 10 分钟)内得到确认,操作系统将自动回滚到之前的配置,并将广播消息发送至所有登录用户。

要在命令后 commit confirmed 安排回滚,请输入 show system commit 命令。例如:

与 命令一 commit 样, commit confirmed 命令将验证配置语法并报告任何错误。如果没有错误,配置将暂时激活 (默认 10 分钟),并开始在设备上运行。

图 1: 确认配置 确认配置

要在确认新配置之前更改时间量,请指定发出 命令时的分钟数:

您也可在配置模式下[edit private]使用 commit confirmed 命令。

计划提交操作

当您希望候选配置变得活跃时,您可以安排时间。要在未来时间或重新启动时保存设备配置更改并激活设备上的配置,请使用commit at配置模式命令,在 [edit] 层次结构级别指定reboot或将来时间:

stringreboot 或未来激活配置更改的时间。您可以以两种格式指定时间:

  • 形式 hh:mm中的一个时间值 [:ss](小时、分钟和可选秒数)— 在指定时间提交配置(必须是将来,但在发出配置模式命令的当天 commit at 晚上 11:59:59 之前)。使用 24 小时实现 hh 该值;例如, 04:30:00 为凌晨 4:30:00, 20:00 为晚上 8:00。该时间将解释为路由器上的时钟和时区设置。

  • 表格 yyyy-mm-dd hh:mm中的日期和时间值(:ss年、月、日期、小时、分钟,还有可选的秒数)— 在指定的日期和时间提交配置,必须在发布命令之后 commit at 。使用 24 小时实现该 hh 值。例如, 2018-08-21 12:30:00 2018 年 8 月 21 日下午 12:30。该时间将解释为路由器上的时钟和时区设置。

将报价标记 (“ ”) 中的值括起来 string 。例如。 commit at "18:00:00" 日期和时间,在同一组引号中包括两个值。例如 commit at "2018-03-10 14:00:00".

发出 commit at 配置模式命令时,将立即执行提交检查。如果检查结果成功,则表示当前用户已注销配置模式,配置数据将保留在只读状态。在完成计划提交之前,不得执行其他提交。

注:

如果设备软件在配置更改处于活动状态之前出现故障,则所有配置更改将丢失。

发出 request system reboot 命令后,commit at 您无法输入配置命令。

在未来的特定时间安排提交操作后,您无法输入 request system reboot 命令。

当计划提交正在等待时,您无法提交配置。有关如何通过 clear 命令取消计划配置的信息,请参阅 CLI Explorer

注:

当设备上启用平滑路由引擎切换时,我们不建议在备份路由引擎上执行提交操作。

监控提交流程

要监控设备配置提交流程,请使用 display detail 管道后的命令和 commit 命令:

例如:

添加评论以描述已提交配置

您可以提供一条评论,其中介绍了对已提交配置的更改。为此,请包括语 commit comment 句。评论可以长达 512 字节,您必须在单行中键入。

comment-string 是评论文本。

注:

您无法在 命令中 commit check 包含评论。

要在 命令中commit添加评论,请在命令后commit加入comment语句:

要在 命令中commit confirmed添加评论,请在命令后commit confirmed加入comment语句:

要查看这些提交评论,请发出 show system commit 操作模式命令。

注:

您也可在配置模式下[edit private]使用 commit confirmed 命令。

批次提交概述

批量提交聚合或合并来自不同 CLI 会话或用户的多个配置编辑,并将其添加到批次提交队列中。在设备上运行的批次提交服务器从批次提交队列中接受一个或多个工作,将配置更改应用到共享配置数据库,然后在单个提交操作中提交配置更改。

提交服务器将根据用户指定的批次的优先级或添加批次作业的时间确定批次优先级。完成一批提交后,将聚合下一组配置更改并加载到批量队列中,以备下一批提交操作。在队列目录中未保留提交条目之前,将创建批次。

与按顺序独立提交所有提交的常规提交操作相比,批次提交可通过在单个提交操作中提交多个小型配置编辑来节省时间和系统资源。

批量提交从 [edit batch] 配置模式执行。提交服务器属性可在 [edit system commit server] 层次结构级别配置。

聚合和错误处理

当其中一个聚合工作出现负载时间错误时,将丢弃遇到错误的提交工作,并将其余工作聚合并提交。

例如,如果聚合commit-3了五个提交工作(commit-1commit-2commit-3commit-4commit-5)并在加载时遇到错误,commit-3则被丢弃和 commit-1commit-2commit-4、 和commit-5聚合和提交。

如果在提交操作中聚合和提交两个或更多工作时出现错误,则聚合将被丢弃,并且每个工作都像定期提交操作一样单独提交。

例如,如果聚合了五个提交工作(、、 commit-4和);如果由于commit-3导致提交错误,聚合将被丢弃、 commit-1commit-2commit-4commit-3commit-5单独提交,而 CLI 报告提交错误。commit-3commit-5commit-3commit-2commit-1

示例:配置批量提交服务器属性

此示例说明如何配置批量提交服务器属性以管理批次提交操作。

要求

此示例使用以下硬件和软件组件:

  • MX 系列 5G 通用路由平台

概述

通过在 [edit system commit server] 层次结构级别配置服务器属性,您可以控制提交服务器如何处理该批提交队列。这使您能够控制将多少提交工作聚合或合并到单个批次提交中、可添加到队列中的最大工作数、保留批次提交错误日志的日志、两批提交之间的间隔,以及跟踪批量提交操作的操作。

配置

CLI 快速配置

要快速配置示例的此部分,请复制以下命令,将其粘贴到文本文件中,移除任何换行符,更改与网络配置匹配所需的任何详细信息,然后将命令复制粘贴到层次结构级别的 [edit] CLI 中。您可以从常规 [edit] 模式或 [edit batch] 模式配置提交服务器属性。

设备 R0

配置提交服务器属性

逐步过程
  1. (可选)配置提交交易数量以在单个提交操作中聚合或合并。

    的默认值是 maximum-aggregate-pool5

    注:

    设置 maximum-aggregate-pool1 单独提交每个工作。

    在此示例中,提交交易的数量设置为 4 表示在发起提交操作之前,将四个不同的提交工作聚合到单个提交中。

  2. (可选)配置一批允许的最大工作数。

    这限制了加入队列的提交工作的数量。

    注:

    如果设置 maximum-entries1,提交服务器不能在队列中添加多个工作,而 CLI 在尝试提交多个工作时会显示适当的消息。

  3. (可选)配置时间(以秒为单位)以等待,然后开始下一批提交操作。

  4. (可选)配置保留错误日志的天数。

    默认值为 30 天。

  5. (可选)配置跟踪操作以记录批量提交事件。

    在此示例中,记录批量提交事件的文件名为 commitd_nov,并且会设置所有追踪标记。

结果

在配置模式下,输入 show system commit server 命令以确认您的配置。如果输出未显示预期的配置,请重复此示例中的说明以更正配置。

从批量配置模式提交配置

逐步过程

要在模式下 [edit batch] 提交配置,请执行以下某个操作:

  • 登录设备并输入 commit

  • 要将更高优先级分配给批次提交工作,请使用 选项发出 commit 命令 priority

  • 要在不将配置更改聚合到队列中的其他提交工作的情况下提交配置,请使用 选项发出 commit 命令 atomic

  • 要提交配置,而无需将配置更改与队列中的其他提交工作聚合,并且对提交工作发出更高优先级,请使用 选项发出 commit 命令 atomic priority

验证

确认配置工作正常。

检查批次提交服务器状态

目的

检查批提交服务器的状态。

行动

默认情况下,提交服务器的状态为 Not running。仅当将一批提交工作添加到队列中时,提交服务器才会开始运行。

将一批提交工作添加到队列中时,提交服务器的状态将更改为 Running

意义

Jobs in process 字段列出了正在从事的工作提交 ID。

检查批次提交状态

目的

检查提交服务器队列以了解批次提交的状态。

行动
意义

Pending commits 显示提交工作,这些工作已添加到提交队列中,但尚未提交。 Completed commits 显示成功的提交工作列表。 Error commits 是因错误而出现故障的提交。

查看批次提交工作中的补丁文件

目的

查看每个提交工作的时间戳、补丁文件和状态。补丁文件显示在添加到批次提交队列的每个提交操作中发生的配置更改。

行动
  1. show system commit server queue patch使用 命令查看所有提交操作的补丁。

    输出显示每个提交工作 ID 的配置更改。

  2. 要查看特定提交工作 ID 的补丁,请发出 show system commit server queue patch id <id-number> 命令。

意义

输出显示为提交工作创建的补丁。或+-签名表示特定提交工作配置的更改。

查看跟踪文件以执行批量提交操作

目的

查看跟踪文件以执行批量提交操作。您可以使用追踪文件进行故障排除。

行动
  • 使用 命令 file show /var/log/<filename> 查看日志文件中的所有条目。

    输出显示提交服务器事件日志以及批次提交的其他日志。

  • 要仅查看成功批次提交操作的日志条目,请使用管道选项发出 file show /var/log/<filename> 命令 | match committed

    输出显示批量提交工作 ID 用于成功提交操作。

  • 要仅查看故障批次提交操作的日志条目,请使用管道选项发出 file show /var/log/<filename> 命令 | match “Error while”

    输出显示提交任务 ID 用于失败的提交操作。

  • 要仅查看用于提交服务器事件的日志条目,请使用管道选项发出 file show /var/log/<filename> 命令 | match “commit server”

    输出显示提交服务器事件日志。

备回备用启动驱动器上的已提交配置

提交配置并确信配置已成功运行后,应发出 request system snapshot 命令将新软件备份到文件系统上 /altconfig 。如果不发出 request system snapshot 命令,则备用启动驱动器上的配置与主启动驱动器上的配置不同步。

命令 request system snapshot 将 root 文件系统备份到 /altroot/config/altconfig。root 和 /config 文件系统位于路由器的闪存驱动器上,并且 /altroot/altconfig 文件系统位于路由器的硬盘上(如果有)。

发出 request system snapshot 命令后,由于软件的运行副本和备份副本相同,无法返回到软件的前一个版本。