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命令的用户锁定。

如果配置中包含语法错误,将出现一条消息,指示错误的位置,并且配置未激活。错误消息具有以下格式:

例如:

在 recommitting 配置之前,您必须更正错误。要快速返回错误所在的层次结构级别,请从错误的第一行复制路径,然后将其粘贴到[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]

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

注:
  • 建议在设备上启用平滑路由引擎切换功能时路由引擎对备份执行提交操作。

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

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

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

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

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

如果您使用configure exclusive命令进入配置模式,只要您保持在配置模式下,您就会锁定候选配置,从而允许您进行更改,而不会干扰其他用户。其他用户可以进入并退出配置模式,但不能提交配置。即使其他用户在输入该configure exclusive命令之前进入了配置模式,也是如此。例如,假设用户 X 已处于configure privateconfigure模式中。然后假设用户 Y 进入configure exclusive模式。即使在用户 Y 登录之前输入了这些变更,用户 X 也无法提交对配置所做的任何更改。如果用户 Y 退出configure exclusive模式,用户 X 可以提交在configure privateconfigure模式下所做的更改。

提交准备和激活概述

从 Junos OS Release 17.3 R1 开始,您可以通过两个步骤完成提交过程。此功能允许您配置多个设备,并同时激活配置。在 Junos OS Release 17.3 R1 之前,提交流程在单个步骤中完成。将这些提交阶段分离的目的是为提交在系统上的有效提供一个明确的时间范围。您可以在提交准备后进入提交模式,但您将收到一条消息,通知提交正等待激活。

在第一步(称为准备阶段),将验证提交,并生成具有必要文件的新数据库。如果配置中包含任何语法错误,将显示相应的错误消息,并且不准备配置。在准备阶段发生故障时,将显示错误消息commit check-out failed

在第二步中,称为激活阶段,将激活以前准备的配置。接下来,如果您需要清除准备好的配置,则可以使用clear system commit prepared命令执行此操作。成功清除挂起提交时生成日志消息。

注:

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

两步提交过程优于时间关键型提交的单步流程。在单步执行过程中,根据设备上的现有配置,准备时间会有所不同。在这两步过程中,复杂准备工作的处理效率更高。

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

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

  • and-quit

  • no-synchronize

  • peers-synchronize

  • synchronize

commit preparecommit activate命令仅适用于私有、独占和共享提交。这些命令不适用于动态和暂时模式。此功能适用于多机箱设备,但不适用于批处理提交。

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

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

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

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

注:
  • 在 MX 系列中虚拟机箱安装程序以下适用:在commit prepare一个路由引擎上发出时,在切换后,发出切换命令的路由引擎重新启动。因此,已准备好的缓存在该路由引擎中被清除。

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

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

从 Junos OS 版本17.3 开始,您可以通过两个步骤完成提交过程。这使您可以配置多个设备,并且配置可以同时激活。在第一步(称为准备阶段),将验证提交,并生成新数据库以及必要的文件。如果配置中包含任何语法错误,将显示相应的错误消息,并且不准备配置。在第二步中,称为激活阶段,将激活先前准备的配置,成为当前的运营设备配置。

要准备配置:

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

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

    例如:

  2. 发出 commit prepare 命令。

    显示消息commit prepare successful

    如果准备阶段失败,将显示错误消息commit check-out failed

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

要激活预准备的配置:

  1. 使用commit activate命令

    显示消息commit complete

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

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

激活设备配置但需要确认

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

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

验证更改是否正常工作后,可通过在命令的 10 分钟内输入 或 命令来保持新配置 commitcommit checkcommit confirmed 处于活动状态。例如:

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

要显示在commit confirmed 命令后调度回滚的时间,请输入show system commit 命令。例如:

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

图 1: 确认配置确认配置

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

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

计划提交操作

您可以安排何时让候选配置生效。要在未来或重新启动时保存设备配置更改并激活路由器上的配置,请使用配置模式命令,在 [ ] 层次结构级别指定或将来 commit atrebootedit 时间:

string何处reboot或未来激活配置更改的时间。您可按两种格式指定时间:

  • 格式为 [ ] 的时间值(小时、分钟,可选秒数)—在指定的时间提交配置(必须在未来,但发布配置模式命令当日的 hh:mm:ss 11:59:59 PM 之前)。 commit at hh该值使用24小时时间;例如, 04:30:00 为 4:30:00 AM, 20:00为 8:00 PM。根据路由器上的时钟和时区设置解释该时间。

  • 格式为 [ ] 的日期和时间值(年、月、日期、小时、分钟以及可选, yyyy-mm-dd hh:mm:ss 秒数)—在指定的日期和时间提交配置,此配置必须在发出命令之后提供。 commit at hh该值使用24小时时间。例如, 2018-08-2112: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 您不能输入 configuration 命令。

为未来特定时间request system reboot计划提交操作时,您不能输入该命令。

计划的提交挂起时,您无法提交配置。有关通过命令取消计划配置的信息, clear 请参阅 CLI Explorer

注:

建议在设备上启用平滑路由引擎切换功能时路由引擎对备份执行提交操作。

监控提交流程

要监控设备配置提交进程,请使用 display detail 以下命令在管道之后 commit 使用 命令:

例如:

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

您可以包括说明已提交配置更改的注释。为此,请包含 commit comment 语句。注释的长度可为512字节,您必须将其键入一行。

comment-string 是注释的文本。

注:

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

要为commit命令添加注释,请在commentcommit命令后面包含语句:

要为commit confirmed命令添加注释,请在commentcommit confirmed命令后面包含语句:

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

注:

从 Junos OS 版本11.4 开始,您还可以使用commit confirmed[edit private]配置模式中的命令。

批处理提交概述

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

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

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

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

聚合和错误处理

如果某个聚合作业中存在加载时错误,则将丢弃遇到错误的提交作业,并聚合并提交剩余作业。

例如,如果要聚合五个提交作业(commit-1commit-2commit-3commit-4commit-5、和),并且commit-3在加载时遇到错误, commit-3则会放弃commit-1commit-2commit-4、、、并commit-5进行聚合和提交。

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

例如,如果聚合了五个提交作业(commit-1commit-2commit-3commit-4、、和commit-5),并且由于存在导致的提交错误commit-3,聚合将被丢弃、 commit-1commit-2commit-3commit-4、、、和commit-5提交,并且 CLI 会报告提交错误。 commit-3

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

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

要求

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

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

  • 在设备上运行的12.1 或更高版本 Junos OS

概述

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

配置

CLI 快速配置

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

设备 R0

配置提交服务器属性

分步过程
  1. 必配置在单个提交操作中聚合或合并的提交事务数。

    的默认值maximum-aggregate-pool5

    注:

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

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

  2. 必配置批处理中允许的最大作业数。

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

    注:

    如果设置maximum-entries1,则提交服务器不能向队列中添加多个作业,并且在您尝试提交多个作业时,CLI 将显示相应的消息。

  3. 必配置在开始下一次批处理提交操作之前要等待的时间(秒)。

  4. 必配置错误日志保留天数。

    默认值为30天。

  5. 必配置跟踪操作以记录批处理提交事件。

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

成果

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

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

分步过程

要从[edit batch]模式提交配置,请执行以下任一操作:

  • 登录设备并进入commit

  • 要将更高优先级分配给批处理提交作业,请使用commitpriority选项发出命令。

  • 要在不使用队列中的其他提交作业聚合配置更改的情况下提交配置, 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>命令。

含义

输出显示为提交作业创建的修补程序。+ Or -符号指示特定提交作业在配置中的更改。

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

用途

查看用于批处理提交操作的跟踪文件。您可以使用跟踪文件进行故障排除。

行动
  • 使用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。root 和文件系统位于路由器的闪存驱动器上,而 和 文件系统位于路由器的硬盘上( /config/altroot/altconfig 如果可用)。

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