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 个用户处于配置模式，同时对配置进行更改。所有用户所做的所有更改对编辑配置的所有人员都是可见的 — 只要用户在更改配置的命令（如setedit、或delete）的命令结束时按 Enter 键，这些更改就会变为可见。

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

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

如果使用命令进入配置模式 configure exclusive ，则只要您保持配置模式，即可锁定候选配置。这样，您可以在不受其他用户干扰的情况下进行更改。其他用户可以进入和退出配置模式，但无法提交配置。即使其他用户在输入命令之前 configure exclusive 进入配置模式，情况也是如此。例如，假设用户 X 已处于 configure private 或 configure 模式。然后假设用户 Y 进入该 configure exclusive 模式。即使用户 X 在用户 Y 登录之前输入了这些更改，用户 X 也无法对配置提交任何更改。如果用户 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 prepare和 commit activate 命令仅适用于私有、排他和共享提交。命令不适用于动态和瞬时模式。此功能适用于多机箱设备，但不适用于批量提交。

为了使用网络配置协议 （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 分钟内commit confirmed输入或commit check命令，commit以保持新配置处于活动状态。例如：

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

要显示命令后 commit confirmed 计划回滚的时间，请输入 show system commit 命令。例如：

与命令类似 commit ， commit confirmed 命令会验证配置语法并报告任何错误。如果没有错误，则配置将临时激活 （默认为 10 分钟），并开始在设备上运行。

图 1： 确认配置 确认配置

要更改之前必须确认新配置的时间量，请指定发出命令时的分钟数：

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

安排提交操作

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

string 是 reboot 或将来激活配置更改的时间。您可以以两种格式指定时间：

  • 以 [:ss] 的形式呈现hh:mm的时间值（小时、分钟和可选秒）— 在指定的时间提交配置，该时间必须在将来发出配置模式命令当天commit at 的 11：59：59 PM 之前提交。将 24 小时时间用于 hh 该值;例如， 04:30:00 为 4：30：00 AM 和 20:00 8：00 PM。时间解释为路由器上的时钟和时区设置。

  • 以 [:ss] 的形式yyyy-mm-dd hh:mm呈现的日期和时间值（年、月、日期、小时、分钟和可选秒）— 在指定的日期和时间提交配置，必须在发出命令之后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 浏览器。

注：

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

监控提交过程

要监控设备配置提交过程，在 display detail 管道后面使用命令，并使用以下 commit 命令：

例如：

添加注释以描述提交的配置

您可以添加一个备注，说明对提交的配置所做的更改。为此，请包含语句 commit comment 。注释长度可高达 512 字节，您必须在单行中键入。

comment-string 是备注的文本。

注：

不能在命令中包含注释 commit check 。

要向 commit 命令添加注释，请将 comment 语句包含在命令后面 commit ：

要向 commit confirmed 命令添加注释，请将 comment 语句包含在命令后面 commit confirmed ：

要查看这些提交注释，请发出 show system commit 操作模式命令。

注：

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

批次提交概述

批量提交聚合或合并不同 CLI 会话或用户的多个配置编辑，并将它们添加到批提交队列中。在设备上运行的批提交服务器从批提交队列中获取一个或多个作业，将配置更改应用于共享配置数据库，然后在单个提交操作中提交配置更改。

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

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

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

聚合和错误处理

其中一个聚合作业出现加载时错误时，遇到错误的提交作业将被丢弃，其余作业将被聚合并提交。

例如，如果有五个提交作业（commit-1、、commit-4commit-3commit-2、和commit-5）正在聚合，并在commit-3加载时遇到错误，commit-3则将被丢弃， 和 commit-1， commit-2commit-4并commit-5已聚合并提交。

如果聚合并提交两个或更多作业的提交操作期间出错，聚合将被丢弃，并且每个作业都像常规提交操作一样单独提交。

例如，如果有五个提交作业（commit-1、、commit-2commit-4commit-3、和commit-5）正在聚合，如果由于commit-3此而导致了提交错误，聚合将被丢弃，commit-1、 、 commit-3commit-4commit-2和commit-5分别提交，而 CLI 报告一个提交错误。commit-3

示例：配置 Batch Commit 服务器属性

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

要求

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

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

概述

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

配置

CLI 快速配置

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

设备 R0

配置提交服务器属性

逐步过程

  1. （可选）配置在单个提交操作中要聚合或合并的提交事务数。

    的默认值 maximum-aggregate-pool 为 5。

    注：

    设置 maximum-aggregate-pool 以 1 分别提交每个作业。

    在此示例中，将提交事务数设置为 4 表示在启动提交操作之前，将四个不同的提交作业聚合到一个提交中。

  2. （可选）配置一批中允许的最大作业数。

    这会限制添加到队列中的提交作业数量。

    注：

    如果设置为maximum-entries1，则提交服务器无法将多个作业添加到队列中，并且当您尝试提交多个作业时，CLI 将显示相应的消息。

  3. （可选）配置在开始下一批提交操作之前等待的时间（以秒为单位）。

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

    默认值 30 为天。

  5. （可选）配置跟踪操作以记录批提交事件。

    在此示例中，用于记录批提交事件的文件名为 commitd_nov，并且会设置所有 traceoption 标志。

结果

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

从批配置模式提交配置

逐步过程

要从该 [edit batch] 模式提交配置，请执行以下操作之一：

  • 登录设备并输入 commit。

  • 要为批提交作业分配更高的优先级，请发出 commit 带有选项的 priority 命令。

  • 要提交配置而不将配置更改与队列中的其他提交作业聚合在一起，请发出 commit 带有选项的 atomic 命令。

  • 要提交配置，而不将配置更改与队列中的其他提交作业聚合，并向提交作业发出更高的优先级，请发出带有选项的commitatomic 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根文件系统备份到/altroot和/config。/altconfig 根 /config 系统和文件系统位于路由器的闪存驱动器上 /altroot ，而文件系统和 /altconfig 文件系统位于路由器的硬盘上（如果可用）。

发出 request system snapshot 命令后，无法返回软件的早期版本，因为软件的运行副本和备份副本完全相同。

相关主题