企业官网建设流程全解析

简介：面向网络工程师与Juniper运维人员的SRX防火墙高可用部署指南，系统讲解JSRP双机配置的完整流程，涵盖Cluster ID与Node ID指定、Control Port与Fabric Link规划、Redundancy Group、冗余以太接口及接口监控等核心环节，并对比JSRP与ScreenOS NSRP的差异，适合具备基础防火墙知识、需要落地HA集群的读者。资源为单个PDF文档，大小277KB，内容精炼聚焦，便于随时查阅。已有120人学习下载。文档按7个配置步骤组织，结合SRX5800/3K平台特点给出命令示例与注意事项，可帮助读者理解控制平面与数据平面同步机制，快速完成双机热备环境的搭建与排错。

1. Juniper SRX 防火墙 HA 双机配置在解决什么问题：一次割接夜里的冷启动教训

很多运维第一次翻到《JuniperSRX防火墙HA双机配置步骤.pdf》这类文档，不是在桌面培训，而是在一场凌晨割接复盘会上。上一台主防火墙意外重启，业务断了整整二十分钟，领导目光全落在这台 SRX 上。Juniper SRX 的 HA 双机配置，官方叫法其实是 chassis cluster，本质是把两台物理防火墙组成一个逻辑集群，通过控制链路同步会话与配置，在主节点故障时让备用节点秒级接管转发。它适合正在管理 SRX 单机、准备做双机热备，或者已经配了双机却发现切换时业务照样丢包的工程师。标题看起来只是一份步骤文档，但整条链路从组网设计到验证口径都埋着一堆默认值，这篇按一线落地顺序把它讲透。

2. 配置前先立住三个前提：Cluster ID、控制链路与版本一致性怎么选

很多人打开这份 PDF，第一件事就是找命令，这其实是顺序错了。SRX 的 HA 在设备上叫 chassis cluster，概念上它和某些厂商“两台设备各配策略、再靠 VRRP 抢一个虚拟 IP”的做法不一样。它把两台物理设备的控制面和管理面合并成一个逻辑集群，对外呈现为单台防火墙。所以配置前先想清楚三件事：集群怎么定义、两根专用链路怎么接、两台的系统版本是否一致。这三个前提没定，后面所有命令都只是白敲。

2.1 先分清形态：SRX 的 Chassis Cluster 才对应传统防火墙双机热备

SRX 的 HA 有三个层次容易混淆：物理端口冗余、链路聚合、chassis cluster。端口冗余只是把两个物理口绑成一个 redundant Ethernet（reth）口，解决的是物理链路故障；链路聚合解决的是带宽叠加，不解决设备故障；真正达到“防火墙双机热备”效果的是 chassis cluster。这也是 Juniper 文档里最常被跳过的一段。

配置 chassis cluster 后，两台设备分为 node0 和 node1，分别承担主备角色，少数场景也能做 active/active 双主。数据和转发面状态，包括会话表、NAT 映射、策略命中计数，会通过控制链路实时同步，所以切换时已有连接理论上不断。这一点是很多从传统防火墙转过来的兄弟最容易忽略的：不少中低端产品的双机只做了会话备份，没有把转发面做成一个整体，切换瞬间应用层照样断。SRX 的 reth 口会把两个成员口虚拟成一个逻辑口，主备切换时 MAC 地址不变化，下游交换机不需要重新学习。

实际项目里，绝大多数场景用 active/passive 主备就够了。active/active 需要两个节点同时处理不同接口的流量，还要考虑分流、环路和回程路径，设计复杂度明显上升，除非吞吐压力确实打满一台设备，否则不建议第一套 HA 就上双主。选型时可以问自己三个问题：业务最坏能容忍多少秒中断、峰值吞吐是多少、是否需要区分控制面和数据面的故障优先级。答案决定了你是只用 reth0 单口承载业务，还是给控制面数据面分别建 redundancy-group。这里也提醒刚接手设备的兄弟：SRX 不会像 HCL 防火墙做 RBM+VRRP 那样要求你在每台设备上分别维护虚拟 IP，它把优先级、抢占、接口监控都收敛到了 redundancy-group 里，这也是为什么看 Juniper 的 HA 配置，命令反而比传统防火墙更少。

2.2 两根物理链路不能省：控制链路与数据链路的分工与接法

chassis cluster 要求两台设备之间至少两条直连线路。一条是控制链路（control link），负责心跳、集群状态同步、配置下发；另一条是数据结构链路（fab link），用于主备节点之间的流量转发，比如某个节点的入向流量需要交给另一个节点的出口处理时就靠它转发。

控制链路必须物理直连，不要过交换机，否则交换机拥塞或 STP 收敛会让心跳抖动，严重时造成脑裂。数据链路也同样建议直连，部分型号可以复用数据口，部分分支型号自带 HA 专用口，具体用哪个物理口取决于设备型号和板卡槽位。动手前先执行show chassis hardware确认槽位布局，再决定控制链路接在哪一个口。这一步看似基础，但很多“备机一直 join 不进来”的问题，最后定位就是控制链路接错了物理口。

控制链路和数据链路建议各拉两根做冗余，万一其中一根光纤被误拔，集群不会因为心跳断开而降级。选口时注意别把管理口 fxp0 当作控制口用，管理口走的是独立管理域，不参与集群状态机，误用后在日志里表现为 control link 反复 flap，但物理链路明明是通的，这个问题非常容易误导排查方向。

2.3 版本与身份的一致性：三处必查项

配置 HA 之前，我习惯把下面这张表过一遍。它的作用不是走流程，而是避免在配置完成后陷入“备机 unreachable”的玄学排错。

版本一致性是最容易翻车的。Junos 每个 release 都包含后台数据结构变更，比如会话表格式、加密引擎状态机，cluster 合并时要对同步协议和表结构做一致性校验，build 不一致时备机会长时间停留在 unreachable 状态，甚至反复尝试重建状态机。这不是网络层问题，靠 ping 和抓包都看不出来，所以排错时别把版本检查放在最后。另外建议两台使用相同的 root 密码和基础系统配置，虽然集群会自动同步配置，但开局阶段还没建集群时，所有命令都是各自独立执行的，基线不同会给后面合并造成额外干扰。

Node 编号也值得提前规划。node0 通常对应机架上方那台，node1 对应下方，身份信息写在set chassis cluster cluster-id 1 node 0这条命令里。Cluster ID 一般默认 1 就够，但如果一个机房管理多套集群，建议把 ID 与机柜编号或网段编号绑定，日志排障时能快速区分故障对象。这些前置参数不花时间，但能省掉后面两个小时的排查时间。

3. 从零到主备收敛：chassis cluster 完整命令序列与关键参数说明

前置条件理清楚之后，就可以动命令了。这一步我按“开局清理 → 集群身份 → 冗余口与策略 → 提交确认”的顺序写，每段命令都标注了必须在哪台设备上执行。这里的核心思路是：先把两台设备还原成干净基线，再赋予集群身份，最后才让业务流量走上 reth 冗余口。反过来的话，业务配置和集群配置混在一起提交，出问题后回退范围会变得很大。

3.1 两台设备先回到同一起跑线：出厂配置与基础开局

现场交接的设备经常带着前任工程师的残留配置，直接在上面叠加 HA 配置容易冲突。常见做法是两台都加载出厂默认配置，再重新定义主机名、root 密码和管理地址。以下命令在 node0 和 node1 上分别执行，这段时期它们还是独立设备。

# 加载出厂默认配置，注意这条命令会清掉所有现有配置 load factory-default # 设置 root 登录密码，要求至少满足 Junos 的密码强度 set system root-authentication plain-text-password # 分别命名为 srx-ha-node0 和 srx-ha-node1，便于日志区分 set system host-name srx-ha-node0 # 配置管理地址，先给两台独立的带外管理 IP set interfaces fxp0 unit 0 family inet address 192.168.1.10/24 set system services ssh # 提交并确认，不要用 commit confirmed，开局阶段没必要引入回退变量 commit

逻辑说明：load factory-default会丢弃 active 和 candidate 配置，把设备还原到出厂状态，但不会重启，所以紧接着配置主机名和密码是安全的。plain-text-password会交互式让输入两次密码，不会明文保存在配置里。管理地址先各配各的，等集群建立后再根据实际情况收敛成统一管理入口。

参数说明：fxp0是所有 Juniper 设备默认的带外管理口，它与转发面隔离，即使业务接口全挂了也能远程登录。给两台设备规划管理地址时，建议使用独立管理网段，不要与业务网段混用。有些型号的管理口叫me0，输入接口名时可以用show interfaces terse确认。

3.2 核心命令块：Cluster 身份、控制链路与冗余组

两台设备完成基础开局后，开始定义集群。要特别注意：同一套 cluster 的配置需要在两台设备上分别执行，但 cluster-id 保持一致，node 编号各自不同。以下命令以中型 SRX 平台为例，控制链路接到设备自带 HA 口，数据结构链路用两个高速数据口。

# ============ node0 上执行 ============ # 定义集群身份，node0 是主选节点 set chassis cluster cluster-id 1 node 0 # 启用 2 个 reth 冗余口，按业务需要调整数量 set chassis cluster reth-count 2 # 定义控制链路：node0 的 fpc0 pic0 port 5 set chassis cluster control-port fpc0 pic0 port 5 # 定义数据链路：fab0 对应 node0 的数据口 set interfaces fab0 fabric-options member-interfaces ge-0/0/4 set interfaces fab0 fabric-options member-interfaces ge-0/0/5 # 冗余组 0 承载控制面，node0 优先级 200 set chassis cluster redundancy-group 0 node 0 priority 200 set chassis cluster redundancy-group 0 node 1 priority 100 # 冗余组 1 承载数据面，node0 优先级 200 set chassis cluster redundancy-group 1 node 0 priority 200 set chassis cluster redundancy-group 1 node 1 priority 100 # ============ node1 上执行 ============ set chassis cluster cluster-id 1 node 1 set chassis cluster reth-count 2 set chassis cluster control-port fpc7 pic0 port 5 set interfaces fab1 fabric-options member-interfaces ge-7/0/4 set interfaces fab1 fabric-options member-interfaces ge-7/0/5 set chassis cluster redundancy-group 0 node 0 priority 200 set chassis cluster redundancy-group 0 node 1 priority 100 set chassis cluster redundancy-group 1 node 0 priority 200 set chassis cluster redundancy-group 1 node 1 priority 100

逻辑说明：reth-count决定这台集群最多能创建多少个 reth 逻辑口，不同型号有上限，设置多了不报错，但建议按实际接口规划来写。control-port把物理口指定为控制链路，两台设备必须指向对应的槽位。fab0/fab1是 Junos 预定义的内部数据结构口，不是用户可随意命名的接口，member-interfaces把物理口挂进数据结构链路。

参数说明：优先级范围是 0 到 255，越大越优先成为主节点。一般情况下主备相差 100 以上，避免因为偶发抖动导致角色互换。RG0 是控制面冗余组，只有持有 RG0 主角色且控制面健康的节点才能成为整个集群的主导节点；RG1 是数据面冗余组，业务接口和 reth 口挂在它下面。两台设备的 priority 配置必须完全镜像，否则集群同步会把两边的配置拉成一致，结果与预期不符。

这段配置提交时，两台设备会开始互相探测。正常表现是 node0 先进入 primary，node1 进入 secondary，并且控制链路状态显示 up。如果看到unreachable，优先查物理接线、cluster-id 和 node 编号，不要先怀疑配置被同步覆盖。

3.3 reth 冗余口与安全策略：让流量切换后能找到出口

集群身份建立后，业务接口要绑定到 reth 上，而不是继续使用普通物理口。reth 口的两个成员口分别分布在不同节点，逻辑上对外是一个接口，这样主备切换时 MAC 不变，下游交换机不需要重新学习地址。以下是一个典型的上联下联配置示例。

# 创建 reth0，对应上联核心交换机 set interfaces reth0 redundant-ethernet 0 set interfaces reth0 redundancy-group 1 set interfaces reth0 unit 0 family inet address 10.0.1.1/24 # node0 的 ge-0/0/0 与 node1 的 ge-7/0/0 都挂进 reth0 set interfaces ge-0/0/0 gigether-options redundant-parent reth0 set interfaces ge-7/0/0 gigether-options redundant-parent reth0 # 创建 reth1，对应下联业务服务器区 set interfaces reth1 redundant-ethernet 1 set interfaces reth1 redundancy-group 1 set interfaces reth1 unit 0 family inet address 10.0.2.1/24 set interfaces ge-0/0/1 gigether-options redundant-parent reth1 set interfaces ge-7/0/1 gigether-options redundant-parent reth1 # 把 reth 口划入安全域 set security zones security-zone untrust interfaces reth0 set security zones security-zone trust interfaces reth1 # 配置默认路由，下一跳指向运营商或者核心交换机 set routing-options static route 0.0.0.0/0 next-hop 10.0.1.254

逻辑说明：redundant-parent reth0是绑定动作，它把物理口从普通接口变成 reth 的成员口。成员口本身不能配 IP，所有 IP 和策略都配置在 reth 逻辑口上。redundancy-group 1指明这个 reth 归数据面冗余组管理，这样 RG1 发生切换时，reth0/reth1 同步切换。

参数说明：上联和下联分属不同安全域，后续策略按from-zone untrust to-zone trust方向编写。默认路由的下一跳要写成交换机或运营商侧的网关地址，而不是 reth 口自身地址。很多照着基于防火墙双机热备与 IPSEC 加密隧道的企业网络设计文档搭建的兄弟，第一步就把成员接口配成普通物理 IP，结果两台设备都上线抢占默认路由，流量全部错乱。

提交配置后，建议立即执行show interfaces terse | match reth确认 reth0/reth1 都是 up/up 状态，再执行ping 10.0.1.254验证上联连通性。这里还有个小习惯：首次提交集群配置建议用commit confirmed 5，五分钟后自动回退，防止远程配置把管理面打断。确认无误后再正常 commit。

4. 验证双机不是看灯：show 命令、主动切换演练与 RTO 实测

两台设备都显示绿灯，不代表 HA 真的可用。很多团队把双机配完就收工，直到真故障才发现备机从未成功接管业务。验证双机的正确姿势分三步：看集群状态、做主动切换、用连续打流测真实 RTO。这三步能发现至少一半的隐性配置错误。

4.1 状态收敛后先看三条 show 命令

第一组命令是show chassis cluster status，输出里最重要的是 Cluster ID、Node name、Priority、Status 四列。正常状态是 node0 的 Redundancy Group 1 显示 primary，node1 显示 secondary。如果显示hold或unreachable，说明集群身份或链路有问题。第二组是show chassis cluster interfaces，确认 reth0、reth1 的成员口都在线，并且redundant-parent关系正确。第三组是show chassis cluster control-plane statistics，看心跳报文是否有丢失，丢包率持续不为零，说明控制链路质量差，需要检查光纤和端口协商。

# 查看集群整体角色分布 show chassis cluster status # 查看 reth 接口与成员口状态 show chassis cluster interfaces # 查看控制面心跳统计 show chassis cluster control-plane statistics

逻辑说明：show chassis cluster status输出的 redundancy-group 行是最关键的，RG0 决定谁持有控制面，RG1 决定数据面走向。两行角色必须一致，如果出现 RG0 在 node0 而 RG1 在 node1，业务流量和管理流量会走不同节点，排查起来非常痛苦。control-plane statistics里的 Heartbeat packets 字段正常应该是持续增长且没有丢失，如果看到 fail count 增长，优先怀疑控制链路。

我之前遇到过一次很隐蔽的问题：心跳报文零丢失，集群状态也是 primary/secondary，但只要业务流量稍大，备机就开始报 fabric link overload。最后定位到数据结构链路接了千兆口，而业务流量接近千兆线速，fab 链路过载导致转发延迟。所以验证阶段不仅要看状态，还要在业务流量高峰期再看一次show chassis cluster statistics，确认数据结构链路没有丢包。

4.2 用 request chassis cluster failover 做主动切换演练

真正的双机验证必须做一次主动切换，而不是等故障自己发生。SRX 提供了手动切换命令，可以单独切换某个 redundancy-group，也可以整体切换。生产环境建议先切数据面 RG1，确认业务无感后，再切换 RG0。

# 将数据面 RG1 切换到备机，业务流量的转发面会瞬时切换到 node1 request chassis cluster failover redundancy-group 1 # 观察角色是否互换成功 show chassis cluster status # 切回原主节点，注意 preempt 未开启时不会自动回切 request chassis cluster failover redundancy-group 1

逻辑说明：failover redundancy-group会强制把指定 RG 的角色换到另一个节点，无论优先级如何，适合演练和维护场景。切换过程中，reth 口的 MAC 地址保持不变，所以下游交换机不会感知到变化，这是 SRX 双机相对传统 VRRP 方案的一个优势。

参数说明：如果只想切换控制面，把命令里的redundancy-group 1改成redundancy-group 0。控制面切换会导致当前 SSH 会话短暂中断，需要在切换前确认带外管理链路可用。演练时建议选业务低谷，并且准备好回切命令的复制文本，避免紧张状态下敲错。回切后要再看一次状态，确认角色恢复原样。

这里要说一个常见误区：很多工程师认为“切过去回不来”。实际上只要集群健康，手动 failover 随时可以再切回来。但如果配置了preempt，备机恢复后会自动抢回主角色，这在维护场景可能造成第二次业务抖动，所以我一般建议关闭 preempt，用人工或自动化脚本控制回切时机。

4.3 RTO 怎么测才有说服力：连续打流与计数脚本

双机验证不能只看“通了”，要量化切换过程丢了多少包。方法很简单：在一台业务终端上持续 ping 防火墙的 reth 口地址，同时手动执行 failover，统计丢包数量和恢复时间。这里的难点是 ping 间隔太长会测不出真实 RTO，建议用 100ms 间隔，再结合一个简易计数脚本。

#!/bin/bash # 持续 ping 防火墙 reth 口地址，记录每次失败时间点 ip=10.0.1.1 log=/tmp/ha_rto.log for i in $(seq 1 300); do if ping -c1 -W1 $ip >/dev/null 2>&1; then echo "$(date +%H:%M:%S) ok" else echo "$(date +%H:%M:%S) fail" sleep 0.1 fi done

逻辑说明：脚本固定 ping 300 次，每次超时 1 秒，失败时记录时间戳。执行 failover 命令后，只需要看 log 里连续 fail 的条数和时间跨度，就能算出丢包数和 RTO。正常情况下，主备切换的丢包在 1 到 3 个以内，换算成 RTO 是 1 到 3 秒。如果连续 fail 超过 10 条，说明切换过程存在明显黑洞，大概率是 reth 成员口状态切换慢或下游交换机在重新学习地址。

参数说明：-W1表示超时时间 1 秒，-c1表示只发一个包。脚本里sleep 0.1是为了让日志时间戳更有区分度，避免所有输出集中在同一秒。这个脚本也适合放在定时任务里做周期性健康检查，但注意别把 ping 目标设成运营商地址，避免把公网抖动误判为防火墙故障。

实测数据要保留下来，作为设备割接报告的一部分。演练结束后，我会把“切换前主备角色、切换中丢包数、切换后恢复时间”填进一张固定格式的表格，后续每次版本升级或配置变更后都重新测一遍，保证 RTO 指标没有劣化。

5. SRX HA 排错避坑清单：5 个生产环境里最常见的翻车现场

配置文档只能覆盖标准路径，生产环境的问题几乎都出在边界条件上。这一章列五个我遇到过的真实故障场景，每条按现象、原因、解决的顺序说清楚，你可以直接把它当作排错手册用。

5.1 备机一直显示 “unreachable”：先查这三个身份字段

现象：show chassis cluster status显示 peer unreachable，备机无法加入集群，状态刷在 hold 或 secondary 但始终不能同步配置。

原因：最常见的是 cluster-id 或 node 编号配错，其次是控制链路物理口接错，最后是两台设备 Junos 版本不一致。很多人一上来就怀疑网络，反复换光纤，实际上三个身份字段只要有一个不一致，集群就握手失败。

解决：先执行show chassis cluster status对比两边的 Cluster ID 和 Node ID，再执行show version比对 release 和 build 号，最后检查控制链路是否接在control-port指定的物理口上。我用这个顺序解决过至少五次类似问题，没有一次需要抓包。

# 在三处快速定位 unreachable 的根因 show chassis cluster status show version show chassis cluster control-plane statistics

逻辑说明：unreachable是集群状态机给出的结果，不是原因。它只告诉你两个节点之间无法正常通信，具体是身份不匹配还是链路问题，要靠上面三条命令缩小范围。注意版本比对要精确到 build 号，release 相同但 build 不同也会导致握手失败。

5.2 切换后业务不通：reth 成员口方向性错误

现象：手动切换后 HA 状态正常，备机变成 primary，但业务流量全部中断，ping reth 口地址通，ping 后端服务器不通。

原因：reth 的两个成员口插反了。例如 reth0 的 node0 侧接的是上联交换机，node1 侧接的却是下联交换机，正常工作时 node0 为 primary 看不出问题，一切换到 node1，流量就从错误的物理口出去了。

解决：检查每个 reth 口的成员口接线拓扑，确保 node0 和 node1 的对应成员口接在同一个二层域。如果现场接线已经乱了，最快的补救办法是调整 reth 的成员口绑定关系，而不是去物理拔线。这属于开局规划问题，排查成本很高，所以搭建阶段就要在接口标签上写清楚角色。

5.3 主备来回翻转：优先级一致与 preempt 残留

现象：集群状态在主备之间反复切换，业务每隔几分钟抖动一次，日志里频繁出现redundancy-group failover记录。

原因：两个节点 priority 差距太小，或者配置了preempt，再加上上游链路偶发抖动，触发备机抢主。常见于配置初始阶段有人把两台设备的 priority 都设成了 200，等于没有主次之分。

解决：把 RG0 和 RG1 的 priority 拉开到 100 以上，比如 node0 设 200、node1 设 100，并显式关闭 preempt，让角色切换完全由手工或明确故障触发。

# 清除 preempt，避免备机恢复后自动抢主 delete chassis cluster redundancy-group 1 preempt # 确认两台设备 priority 有明显梯度 show configuration chassis cluster | display set

逻辑说明：preempt的意思是当高优先级节点恢复后，自动抢回主角色。对部分业务来说这种自动回切是友好的，但对稳定性敏感的环境，回切造成的第二次抖动反而更伤业务。关闭后，故障节点恢复会以 secondary 身份加入集群，由运维选择何时手动切回。

5.4 升级系统后集群 degraded：升级顺序与回退方法

现象：升级完一台设备后，集群状态变成 degraded，另一台仍然停留在旧版本，两台设备无法同步配置。

原因：Junos 软件升级必须按“先备后主”的顺序执行，两台设备不能在 build 差异较大的状态下长期共存。如果先升级了当前 primary，集群状态同步协议会因为版本不匹配而进入降级模式。

解决：升级流程应固定为：先升级 secondary，确认其正常运行后手动切主，再升级原 primary，最后切回或保持现状。升级过程中不要同时重启两台设备，否则集群两个节点同时离线，业务直接中断。如果不小心先升级了主设备，回退思路是重新加载旧版本并重启，让集群恢复到一个版本基线，再按正确顺序重来。

# 升级前先确认当前主备角色，只操作 secondary show chassis cluster status # 在 secondary 上安装新版本软件包（以实际包名为准） request system software add /var/tmp/junos-install.tgz # 确认新版正常后，手动切主 request chassis cluster failover redundancy-group 1

逻辑说明：这里的关键动作是“永远保持一个节点可用”。第一次升级的对象必须是 secondary，升级成功后验证业务，再执行 failover，把 primary 变成 secondary 再升级。整个过程两台设备不会同时处于不可用状态。升级包路径和文件名以你实际拿到的软件包为准，不要照抄。

5.5 管理面登录不上：把管理地址绑到 reth 而不是物理口

现象：配置完 HA 后，使用带外管理 IP 能登录 node0，但一旦主备切换，同一个 IP 就登不上了，需要到机房接 console 才能恢复。

原因：管理地址配置在了 node0 的 fxp0 上，而不是绑定在集群冗余口中。切换后 node0 变成 secondary，管理面不再持有原主节点的地址，新的主节点又没有配置该管理 IP。

解决：把用于远程管理的地址配置在 reth 逻辑口上，或者额外创建一个 reth2 专门承载管理 VLAN，保证无论哪个节点是主，管理地址都跟着 RG0 走。带外管理口 fxp0 的地址一般只用于开局，不建议作为日常运维的唯一入口。

# 创建一个 dedicated 管理 reth，绑定到 RG0 set interfaces reth2 redundant-ethernet 2 set interfaces reth2 redundancy-group 0 set interfaces reth2 unit 0 family inet address 192.168.1.20/24 set interfaces ge-0/0/2 gigether-options redundant-parent reth2 set interfaces ge-7/0/2 gigether-options redundant-parent reth2

逻辑说明：redundancy-group 0是控制面专用，把它和 reth 口绑定后，管理地址会始终跟随主控制面节点。这样无论主备如何切换，运维都能用同一个 IP 登录防火墙。注意 reth2 要接在带外管理或独立管理 VLAN 中，不要和业务流量混跑。

6. 让这份步骤文档长出参数：监控阈值、预占策略与切换演练计划

文档到这里其实只是完成了“能用”，距离“好用”还差一层参数调优。最后补充三个进阶配置思路，这决定了 HA 双机在真实故障面前的表现。

第一是接口级故障监控。默认情况下，只有控制链路和数据链路出问题才会触发 RG1 切换，但你的上联物理口如果单独宕掉，集群未必会感知。常见做法是给 RG1 配置 interface-monitor，把上联口纳入监控，一旦链路 down 主动触发切换。阈值不宜设得太激进，我一般会结合下游交换机端口恢复时间把它设得保守一些，宁可让它晚切几秒，也不要因为链路闪断频繁切换。

# 将 node0 的上联物理口纳入 RG1 监控，配置项以实际版本提示为准 set chassis cluster redundancy-group 1 node 0 interface-monitor ge-0/0/0

第二是预占策略。生产环境我几乎都关闭 preempt，改用人工或工单系统控制回切，避免故障恢复瞬间产生二次抖动。关闭后，原主节点恢复后会以 secondary 身份静默加入，直到你确认一切正常再手动切回，这一步是最容易忽略的参数，也是双机稳不稳的分水岭。

第三是切换演练计划。我建议每季度做一次手动切换演练，每次演练留出 30 分钟窗口，按“查看当前主备、启动打流脚本、执行 failover、记录丢包、回切、再次记录”六步走。演练结果归档后会形成一张 RTO 趋势表，如果某次丢包数明显上升，说明防火墙内部状态同步出了问题，可以提前处理而不是等故障爆发。

这几年的 HA 配置经验里，我得失最深的教训是：优先级的数字大小远没有预占策略、接口监控阈值对人。有一年我把优先级和 preempt 都调到了“标准答案”，结果光纤闪断引发备机抢主，业务断了两分钟，从那以后我把 preempt 关掉，把切换条件收敛到明确的链路故障和主动演练，切换次数反而少了一大半。这套思路也写进了我所有 HA 项目的评审清单里，希望帮到你。

本文还有配套的精品资源，点击获取