3. Junos操作系统高可用特性
在QFX系列交换机组成的园区或数据中心网络中，控制平面与转发平面的可用性直接决定了业务中断的时长。Junos操作系统的高可用特性并不是单一功能，而是一组围绕“控制平面冗余、转发平面不中断、配置状态可恢复”协同工作的机制。理解这些机制的分工与配合，才能在实际组网中正确启用并验证它们。
Junos高可用架构：主备RE与双平面分离
支持双路由引擎（Dual RE）的QFX设备（如QFX5100、QFX5110、QFX5120、QFX10002等）内部存在两个独立的路由引擎插槽：RE0与RE1。每个RE拥有独立的CPU、内存、控制板与Junos镜像，但共享同一套转发芯片（PFE）与接口。同一时刻只有一个RE处于主用（Master）状态，负责运行路由协议、生成转发表、管理配置；另一个处于备用（Backup）状态，持续同步配置与协议状态，但不向PFE下发转发表项。
两个RE之间通过专用的控制链路（通常为内部千兆以太网）通信，用于心跳检测、配置同步、协议状态复制。转发平面与控制平面在物理上分离，这是“非stop转发”能够成立的前提：即使主RE失效，PFE中已有的转发表项仍可继续转发流量。
判断当前主备状态，最直接的命令是：
user@qfx> show chassis routing-engine
Routing Engine status:
Slot 0:
Current state Master
Election priority Master (default)
Slot 1:
Current state Backup
Election priority Backup (default)输出中的Current state字段是判断主备的唯一权威依据。若显示Disabled，说明该RE未参与选举，通常是因为未配置双RE或该槽位故障。
进程监控与重启：RE内的自愈机制
Junos将控制平面功能拆分为多个独立进程（daemon），例如rpd负责路由协议、mgd负责管理接口、chassisd负责硬件监控、dcd负责接口配置。每个进程由init或watchdog监控，一旦进程异常退出，系统会按预设策略自动重启该进程，而不必重启整个RE。
进程重启策略由system processes层级配置，关键参数包括：
core-file：进程崩溃时是否生成core文件，便于事后分析。restart：进程异常退出后是否自动重启，默认多数关键进程为on-failure。failover：进程连续重启失败达到阈值后，是否触发RE切换。
例如，将rpd配置为连续失败3次后触发切换：
set system processes rpd failover other-routing-engine
set system processes rpd restart on-failure 3需要区分两类故障：进程级故障只影响单个daemon，重启后通常可恢复；RE级故障（如内核panic、内存耗尽）则必须依赖RE切换。进程监控的价值在于把大量“本可自愈”的故障拦截在RE切换之前，减少不必要的切换开销。
平滑路由引擎切换（GRES）：切换时协议不中断
平滑路由引擎切换（Graceful Routing Engine Switchover，GRES）解决的是“切换瞬间控制平面协议状态丢失”的问题。启用GRES后，主RE会持续将路由协议状态、接口状态、转发状态同步到备RE。当主RE失效时，备RE在接管后无需重新收敛协议，邻居关系保持，转发表项延续。
启用GRES的基本配置：
set chassis redundancy graceful-switchoverGRES生效的前提是双RE均正常运行且同步完成。可通过以下命令确认同步状态：
user@qfx> show chassis synchronization
Synchronization status: In sync若显示Not in sync，说明备RE尚未完成状态复制，此时切换仍会发生，但协议可能重新收敛。GRES只保证控制平面平滑，转发平面是否真正不丢包，取决于下一节的非stop转发。
非stop转发（NSR/NSB）：转发平面不中断
非stop转发（Nonstop Forwarding，NSF）在Junos中通常与非stop路由（NSR）和非stop桥接（NSB）配合使用。其核心思想是：主RE切换期间，PFE继续使用已有的转发表转发报文，不因控制平面切换而清空或重建转发表。
NSR与GRES的区别在于：GRES依赖邻居设备配合（通过GR/LLGR等协议扩展），而NSR由本机双RE之间直接同步协议状态，不要求邻居感知切换。对于QFX作为接入或汇聚设备的场景，NSR通常更可控。
启用NSR的典型配置：
set routing-options nonstop-routing
set protocols ospf nonstop-routing
set protocols bgp graceful-restart验证NSR是否生效，可在切换前后观察OSPF邻居状态与BGP会话：
user@qfx> show ospf neighbor
Address Interface State ID Pri Dead
10.0.0.2 ge-0/0/1 Full 1.1.1.1 128 38若切换后邻居仍为Full且Dead计时器未重置，说明NSR与GRES协同工作正常。若邻居变为ExStart或Down，则需检查NSR配置是否覆盖了对应协议。
配置恢复机制：rescue配置与自动回滚
高可用不仅指运行时不中断，也包括配置错误后的快速恢复。Junos提供两层配置恢复机制：
- rescue配置：管理员可预先保存一份“已知可用”的配置，在误操作导致设备失联时，通过
rollback rescue一键恢复。 - commit confirmed：提交配置时设置确认时间（默认10分钟），若期间未再次确认，系统自动回滚到上一版本。
保存与恢复rescue配置的操作如下：
user@qfx# save rescue configuration
user@qfx# rollback rescue
user@qfx# commit对于远程操作，推荐使用commit confirmed 5，给自己留出验证窗口：
user@qfx# commit confirmed 5
commit confirmed will be automatically rolled back in 5 minutes unless confirmed
user@qfx# commit若5分钟内未执行第二次commit，配置自动回滚。这一机制与GRES/NSR形成互补：前者防止“配置错误导致失联”，后者防止“硬件或进程故障导致中断”。
四类机制的协同关系与验证要点
上述四类机制并非孤立，而是按“故障层级”分工：进程监控处理daemon级异常，GRES处理RE切换时的协议平滑，NSR/NSB处理转发平面不中断，配置恢复处理人为配置错误。实际部署中，建议按以下顺序验证：
- 确认双RE均
show chassis routing-engine状态正常，且show chassis synchronization为In sync。 - 检查
set chassis redundancy graceful-switchover已启用。 - 对OSPF/BGP等关键协议启用
nonstop-routing，并确认邻居在切换后保持Full。 - 保存rescue配置，并在远程操作时使用
commit confirmed。
需要特别注意的是，GRES与NSR同时启用时，切换期间控制平面由备RE接管，转发平面由PFE维持，两者时间窗口重叠但互不依赖。若只启用GRES而未启用NSR，切换时协议邻居可能因未收到GR消息而重置；若只启用NSR而未启用GRES，备RE可能因状态未同步而无法立即接管。因此，在QFX双RE场景中，两者通常成对配置。
show chassis routing-engine的主备变化，还应同时观察show ospf neighbor的Dead计时器是否重置、show interfaces statistics的丢包计数是否增长。若丢包计数在切换瞬间明显上升，说明NSR/NSB未完全生效。最后，配置恢复机制虽然简单，却是运维中最常被忽略的一环。建议在每次重大变更前执行save rescue configuration，并在远程操作时始终使用commit confirmed。这两条习惯与GRES/NSR形成“运行时+配置时”的双重保护，使QFX高可用架构真正闭环。