3. Junos OS基础操作与配置管理
Junos OS 的配置管理模型与多数通用网络操作系统有本质区别：它把“运行中的配置”和“候选配置”分离，所有修改先进入候选配置，经语法与语义校验后，再由 commit 一次性原子生效。理解这一模型，是后续在 MX 平台上安全变更、快速回退和批量运维的基础。
CLI 的两种操作模式
登录 MX 路由器后，CLI 首先进入操作模式（Operational Mode），提示符为 >。该模式用于查看状态、执行诊断和触发运维动作，例如：
user@MX204> show interfaces ge-0/0/0 terse
user@MX204> show route summary
user@MX204> ping 192.0.2.1 count 5
user@MX204> request system reboot输入 configure 后进入配置模式（Configuration Mode），提示符变为 #。此时命令作用于候选配置，而不是立即生效的运行配置。配置模式内部还有层次：edit 进入某个层级，top 回到顶层，up 返回上一级，exit 逐级退出，quit 直接退出配置模式。提示符会随层级变化，例如 [edit interfaces ge-0/0/0]，这是判断“当前在改哪一层”的最直接依据。
配置层次结构与 set/delete 操作
Junos 配置是一棵严格的树：顶层包含 system、interfaces、protocols、routing-options、policy-options、firewall 等分支。同一层级中，容器节点（如 interfaces）可以包含多个子节点，而叶子节点（如 description、unit 0 family inet address）承载具体值。
修改配置有两种等价风格。第一种是逐层 edit 后直接输入语句：
user@MX204# edit interfaces ge-0/0/0
user@MX204# set description "to-Core-R1"
user@MX204# set unit 0 family inet address 192.0.2.1/30
user@MX204# top第二种是使用完整路径的 set 命令，适合脚本化和批量操作：
user@MX204# set interfaces ge-0/0/0 description "to-Core-R1"
user@MX204# set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.1/30
user@MX204# delete interfaces ge-0/0/1 description两种方式写入的是同一棵候选配置树，因此可以混用。查看候选配置用 show，只看与运行配置的差异用 show | compare，这是提交前最关键的检查动作：
user@MX204# show | compare
[edit interfaces ge-0/0/0]
+ description "to-Core-R1";
+ unit 0 {
+ family inet {
+ address 192.0.2.1/30;
+ }
+ }行首的 + 表示新增，- 表示删除，无符号行是上下文。养成“改完必 compare”的习惯，可以避免误删或漏配。
commit 与 rollback 机制
commit 会先做语法检查，再检查语义（如引用不存在的策略、地址冲突、接口不存在等），全部通过后才把候选配置合并进运行配置。若校验失败，候选配置保留，可继续修改。常用变体包括：
commit check：只校验不生效，适合在正式提交前预检。commit confirmed 5：提交后 5 分钟内若未再次执行commit，系统自动回滚到提交前状态。这是远程改管理接口、改路由策略时的“安全绳”。commit and-quit：提交成功后直接退出配置模式。commit comment "add core uplink"：为本次提交写入注释，便于日后审计。
Junos 默认保留最近 50 个提交点（可通过 set system max-configurations-on-flash 调整）。回退时先看历史：
user@MX204> show system commit
0 2024-06-11 10:22:31 UTC by user via cli
1 2024-06-11 09:58:04 UTC by user via cli
2 2024-06-10 18:03:12 UTC by root via cli然后执行 rollback 1 把候选配置恢复为第 1 个提交点的内容，再用 show | compare 确认差异，最后 commit 使其生效。rollback 0 表示回到当前运行配置，用于放弃未提交的修改。注意：rollback 只改候选配置，不自动提交。
配置归档与救援配置
提交点保存在设备本地，若设备无法启动或配置被破坏，需要外部备份。Junos 提供两类机制：
配置归档通过 system archival configuration 在每次提交后把配置上传到 FTP/SCP 服务器，形成带时间戳的历史文件：
set system archival configuration transfer-on-commit
set system archival configuration archive-sites "scp://backup@198.51.100.10:/configs" password "ExamplePass"救援配置（Rescue Configuration）是设备本地的一份“已知良好”配置快照。执行 request system configuration rescue save 保存当前配置为救援配置；当变更导致设备失联时，可在启动阶段或通过 rollback rescue 恢复：
user@MX204> request system configuration rescue save
user@MX204# rollback rescue
user@MX204# commit建议在每次重大变更前保存救援配置，并确认归档服务器可达。
批量配置与脚本化入门
Junos 支持 load merge、load replace、load override 三种加载方式，用于把外部文件合并进候选配置。load merge 保留现有配置并叠加新内容，最常用；load replace 替换指定层级；load override 用文件完全替换整个配置，风险最高，需谨慎。
user@MX204# load merge terminal
[Type ^D to end]
interfaces {
ge-0/0/2 {
description "to-PE2";
unit 0 { family inet { address 192.0.2.5/30; } }
}
}
^D
user@MX204# show | compare
user@MX204# commit check
user@MX204# commit更进一步，Junos 提供 commit 脚本和 op 脚本，可用 SLAX 或 Python 编写。入门阶段可先掌握“用 set 命令写成文本文件，再通过 load merge terminal 批量导入”的方式，这已经能覆盖大部分重复配置场景。脚本化时注意：脚本运行在受控环境中，修改配置仍需走候选配置与 commit 流程，不能绕过校验。
show | compare 看差异 → commit check 做校验 → 远程变更用 commit confirmed 留退路 → 重大变更前 request system configuration rescue save。把上述流程固化为习惯后，MX 平台上的配置变更就从“高风险操作”变成“可检查、可回退、可审计”的常规动作。下一阶段可以在此基础上引入更复杂的策略配置与脚本自动化。