📚 课程目录第2章 Juniper设备配置管理基础

2. Juniper设备配置管理基础

Junos 的配置管理模型与多数网络操作系统有本质区别：设备上运行的配置并不是一份“正在生效的文本文件”，而是由候选配置（candidate configuration）、提交（commit）动作和配置版本库共同构成的一套事务化机制。理解这套机制，是后续用 NETCONF、REST API 或自动化框架安全读写配置的前提。

一、配置层次结构：从层级树到 set 命令

Junos 配置是一棵严格的层次树，根为 edit 上下文，向下依次是 system、interfaces、protocols、routing-options、security 等顶层语句。每个节点由“语句名 + 值 + 可选子节点”构成，例如接口配置的路径是 interfaces ge-0/0/0 unit 0 family inet address 192.0.2.1/24。这种层级结构决定了两种等价的配置表达方式：

层级文本形式：用花括号嵌套，适合人工阅读和整体查看，如 show configuration interfaces ge-0/0/0 的输出。
set 命令形式：把整条路径压平为一行，适合脚本逐条下发，如 set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.1/24。

两者描述的是同一棵树，因此可以互相转换：show configuration | display set 把层级文本转为 set 形式，而 load set 或 load merge 则把 set 文本重新装载回层级树。自动化场景中通常使用 set 形式，因为它天然是“一行一条路径”，便于程序生成、比对和幂等重放。

与 set 对应的是 delete。删除同样按路径定位：delete interfaces ge-0/0/0 unit 0 family inet address 192.0.2.1/24 只移除该叶子节点；delete interfaces ge-0/0/0 则删除整个接口节点及其全部子节点。需要注意，delete 作用于候选配置，不会立即影响转发，必须经过 commit 才生效。若路径不存在，Junos 会给出 warning 而非报错，这在自动化脚本中容易被忽略，因此建议在关键删除后配合 show | compare 确认差异。

二、候选配置与 commit / rollback 机制

Junos 的配置编辑默认发生在候选配置上。进入 configure 模式后，所有 set/delete 都只修改候选副本，直到执行 commit 才把候选配置校验、应用并写入版本库。这一设计带来三个关键能力：

原子性：commit 是一次事务，校验失败则整体不生效，不会出现“改了一半”的中间状态。
可回滚：每次成功 commit 都会生成一个新版本，rollback 1 回到上一版本，rollback 0 回到当前已提交版本（丢弃未提交修改）。
可预检：commit check 只做语法与语义校验，不真正应用；commit confirmed 5 则在 5 分钟内若未再次确认，自动回滚，是远程改配置的“安全绳”。

版本库默认保留最近 50 个提交版本，可用 show system commit 查看版本号、时间、提交者和注释。回滚时也可以直接指定版本号，如 rollback 3。在自动化中，建议每次 commit 都带注释：commit comment "auto: add loopback0 for test"，这样版本历史本身就是一份可追溯的变更日志。

三、配置版本与救援配置

救援配置（rescue configuration）是一份被显式标记的“已知良好”配置快照。执行 request system configuration rescue save 会把当前提交配置保存为救援配置；当设备因误配置导致管理面不可达时，可在 console 或通过 rollback rescue 快速恢复到该状态。它与普通版本的区别在于：救援配置是独立命名的基准点，不会被后续 commit 覆盖，适合作为设备出厂基线或割接前的安全锚点。

下表对比了几种恢复手段的适用场景：

手段	作用对象	典型场景
rollback 1	上一提交版本	刚提交的变更引发问题
rollback rescue	救援配置	管理面失联、需回到基线
commit confirmed	未确认的提交	远程改配置的自动兜底
load override	整份配置	用外部文件完全替换配置

四、通过 NETCONF / REST API 读写配置

Junos 的 NETCONF 服务默认监听 830 端口，REST API 通常走 HTTPS 的 /rpc 或 /restconf 端点。两者底层都映射到同一套配置操作，只是封装不同。NETCONF 使用 XML 的 <edit-config> 操作，配合 candidate 数据存储和 <commit> 完成事务；REST API 则可用 JSON 或 XML 提交同样的内容。

下面是一个通过 NETCONF 修改接口描述并提交的示例（示例参数，非实测输出）：

<rpc>
  <edit-config>
    <target><candidate/></target>
    <config>
      <configuration>
        <interfaces>
          <interface>
            <name>ge-0/0/0</name>
            <description>uplink-to-core</description>
          </interface>
        </interfaces>
      </configuration>
    </config>
  </edit-config>
</rpc>
<rpc><commit/></rpc>

对应的 REST 调用可写成 POST /rpc/edit-config 加 POST /rpc/commit，或使用 RESTCONF 的 PATCH 到候选数据存储后再 POST commit。无论哪种方式，关键点一致：先写候选，再校验，最后提交；读取时用 <get-config> 或 GET 请求获取 running 配置，并可用 XPath 或 subtree filter 只取所需子树，避免拉取整份配置。