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]

提交配置时，将以当前形式提交整个配置。

注：

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

  • 如果为管理接口或内部接口（如）和外部物理接口（如fxp0ge-0/0/1）配置相同的 IP 地址，则当启用平稳路由引擎切换 （GRES） 时，CLI 将显示相应的提交错误消息，指出在专用接口和公共接口上找到相同的地址。在这种情况下，您必须为具有重复地址的两个接口分配唯一的 IP 地址。

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

最多 32 个用户可以同时处于配置模式，对配置进行更改。所有用户所做的所有更改对编辑配置的所有人都可见 - 只要用户在更改配置的命令（如 set、 edit或 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 无法对配置提交任何更改，即使用户 X 在用户 Y 登录之前输入了这些更改也是如此。如果用户 Y 退出 configure exclusive 模式，则用户 X 可以提交在 configure private 或 configure 模式下所做的更改。

提交准备和激活概述

您可以通过两个步骤完成提交过程。两步提交功能使您能够配置多个设备并同时激活配置。两步提交为提交在系统上生效提供了明确的时间窗口。您可以在准备提交后进入提交模式，但您将收到一条消息，指出提交正在等待激活。

在第一步，即准备阶段，验证提交并生成包含必要文件的新数据库。如果配置包含任何语法错误，则会显示相应的错误消息，并且不会准备配置。如果在准备阶段出现故障，将显示错误消息 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 detailshow system commit输出，请发出以下命令。

通过确认激活设备配置

提交当前候选配置时，可以要求显式确认才能使提交成为永久性的。如果要验证配置更改是否正常工作并且不会阻止对设备的访问，这将非常有用。如果更改阻止访问或导致其他错误，设备会自动返回到之前的配置，并在回滚确认超时过后恢复访问。此功能称为自动回滚。

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

验证更改正确工作后，可以通过在命令发出后的 commit confirmed 10 分钟内输入commit或commit check命令来保持新配置处于活动状态。例如：

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

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

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

图 1： 确认配置确认配置

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

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

计划提交操作

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

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

  • 格式为 [:ss]（小时、分钟和可选的秒）的时间hh:mm值 - 在指定时间提交配置，该时间必须在将来提交，但在发出配置模式命令之日commit at 晚上 11：59：59 之前。对值使用 hh 24 小时制;例如， 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 资源管理器。

注：

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

监控提交过程

若要监视设备配置提交过程，请在管道commit后使用display detail命令和命令：

例如：

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

您可以添加描述对已提交配置的更改的注释。为此，请包含语句 commit comment 。注释可以长达 512 个字节，您必须在一行中键入它。

comment-string 是注释的文本。

注：

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

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

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

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

注：

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

从 Junos OS 24.2R1 版开始，Junos OS 强制您为每个提交请求发出注释。这有助于跟踪多个用户或管理员在提交时所做的更改。

注：

commit 如果没有参数，命令 comment 就不会执行。

若要强制用户为每个提交请求添加注释，请在层次结构级别配置force-commit-log[edit system commit]选项。

批量提交概述

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

提交服务器根据用户指定的批处理的优先级或添加批处理作业的时间，对批处理设置优先级。完成一次批处理提交后，下一组配置更改将聚合并加载到批处理队列中，以供批处理提交操作的下一个会话使用。创建批处理，直到队列目录中没有剩余的提交条目。

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

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

聚合和错误处理

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

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

如果在聚合和提交两个或多个作业时提交操作期间出现错误，则会丢弃聚合，并且其中每个作业都会像常规提交操作一样单独提交。

例如，如果有五个提交作业（commit-1、commit-2、commit-3commit-4、 和 commit-5）被聚合，并且由于 导致commit-3提交错误，则聚合将被丢弃、commit-1、 commit-4commit-3commit-2并commit-5单独提交，并且 CLI 会报告 的commit-3提交错误。

示例：配置批处理提交服务器属性

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

要求

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

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

概述

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

配置

CLI 快速配置

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

设备 R0

配置提交服务器属性

分步过程

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

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

    注：

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

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

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

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

    注：

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

  3. （可选）配置在启动下一个批处理提交操作之前要等待的时间（以秒为单位）。

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

    默认值为 30 天。

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

    在此示例中，记录批处理提交事件的文件名为 commitd_nov，并设置了所有 traceoption 标志。

结果

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

从批处理配置模式提交配置

分步过程

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

  • 登录到设备并输入 commit.

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

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

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

发出 request system snapshot 命令后，您无法返回到以前版本的软件，因为该软件的运行副本和备份副本是相同的。

相关主题