2. Juniper设备资产与版本基线梳理

升级迁移项目最容易失控的环节，往往不是配置命令本身，而是“不知道自己有什么”。在动任何一台设备之前，必须先把现网 Juniper 设备的资产台账和软件版本基线建立起来。这一步的产出物将直接决定后续升级路径、停机窗口、回退方案和风险评估的准确性。本节围绕 EX、QFX、MX、SRX 四条产品线，说明如何盘点型号、Junos 版本、生命周期状态，并构建兼容性矩阵。

一、资产盘点的四个维度

资产盘点不是简单抄一遍设备清单，而是要形成可支撑决策的结构化数据。建议至少覆盖以下四个维度：

• 硬件维度：产品系列（EX/QFX/MX/SRX）、具体型号（如 EX4300-48T、QFX5120-48Y、MX204、SRX345）、序列号、机框/堆叠成员、板卡与子卡（MPC、MIC、FPC）、电源与风扇冗余状态。
• 软件维度：当前 Junos 版本（如 20.4R3-S5）、版本类型（R 版、S 版、X 版）、是否启用双 RE、是否启用统一 ISSU、Junos Evolved 与标准 Junos 的区分。
• 生命周期维度：硬件 EOL/EOS 状态、Junos 版本 EOL 时间、是否处于 Extended End-of-Life 支持期。
• 业务维度：设备角色（核心/汇聚/接入/边界）、承载业务、上下游邻居、是否在关键路径上。

实际执行时，可通过 show chassis hardware、show version、show virtual-chassis status、show chassis cluster status 等命令批量采集。对于规模较大的网络，建议用 Junos PyEZ 或 Ansible 批量拉取，避免人工抄录出错。

# 批量采集示例（Junos PyEZ）
from jnpr.junos import Device
dev = Device(host='10.0.0.1', user='ops', password='***')
dev.open()
print(dev.facts['model'], dev.facts['version'], dev.facts['serialnumber'])
dev.close()

二、Junos 版本基线与命名规则

Junos 版本号形如 20.4R3-S5.4，理解其结构是判断兼容性的前提。主版本（20.4）代表功能基线，R 表示正式发布（Release），S 表示服务版本（Service Release，只修缺陷不加功能），X 表示特殊版本。同一主版本内，R1 通常是新功能首发，R2/R3 稳定性更好，因此生产网一般推荐 R2 及以后的 S 版本。

基线梳理的核心目标是回答三个问题：现网版本是否已 EOL？目标版本是否被硬件支持？升级路径是否需要跨主版本？例如从 18.4R3 升到 22.4R3，通常不能一步到位，需要经过 20.4R3 作为中间跳板，因为 Junos 官方只保证相邻主版本或指定路径的升级兼容性。

三、生命周期状态与兼容性矩阵

Juniper 的生命周期分为 GA（一般可用）、EOL（停止销售）、EOS（停止服务）、EOS-Extended（延长支持）等阶段。硬件 EOL 后仍可运行，但不再获得新版本支持；软件 EOL 后不再发布安全补丁。升级前必须确认目标版本是否仍在支持期内，否则升级后可能面临无补丁可用的风险。

兼容性矩阵是本节最重要的交付物，它把“设备型号 × Junos 版本 × 生命周期状态”三者关联起来。下表为示例结构（数据为教学假设，非实测）：

矩阵中每一行都要能回答：该设备能否直接升级？是否需要更换硬件？升级后是否仍在支持期？如果某台 MX 的 MPC 板卡不支持目标版本，就必须先更换板卡或调整升级目标。

四、从盘点结果到升级决策

盘点完成后，通常会出现三类设备：可直接升级（版本路径清晰、硬件在支持期）、需跳板升级（跨主版本，需中间版本）、需先更换或下线（硬件 EOL 且目标版本不支持）。这三类设备应分别制定策略，而不是统一按一个窗口推进。

此外，还要关注双 RE、虚拟 chassis（VC）、chassis cluster 等冗余形态。例如 EX 的 VC 升级需要按成员逐个进行，MX 的双 RE 升级要确认 GRES/NSR 是否启用，SRX 的 cluster 升级要确认双机心跳与抢占配置。这些细节都会影响停机时长和回退复杂度。

完成上述梳理后，团队应当得到一份可执行的升级路径表：每台设备对应明确的当前版本、目标版本、中间跳板、停机预估和回退点。这份表就是后续所有升级操作、验证脚本和回退预案的输入。没有它，升级迁移就只能靠经验拍脑袋，风险不可控。