提交配置
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 synchronizeCLI 命令。如果其中一个路由引擎被锁定,则同步将会失败。如果由于配置文件锁定而导致同步失败,可以使用命令commit synchronize force。此命令将覆盖锁并同步配置文件。-
分布:在多机箱设备上的路由平面上传播配置。分发会自动进行。没有用户命令可用于控制分配过程。如果在分发配置期间锁定配置,则锁定的配置不会接收分发的配置文件,因此同步将会失败。您需要在配置之前清除锁定并重新同步路由平面。
注意:在多机箱平台上使用
commit synchronize forceCLI 命令时,配置文件的强制同步不会影响配置文件在路由平面上的分布。如果远离发出命令的设备上的配置文件被锁定,则远程设备上的同步将失败。您需要清除锁并重新发出synchronization命令。注意:Junos OS 演化版不支持以下
commit配置选项:-
fast-synchronize -
peers -
peer-synchronize -
commit-synchronize-server
-
提交设备配置
要将设备配置更改保存到配置数据库并激活设备上的配置,请使用 commit 配置模式命令。您可以从任何层级发出命令 commit :
[edit]
user@host# commit
commit complete
[edit]
user@host#
输入命令 commit 时,将首先检查配置是否存在语法错误 (commit check)。然后,如果语法正确,则会激活配置并成为当前的可作设备配置。
当路由器上启用了平滑路由引擎切换时,不建议在备份路由引擎上执行提交作。
配置提交可能会因以下任何原因而失败:
-
配置包含不正确的语法,这会导致提交检查失败。
-
您尝试提交的候选配置大于 700 MB。
-
配置被输入
configure exclusive命令的用户锁定。
如果配置包含语法错误,则会出现一条消息,指示错误的位置,并且配置不会被激活。错误消息的格式如下:
[editedit-path] ‘offending-statement;’error-message
例如:
[edit firewall filter login-allowed term allowed from] ‘icmp-type [ echo-request echo-reply ];’ keyword ‘echo-reply’ unrecognized
必须先更正错误,然后才能重新提交配置。要快速返回到错误所在的层级,请从错误的第一行复制路径,并将其粘贴到层级的 [edit] 配置模式提示符处。
未提交的候选配置文件是 /var/rundb/juniper.db。默认情况下,文件的大小限制为配置数据库的默认最大大小。您可以通过发出 show system configuration database usage 命令来验证磁盘上的数据库大小和最大数据库大小。您还可以通过发出 run file list /var/rundb detail 命令从配置模式查看文件的大小。如果候选配置超过最大数据库大小,则提交失败,并显示消息 configuration database size limit exceeded。要解决此错误,您可以:
-
通过在支持此语句的设备上在层次结构级别配置
[edit system configuration-database]该extend-size语句,增加配置数据库的最大大小。您必须重新启动设备才能使更改生效。 -
通过使用通配符创建配置组或在防火墙过滤器中定义不太具体的匹配策略,简化配置并减小文件大小。
提交配置并在必要时重新启动后,可以通过发出 show system configuration database usage 命令来验证对磁盘上的数据库大小或最大数据库大小的任何更新。
在层次结构级别上 [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]
提交配置时,将以当前形式提交整个配置。
-
当设备上启用 了平滑路由引擎切换 时,我们不建议在备份路由引擎上执行提交作。
-
如果为管理接口或内部接口(例如)和外部物理接口(如
re0:mgmt-0xe-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 or 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>
通过两个步骤提交设备配置:准备和激活
可以通过两个步骤完成提交过程。这样您就可以配置多个设备,并且可以同时激活这些配置。在第一步(称为准备阶段)中,验证提交并生成新数据库以及必要的文件。如果配置包含任何语法错误,将显示相应的错误消息,并且不会准备好配置。在第二步(称为激活阶段)中,先前准备好的配置将被激活,并成为当前可作的设备配置。
要准备配置,请执行以下作:
要激活准备好的配置:
使用命令
commit activate[edit] user@host#
commit activate将显示该消息
commit complete。要验证激活的系统配置,请使用以下命令:
user@host>
show configuration system scriptslanguage python;
要在发出后commit activate验证 和 show system commit show system commit revision detail 命令的输出,请发出以下命令。
user@host> show system commit
0 2018-07-12 22:54:46 PDT by user via cli commit activate
user@host> show system commit revision detail
Revision: re0-1499925285-2214
User : user
Client : cli
Time : 2018-07-12 22:54:46 PDT
Comment : commit activate
激活设备配置并确认
提交当前候选配置时,可能需要明确确认才能使提交永久生效。如果要验证配置更改是否正常工作并且不会阻止对设备的访问,这将很有用。如果更改阻止访问或导致其他错误,设备会自动返回到之前的配置,并在回滚确认超时过后恢复访问。此功能称为自动回滚。
要提交当前候选配置,但需要明确确认才能使提交永久生效,请使用 commit confirmed 配置模式命令:
[edit]
user@host# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
#commit confirmed will be rolled back in 10 minutes
[edit]
user@host#
在验证更改是否正常工作后,您可以在命令commit confirmed发布后的 10 分钟内输入 commit or commit check 命令,使新配置保持活动状态。例如:
[edit]
user@host# commit check
configuration check succeeds
如果在一定时间内(默认为 10 分钟)未确认提交,则作系统会自动回滚到之前的配置,并向所有登录的用户发送广播消息。
要显示何时在命令之后 commit confirmed 计划回滚,请输入命令 show system commit 。例如:
user@host>show system commit
0 2018-01-05 15:00:37 PST by root via cli commit confirmed, rollback in 3mins
与命令类似 commit ,该 commit confirmed 命令会验证配置语法并报告任何错误。如果没有错误,配置将暂时激活(默认为 10 分钟)并开始在设备上运行。
要更改必须确认新配置之前的时间量,请指定发出命令时的分钟数:
[edit]
user@host# commit confirmed minutes
commit complete
[edit]
user@host#
您也可以在[edit private]配置模式下使用该commit confirmed命令。
安排提交作
您可以安排候选配置何时激活。要保存设备配置更改并在将来或重新启动时激活设备上的配置,请使用commit at配置模式命令,在 [edit] 层次结构级别指定 reboot 或 将来时间:
[edit]
user@host # commit at string
string 是 reboot 或将来激活配置更改的时间。可以指定两种格式的时间:
形式为
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-2112:30:00是 2018 年 8 月 21 日中午 12:30。时间是根据路由器上的时钟和时区设置来解释的。
用引号 (“ ”) 将值括起来string。例如,commit at 8:00:00"1"。对于日期和时间,请在同一组引号中包含这两个值。例如,commit at "2018-03-10 14:00:00".
发出配置模式命令时 commit at ,将立即执行提交检查。如果检查结果成功,则当前用户将退出配置模式,并且配置数据将保持只读状态。在计划提交完成之前,不能执行其他提交。
如果设备软件在配置更改变为活动状态之前发生故障,则所有配置更改都将丢失。
发出request system reboot命令后,无法输入commit at 配置命令。
在将来的特定时间安排提交作后,将无法输入命令 request system reboot 。
当计划提交处于挂起状态时,无法提交配置。有关如何使用命令取消计划配置 clear 的信息,请参阅 CLI 资源管理器。
当设备上启用了平滑路由引擎切换时,我们不建议在备份路由引擎上执行提交作。
监控提交过程
要监控设备配置提交过程,请在竖线commit后面使用以下display detail命令:
user@host# commit | display detail
例如:
[edit]
user@host# commit | display detail2021-10-08 10:33:42.619908 PDT: Obtaining lock for commit
2021-10-08 10:42:36.341266 PDT: Obtaining lock for commit
2021-10-08 10:42:36.343401 PDT: updating commit revision
2021-10-08 10:42:36.343639 PDT: UI extensions feature is not configured
2021-10-08 10:42:36.343718 PDT: UI change-notification feature is not configured
2021-10-08 10:42:36.343877 PDT: Started running translation script
2021-10-08 10:42:36.398596 PDT: No delta input for translation
2021-10-08 10:42:36.398679 PDT: Finished running translation script
2021-10-08 10:42:36.398904 PDT: start loading commit script changes
2021-10-08 10:42:36.398944 PDT: no commit script changes
2021-10-08 10:42:36.399006 PDT: no transient commit script changes
2021-10-08 10:42:36.399046 PDT: finished loading commit script changes
2021-10-08 10:42:36.399091 PDT: No translation output from the scripts
2021-10-08 10:42:36.400007 PDT: building groups inheritance path proportional in
candidate db
2021-10-08 10:42:36.400074 PDT: finished groups inheritance path
2021-10-08 10:42:36.400112 PDT: copying juniper.db to juniper.data+
2021-10-08 10:42:36.402278 PDT: finished copying juniper.db to juniper.data+
2021-10-08 10:42:36.402357 PDT: exporting juniper.conf
2021-10-08 10:42:36.404504 PDT: expanding interface-ranges
2021-10-08 10:42:36.404566 PDT: finished expanding interface-ranges
2021-10-08 10:42:36.404598 PDT: setup foreign files
2021-10-08 10:42:36.411776 PDT: propagating foreign files
2021-10-08 10:42:36.411824 PDT: Sending constraint check command to evaluate con
straints
2021-10-08 10:42:36.580667 PDT: constraints passed in mustd - not checking const
raints in propagation
2021-10-08 10:42:36.586908 PDT: complete foreign files
2021-10-08 10:42:36.663944 PDT: Forking child for configd-streamer operation
2021-10-08 10:42:36.666585 PDT: dropping unchanged foreign files
2021-10-08 10:42:36.666768 PDT: start ffp propagate
2021-10-08 10:42:36.855945 PDT: propagate stp-portid-ffp
2021-10-08 10:42:37.120224 PDT: propagate stp-portid-ffp done
2021-10-08 10:42:37.120447 PDT: propagate interface-alias-ffp
2021-10-08 10:42:37.464777 PDT: propagate interface-alias-ffp done
2021-10-08 10:42:37.467692 PDT: finish ffp propagate
2021-10-08 10:42:37.467826 PDT: Sending command to evaluate validation hooks
2021-10-08 10:42:37.471143 PDT: daemons checking new configuration
2021-10-08 10:42:37.761146 PDT: Collecting status of mustd hooks validation, sta
tus 0
2021-10-08 10:42:37.761273 PDT: commit wrapup...
2021-10-08 10:42:37.761519 PDT: Checking status of configd-streamer child before
ffp activate
2021-10-08 10:42:37.761562 PDT: ev.ops+ file generated successfully
2021-10-08 10:42:37.761635 PDT: start ffp activate
2021-10-08 10:42:37.938324 PDT: activate stp-portid-ffp
2021-10-08 10:42:38.181781 PDT: activate stp-portid-ffp done
2021-10-08 10:42:38.181953 PDT: activate interface-alias-ffp
2021-10-08 10:42:38.373063 PDT: activate interface-alias-ffp done
2021-10-08 10:42:38.373125 PDT: activate hostname-ffp
2021-10-08 10:42:38.731220 PDT: activate hostname-ffp done
2021-10-08 10:42:38.731575 PDT: activate configd-ffp
2021-10-08 10:42:38.904529 PDT: activate configd-ffp done
2021-10-08 10:42:38.906425 PDT: activating '/var/etc/cosd.conf'
2021-10-08 10:42:38.906598 PDT: activating '/var/etc/pam.conf'
2021-10-08 10:42:38.906716 PDT: activating '/var/etc/pam_radius.conf'
2021-10-08 10:42:38.983913 PDT: activating '/var/etc/pam_tacplus.conf'
2021-10-08 10:42:38.984100 PDT: activating '/var/etc/issue'
2021-10-08 10:42:38.984202 PDT: activating '/var/etc/certs'
2021-10-08 10:42:38.991939 PDT: activating '/var/etc/motd'
2021-10-08 10:42:38.992178 PDT: activating '/var/etc/max-db-size-cfg'
2021-10-08 10:42:38.992267 PDT: activating '/var/etc/subs-mgmt-cfg'
2021-10-08 10:42:38.992342 PDT: activating '/var/etc/nc_notification'
2021-10-08 10:42:38.992464 PDT: activating '/var/etc/ephinst.conf'
2021-10-08 10:42:38.992557 PDT: activating '/var/etc/config-apps.txt'
2021-10-08 10:42:38.992674 PDT: executing foreign_commands
2021-10-08 10:42:38.992722 PDT: /bin/sh /etc/rc.ui ui_setup_users (sh)
2021-10-08 10:42:39.24126 PDT: not executing commit in cli_sysctl
2021-10-08 10:42:39.24234 PDT: finish ffp activate
2021-10-08 10:42:39.24278 PDT: db_groups_info_clear start
2021-10-08 10:42:39.419569 PDT: db_groups_info_clear done
2021-10-08 10:42:39.419653 PDT: activating '/var/rundb/juniper.data'
2021-10-08 10:42:40.14698 PDT: Rotate backup configs
2021-10-08 10:42:40.142039 PDT: ssync begins
2021-10-08 10:42:40.566324 PDT: ssync ends
2021-10-08 10:42:40.566392 PDT: ssync begins
2021-10-08 10:42:40.807541 PDT: ssync ends
2021-10-08 10:42:40.807608 PDT: notifying daemons of new configuration
2021-10-08 10:42:40.807804 PDT: ssync begins
2021-10-08 10:42:40.924440 PDT: ssync ends
2021-10-08 10:42:40.924630 PDT: mgd tracing: disabled
2021-10-08 10:42:40.924684 PDT: New database revision 're0-1633714956-29' and ol
d database revision 're0-1633714422-28'
2021-10-08 10:42:40.924709 PDT: commit complete
commit complete
添加注释以描述已提交的配置
您可以添加注释,描述对已提交的配置所做的更改。为此,请包含该 commit comment 语句。注释最长可达 512 个字符,您必须在一行上键入。
[edit]
user@host# commit comment comment-string
comment-string 是注释的正文。
您不能在命令中 commit check 包含注释。
要向命令添加commit注释,请在命令后commit包含以下comment语句:
[edit]
user@host# commit comment "add user joe"
commit complete
[edit]
user@host#
要向命令添加commit confirmed注释,请在命令后commit confirmed包含以下comment语句:
[edit]
user@host# commit confirmed comment "add customer to port 27"
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
[edit]
user@host#
要查看这些提交注释,请发出 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-2、 commit-4commit-3、 commit-5和 )正在聚合commit-3,并在加载时遇到错误,commit-3则丢弃commit-1,聚合并提交 、 、 commit-2commit-4和 commit-5 。
如果在聚合和提交两个或多个作业时在提交作期间出现错误,则将丢弃聚合,并像常规提交作一样单独提交每个作业。
例如,如果聚合了五个提交作业(commit-1、 commit-4commit-3commit-2和 commit-5),并且由于 而导致commit-3提交错误,则该聚合将被丢弃、 commit-1、 commit-2、 commit-4commit-3和 commit-5 单独提交,并且 CLI 报告 的提交错误。commit-3
示例:配置批量提交服务器属性
此示例演示如何配置批量提交服务器属性来管理批量提交作。
概述
您可以通过在层次结构级别配置 [edit system commit server] 服务器属性来控制提交服务器如何处理批量提交队列。这样可以控制聚合或合并到单个批量提交中的提交作业数量、可以添加到队列中的最大作业数、保留批量提交错误日志的天数、两次批量提交之间的间隔以及批量提交作的跟踪作。
配置
CLI 快速配置
要快速配置示例的此部分,请复制以下命令,将其粘贴到文本文件中,删除所有换行符,更改任何必要的详细信息以匹配您的网络配置,然后将命令复制并粘贴到层次结构级别的 [edit] CLI 中。您可以从常规 [edit] 模式或 [edit batch] 模式配置提交服务器属性。
设备 R0
set system commit server maximum-aggregate-pool 4set system commit server maximum-entries 500set system commit server commit-interval 5set system commit server days-to-keep-error-logs 30set system commit server traceoptions file commitd_novset system commit server traceoptions flag all
配置提交服务器属性
分步程序
-
(选答)配置在单个提交作中聚合或合并的提交事务数。
的
maximum-aggregate-pool默认值为5。注意:maximum-aggregate-pool1设置为单独提交每个作业。在此示例中,提交事务数设置为
4指示在启动提交作之前将四个不同的提交作业聚合到单个提交中。[edit system commit server]user@R0#set maximum-aggregate-pool 4 -
(选答)配置批处理中允许的最大作业数。
这限制了添加到队列中的提交作业的数量。
[edit system commit server]user@R0#set maximum-entries 500注意:如果设置为
maximum-entries1,则提交服务器无法将多个作业添加到队列中,并且当您尝试提交多个作业时,CLI 会显示相应的消息。 -
(选答)配置在开始下一个批量提交作之前等待的时间(以秒为单位)。
[edit system commit server]user@R0#set commit-interval 5 -
(选答)配置保留错误日志的天数。
默认值为
30天。[edit system commit server]user@R0#set days-to-keep-error-logs 30 -
(选答)配置跟踪作以记录批量提交事件。
在此示例中,用于记录批量提交事件
commitd_nov的文件名为 ,并设置了所有 traceoption 标志。[edit system commit server]user@R0#set traceoptions commitd_novuser@R0#set traceoptions flag all
结果
在配置模式下,输入 show system commit server 命令以确认您的配置。如果输出未显示预期的配置,请重复此示例中的说明以更正配置。
user@R0# show system commit server
maximum-aggregate-pool 4;
maximum-entries 500;
commit-interval 5;
days-to-keep-error-logs 30;
traceoptions {
file commitd_nov;
flag all;
}
从批处理配置模式提交配置
分步程序
要从该 [edit batch] 模式提交配置,请执行下列作之一:
-
登录设备并输入
commit。[edit batch]user@R0#commitAdded to commit queue request-id: 1000 -
要为批处理提交作业分配更高的优先级,请发出
commit带有该选项的priority命令。[edit batch]user@R0#commit priorityAdded to commit queue request-id: 1001 -
要提交配置而不将配置更改与队列中的其他提交作业聚合,请发出
commit带有该选项的atomic命令。[edit batch]user@R0#commit atomicAdded to commit queue request-id: 1002 -
要提交配置而不将配置更改与队列中的其他提交作业聚合,并为提交作业发出更高的优先级,请发出带有
commit该选项的atomic priority命令。[edit batch]user@R0#commit atomic priorityAdded to commit queue request-id: 1003
验证
确认配置工作正常。
检查批量提交服务器状态
目的
检查批量提交服务器的状态。
行动
user@R0> show system commit server
Commit server status : Not running
默认情况下,提交服务器的状态为 Not running。只有当批量提交作业添加到队列中时,提交服务器才会开始运行。
将批处理提交作业添加到队列中时,提交服务器的状态将更改为 Running。
user@R0> show system commit server
Commit server status : Running
Jobs in process:
1003 1004 1005
意义
该 Jobs in process 字段列出正在处理的作业的提交 ID。
检查批量提交状态
目的
检查提交服务器队列以获取批量提交的状态。
行动
user@R0> show system commit server queue
Pending commits:
Id: 1005
Last Modified: Tue Nov 1 23:56:43 2018
Completed commits:
Id: 1000
Last Modified: Tue Nov 1 22:46:43 2018
Status: Successfully committed 1000
Id: 1002
Last Modified: Tue Nov 1 22:50:35 2018
Status: Successfully committed 1002
Id: 1004
Last Modified: Tue Nov 1 22:51:48 2018
Status: Successfully committed 1004
Id: 1007
Last Modified: Wed Nov 2 01:08:04 2018
Status: Successfully committed 1007
Id: 1009
Last Modified: Wed Nov 2 01:16:45 2018
Status: Successfully committed 1009
Id: 1010
Last Modified: Wed Nov 2 01:19:25 2018
Status: Successfully committed 1010
Id: 1011
Last Modified: Wed Nov 2 01:28:16 2018
Status: Successfully committed 1011
Error commits:
Id: 1008
Last Modified: Wed Nov 2 01:08:18 2018
Status: Error while commiting 1008
意义
Pending commits 显示已添加到提交队列但尚未提交的提交作业。 Completed commits 显示成功的提交作业列表。 Error commits 是由于错误而失败的提交。
查看批量提交作业中的补丁文件
目的
查看每个提交作业的时间戳、补丁文件和状态。修补程序文件显示添加到批处理提交队列的每个提交作中发生的配置更改。
行动
-
使用该
show system commit server queue patch命令查看所有提交作的补丁。user@R0>
show system commit server queue patchPending commits: none Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit groups] re1 { ... } + GRP-DHCP-POOL-NOACCESS { + access { + address-assignment { + pool <*> { + family inet { + dhcp-attributes { + maximum-lease-time 300; + grace-period 300; + domain-name verizon.net; + name-server { + 4.4.4.1; + 4.4.4.2; + } + } + } + } + } + } + } Id: 1002 Last Modified: Tue Nov 1 22:50:35 2018 Status: Successfully committed 1002 Patch: [edit] + snmp { + community abc; + } Id: 1010 Last Modified: Wed Nov 2 01:19:25 2018 Status: Successfully committed 1010 Patch: [edit system syslog] file test { ... } + file j { + any any; + } Error commits: Id: 1008 Last Modified: Wed Nov 2 01:08:18 2018 Status: Error while commiting 1008 Patch: [edit system] + radius-server { + 10.1.1.1 port 222; + }输出显示每个提交作业 ID 的配置更改。
-
要查看特定提交作业 ID 的补丁,请发出命令
show system commit server queue patch id <id-number>。user@R0>
show system commit server queue patch id 1000Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit system] + radius-server { + 192.168.69.162 secret teH.bTc/RVbPM; + 192.168.64.10 secret teH.bTc/RVbPM; + 192.168.60.52 secret teH.bTc/RVbPM; + 192.168.60.55 secret teH.bTc/RVbPM; + 192.168.4.240 secret teH.bTc/RVbPM; + }
意义
输出显示为提交作业创建的修补程序。 + 或 - 号表示特定提交作业的配置更改。
查看批量提交作的跟踪文件
目的
查看批量提交作的跟踪文件。您可以将跟踪文件用于故障排除目的。
行动
-
使用此命令查看
file show /var/log/<filename>日志文件中的所有条目。user@R0>
file show/var/log/commitd_nov输出显示提交服务器事件日志和其他批量提交日志。
Nov 1 22:46:43 Successfully committed 1000 Nov 1 22:46:43 pausing after commit for 0 seconds ... Nov 1 22:46:43 Done working on queue ... Nov 1 22:47:17 maximum-aggregate-pool = 5 Nov 1 22:47:17 maximum-entries= 0 Nov 1 22:47:17 asynchronous-prompt = no Nov 1 22:47:17 commit-interval = 0 Nov 1 22:47:17 days-to-keep-error-logs = -1 ... Nov 1 22:47:17 Added to commit queue request-id: 1001 Nov 1 22:47:17 Commit server status=running Nov 1 22:47:17 No need to pause ... Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:47:18 doing rollback ...
-
要仅查看成功批量提交作的日志条目,请使用 pipe 选项发出
file show /var/log/<filename>| match committed命令。输出显示成功提交作的批量提交作业 ID。
user@R0>
file show/var/log/commitd_nov | match committedNov 1 22:46:43 Successfully committed 1000 Nov 1 22:50:35 Successfully committed 1002 Nov 1 22:51:48 Successfully committed 1004 Nov 2 01:08:04 Successfully committed 1007 Nov 2 01:16:45 Successfully committed 1009 Nov 2 01:19:25 Successfully committed 1010 Nov 2 01:28:16 Successfully committed 1011 -
要仅查看失败的批量提交作的日志条目,请使用 pipe 选项发出
file show /var/log/<filename>| match “Error while”命令。输出显示失败提交作的提交作业 ID。
user@R0>
file show/var/log/commitd_nov | match “Error while”Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:51:10 Error while commiting 1003 Nov 1 22:52:15 Error while commiting 1005 ... -
要仅查看提交服务器事件的日志条目,请发出
file show /var/log/<filename>带有 pipe 选项的| match “commit server”命令。输出显示提交服务器事件日志。
user@R0>
file show/var/log/commitd_nov | match “commit server”Nov 1 22:46:39 Commit server status=running Nov 1 22:46:39 Commit server jobs=1000 Nov 1 22:46:43 Commit server status=not running Nov 1 22:46:43 Commit server jobs= Nov 1 22:47:17 Commit server status=running Nov 1 22:47:18 Commit server jobs=1001 Nov 1 22:47:18 2 errors reported by commit server Nov 1 22:47:18 Commit server status=not running Nov 1 22:47:18 Commit server jobs= Nov 1 22:50:31 Commit server status=running Nov 1 22:50:31 Commit server jobs=1002 Nov 1 22:50:35 Commit server status=not running Nov 1 22:50:35 Commit server jobs= Nov 1 22:51:09 Commit server status=running Nov 1 22:51:10 Commit server jobs=1003 Nov 1 22:51:10 2 errors reported by commit server Nov 1 22:51:10 Commit server status=not running ...
在备用启动驱动器上备份提交的配置
提交配置并确信其运行成功后,应发出命令 request system snapshot 将新软件备份到文件系统上 /altconfig 。如果不发出命令 request system snapshot ,则备用启动驱动器上的配置与主启动驱动器上的配置不同步。
该 request system snapshot 命令将根文件系统备份到 /altroot和 /config /altconfig。根和 /config 文件系统位于路由器的闪存驱动器上, /altroot 和 /altconfig 文件系统位于路由器的硬盘上(如果可用)。
发出命令 request system snapshot 后,将无法返回到软件的先前版本,因为软件的运行副本和备份副本相同。