企业官网建设流程全解析

简介：这份专为Juniper SRX防火墙高可用部署准备的配置指南，面向企业网络运维工程师及安全架构师，系统梳理HA双机切换的完整实施路径，特别针对SRX5K与SRX3K两类主流平台的差异给出对照建议。文档从JSRP协议与ScreenOS NSRP的区别切入，解释JSRP将两台设备抽象为逻辑机箱、支持主备/主主模式，以及控制面与数据面分别通过Control Port和Fabric Link互联的机制；随后按步骤展开Cluster ID/Node ID设置、Control Port与Fabric Link规划、Redundancy Group及冗余以太接口配置、接口监控等七大关键配置，并补充接口板卡严格对应、光纤直连等实施注意事项。资源包为1个PDF文件，大小277KB，以配置命令和注释为主线，结构紧凑，适合现网改造前快速查阅与对照落地。目前已有122人学习，适合具备基础JUNOS操作经验、需要独立完成SRX双机热备部署或排查切换异常的网络技术人员。

1. Juniper SRX 双机 HA：从单点故障到秒级切换的现实账本

一台 SRX 扛出口网关时，最怕的不是策略写得不对，而是硬件单点故障之后整段业务跟着下线。Juniper SRX 双机 HA 在现网里的落地形态是 Chassis Cluster（机箱集群），把两台独立设备通过专用控制链路和 fabric 数据链路合成一台逻辑网关。平时主节点转发全部流量，备节点实时同步配置、会话表和安全策略；主节点故障或人工介入时，备节点在同一组 reth 接口 IP 上接管转发，业务中断按秒计，不用改路由下一跳、不用动终端网关。这篇笔记面向刚拿到两台 SRX 准备组双机热备的运维和网络工程师，按物理连接、集群配置、切换验证、现场避坑的顺序展开，以 SRX300 系列为模板，其他型号思路一致。

2. 开局先把两节点的“背脊”接对：SRX 物理链路、管理地址与可测光学核查

双机 HA 里最容易被低估的是物理层。很多运维上来就敲set chassis cluster，敲完发现集群状态起不来，回头查才发现光纤接反、光模块选错、控制链路压根没插。这一步决定了后面所有配置有没有意义。我习惯先把链路理清：控制链路、fabric 链路、管理口三条线各司其职，再动手。

2.1 双机拓扑里不止一根线：fabric、控制链路和管理口各管什么

SRX 集群不是“拿一根网线把两台设备连起来”那么简单。逻辑上至少有三条独立通道，少一条都可能让集群处于半残状态。

控制链路走的是低带宽控制协议，fabric 链路才是真正的数据同步通道。两者缺一不可：控制链路断了，集群会脑裂；fabric 链路断了，备节点拿不到完整会话表，切换时业务必断。

接线顺序也有讲究。先把控制链路两端接好，再接 fabric 光纤，最后上电。有些型号对控制链路的连接方式有硬性要求（RJ45 交叉线或专用 CSR 互联线），拿普通直通网线去怼，端口状态能 up 但心跳包过不去，属于比较玄学的故障，后面避坑章节会展开。

2.2 配置前的三个准备动作：root 口令、管理地址与主机名

拿到两台全新 SRX 后，先别急着组集群。每个节点是独立设备，需要单独完成基础引导。我一般先用 console 线连接设备，因为后面启用集群的瞬间 SSH 会话很可能会断开。

# 节点 0 的首次引导 configure set system host-name srx-ha-node0 set system root-authentication plain-text-password set system services ssh set interfaces fxp0 unit 0 family inet address 172.16.1.10/24 set routing-options static route 0.0.0.0/0 next-hop 172.16.1.254 commit

这段配置的逻辑很清楚：第一行给设备起名，方便后续日志区分主备；root 口令用交互方式输入两遍，不回显；fxp0 是管理口，给一个独立的带外地址，避免和设备业务段混在一起；默认路由指向管理交换机，保证远程维护可达。

参数上要注意两点：一是 fxp0 地址必须在两台节点上各不相同，比如节点 0 用 172.16.1.10、节点 1 用 172.16.1.11，否则集群建立后管理平面会冲突；二是不要在这个阶段就把 ge-0/0/0 配置成业务口，因为 SRX300 系列的默认 fabric 口就是它，一旦被人占掉，后面集群链路会非常难搞。两个节点都按同样的方法引导，只是 hostname 和 fxp0 地址不同。

2.3 用 show interfaces diagnostics optics 把光口状态先摸清

光纤链路不是插上就通。两个节点端口的收发必须交叉，模块 DAC 线和光模块不能混用，单模多模波长也得一致。我见过最典型的翻车场景：两边都插了 SFP，看起来灯亮，但show chassis cluster interfaces里 fabric 状态始终是 offline。这种问题用肉眼查不出来，必须用命令看光模块参数。

# 节点 0 与节点 1 都执行 show interfaces terse | match ge-0/0/0 show interfaces diagnostics optics ge-0/0/0 show interfaces diagnostics optics ge-7/0/0 show log messages | match "SFP|optical|transceiver"

show interfaces terse先确认端口没有被配置成普通业务口，状态应该是 up。show interfaces diagnostics optics输出里重点看 TX 光功率、RX 光功率和温度告警位。正常情况下 RX 功率应该在模块接收灵敏度之上，比如多模模块一般在 -10 到 -3 dBm 之间；如果 RX 一直显示 -40 dBm 甚至 “LOS”，基本可以断定光纤没收到光。再看日志里有没有 SFP 模块识别失败或者温度越限的记录，排除硬件层面问题再回集群配置。

3. 用 CLI 把两台 SRX 绑成机箱集群：集群 ID、fabric 成员与冗余组参数

物理链路确认无误后，才进入真正的集群配置阶段。这一步的核心是把两台独立设备通过cluster-id和node-id“焊接”成一个逻辑体，再做 fabric 成员和冗余组参数的下发。顺序上我习惯先让集群身份成立，再谈数据平面。

3.1 集群 ID 与节点 ID：两台设备如何先互相“认出”对方

Juniper 的机箱集群依赖一组身份参数完成配对：两台设备的cluster-id必须一致，node-id分别取 0 和 1。这两个参数决定了设备在集群里的角色和接口编号规则。

# 节点 0 configure set chassis cluster cluster-id 1 node 0 commit

# 节点 1 configure set chassis cluster cluster-id 1 node 1 commit request system reboot

逻辑说明：节点 0 先提交cluster-id 1 node 0，节点 1 再提交cluster-id 1 node 1。提交后设备会把集群参数写入本地配置，重启后 fabric 端口才能切换成集群模式。如果两台同时配置同时重启，控制链路的协商时序容易错位，反而不利于首次握手。

参数范围：cluster-id取值 0 到 15，node-id只能是 0 或 1。同一个网络环境里如果有多个 SRX 集群，cluster-id 不要重复。提交后先不配任何业务，直接执行show chassis cluster status，能看到两个节点的状态从 “Inactive” 变成 “Primary / Backup” 再继续下一步。这一步只有集群身份，还没有数据面，设备重启后管理地址会从 fxp0 迁移到 vme 逻辑口，所以远程管理地址要在集群形成后重新确认。

3.2 fabric 成员接口与 reth 聚合：把数据链路并入集群

集群身份就绪后，要把物理数据口纳入集群。SRX 的集群数据口不是直接用 ge-0/0/1 这样的物理口配 IP，而是先定义一个逻辑聚合口reth，再把两台设备上的物理成员挂进去。这样切换时 reth 接口整体在节点间搬家，IP 和 MAC 不变。

# 在主节点上配置（备节点随集群同步） set interfaces fab0 fabric-options member-interfaces ge-0/0/0 set interfaces fab1 fabric-options member-interfaces ge-7/0/0 set chassis cluster reth-count 2 set interfaces ge-0/0/1 gigether-options redundant-parent reth1 set interfaces ge-7/0/1 gigether-options redundant-parent reth1 set interfaces reth1 redundant-ether-options redundancy-group 1 set interfaces reth1 unit 0 family inet address 203.0.113.1/24 set interfaces ge-0/0/2 gigether-options redundant-parent reth2 set interfaces ge-7/0/2 gigether-options redundant-parent reth2 set interfaces reth2 redundant-ether-options redundancy-group 1 set interfaces reth2 unit 0 family inet address 198.51.100.1/24

逻辑说明：fab0和fab1是从主节点视角定义的 fabric 通道，member-interfaces分别指向本机物理口和对端物理口。reth-count 2声明这台集群创建两个冗余以太口，后续业务都用 reth1、reth2，不再直接引用物理口。每个 reth 下面挂两个物理成员：节点 0 的 ge-0/0/1 和节点 1 的 ge-7/0/1，只要有一端存活，reth1 就保持在线。

这个阶段最大的坑是物理成员接口不能同时配置独立 IP。如果 ge-0/0/1 之前被配过地址，必须delete interfaces ge-0/0/1 unit 0清干净，否则redundant-parent reth1会提交失败。另外 reth 接口默认不带 vlan-tagging，如果业务侧要跑 trunk，需要在 reth 下加上vlan-tagging再分别配 unit。

3.3 redundancy-group 优先级与监控链路：主备偏好和自动切换的开关

reth 配完之后，还要回答一个问题：谁是主、谁是备，凭什么是它。这就是 redundancy-group（冗余组）做的事。RG0 是控制平面冗余组，负责路由引擎和集群管理平面的主备；RG1 及以后是数据平面冗余组，绑定具体的 reth 接口。

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

优先级范围是 1 到 255，数字越大越倾向成为主。上面配置让节点 0 在控制平面和数据平面都是主。如果希望业务流量主要跑在节点 0，而控制平面主备可以随心跳自动切换，就把 RG0 两个节点的优先级设成相同值，让系统自己选。

这里还可以加监控接口，让集群在检测到关键链路故障时自动降级。比如上行口 ge-0/0/1 所在的 reth1 断掉，就触发整组切换：

set chassis cluster redundancy-group 1 monitoring-interface ge-0/0/1

不过监控接口是一把双刃剑。我一般建议先不加，等业务跑稳之后，在维护窗口里逐步加监控并观察切换行为。因为监控接口如果误报或者抖动，可能引发频繁切换，比故障本身还伤业务。

4. 避坑地图：集群起不来、脑裂、配置丢与切换黑洞的五个现场

后面的这些坑，都是我这些年跑现网反复撞过的。每个都按“现象 → 原因 → 解决”拆开写，方便对号入座。

4.1 fabric 老是不 up，show chassis cluster interfaces 一直报 offline

现象：show chassis cluster interfaces里 fabric 状态是 offline，集群状态显示两个节点都处于异常，业务起不来。

原因：最常见就三种。一是光纤收发接反了，节点 0 的 TX 没有接到节点 1 的 RX；二是 SFP 模块型号不匹配，两边波长不一样；三是 ge-0/0/0 之前被当业务口配过地址，没有清理干净。

解决：先show interfaces terse | match ge-0/0/0确认端口没有被业务配置占用；再show interfaces diagnostics optics ge-0/0/0看光功率，RX 功率如果低于模块阈值基本就是链路物理层问题；最后把光纤两端重新对调，或者换一对相同型号的模块再做环回测试。

4.2 两台设备同时宣称自己是主节点（双主脑裂）

现象：show chassis cluster status里两个节点都显示 primary，网络侧出现同一个网关 IP 的 ARP 抖动，业务频繁断连重连。

原因：控制链路完全中断，两台设备互相收不到心跳，但业务链路还是通的。于是各自认为对方已宕机，纷纷升主，形成脑裂。

解决：立即恢复控制链路的物理连接，重点查 CSR 端口、RJ45 交叉线和交换机中间链路。恢复后高优先级节点会重新成为主，另一台自动降级。如果控制链路经常闪断，可以调小心跳间隔和阈值：

set chassis cluster heartbeat-interval 1000 set chassis cluster heartbeat-threshold 3

heartbeat-interval单位是毫秒，heartbeat-threshold表示连续丢多少个心跳判定对端失效。默认值是 1000 和 3，如果网络抖动比较大，可以把 threshold 调到 5 以上；如果追求切换速度，可以缩到 2。

4.3 重启后集群配置没生效，设备退回单机模式

现象：集群配置完成，重启后show chassis cluster status变成 Inactive，设备回到独立模式，reth 接口全部消失。

原因：最常见的是改了chassis cluster配置后没有 commit 就重启，其次是两台设备的 cluster-id 不一致，再者是异常断电导致配置没有完整落盘。

解决：重启后先show configuration chassis cluster看节点身份参数是否还在。如果 cluster-id 和 node-id 都在，只是状态不对，重新提交一次即可恢复；如果参数缺失，只能重新写入集群配置并按顺序重启。每次改完集群相关配置，一定 commit，再show | compare核对差异。

4.4 切换成功但业务黑洞几十秒，会话表像没带过来

现象：手动 failover 成功，备节点升主，但业务侧 ping 丢包几十秒，新建连接全部重连，长连接直接断。

原因：fabric 链路没有真正同步会话表，备节点升主后找不到原有会话状态；或者对端交换机没有快速收敛 ARP 表项；也有可能是 reth 对应的对端设备只看物理 port 状态，没有感知逻辑口角色切换。

解决：切换前检查show chassis cluster style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />