简介面向负责Juniper SRX防火墙高可用性设计运维的网络工程师这份PDF是一份聚焦双机热备实施的操作手册。文档从JSRP协议入手对比其与ScreenOS NSRP的异同说明JSRP将两台设备抽象为逻辑单机的集群特性以及对硬件型号、软件版本、板卡位置的严格匹配要求。配置部分按7个步骤展开设置Cluster ID和Node ID、指定Control Port、指定Fabric Link、配置Redundancy Group、完成各机箱个性化配置、配置Redundant Ethernet接口以及配置接口监控每一步都配有JUNOS命令示例和注意事项并附带控制面与数据面同步机制、互联链路建议等实践说明。此外文档还解释了冗余组RG0/RG1的用途以及接口监控作为数据面切换依据的原理。资料为单个PDF文件大小仅277KB方便快速下载与移动阅读。目前已有122人学习下载对正在规划或实施SRX双机高可用方案的技术人员具有直接参考价值。1. Juniper SRX 防火墙 HA 双机为什么 JSRP 不是主备而是一台“逻辑设备”干过生产网割接的兄弟都有过这种时刻防火墙单机跑了大半年一听说要升级 JUNOS 版本心里就打鼓——重启一下 RE整条业务链路的流量全部中断领导在群里问话你连回消息的时间都没有。所以 SRX 的 HA 双机几乎是每个机房的刚需配置而这份《JuniperSRX防火墙HA双机配置步骤.pdf》讲的就是 JSRPJuniper SRX 私有 HA 协议。它和 ScreenOS 时代的 NSRP 有本质区别JSRP 把两台物理机箱抽象成一台逻辑设备接口板卡统一编号配置与会话全部同步运维变更只操作一次即可生效。适合刚接手 SRX 防火墙、准备做 A/P 双机或已经配过但想核对细节的网络工程师。先说一个反直觉的结论JSRP 的难点不在命令而在“两台设备当作一台”的模型转换理解不了这一点后面每一步配置都会翻车。2. JSRP 的逻辑模型Cluster 抽象、双平面互联与槽位编号规则2.1 从 NSRP 到 JSRP主备复制升级成了真正的集群Juniper 的老用户对 ScreenOS 的 NSRP 应该不陌生两台防火墙各自独立运行通过协议同步配置和 session主设备挂了备设备顶上。但仔细想想NSRP 本质上是“两台独立设备加同步机制”两台机器的接口编号、路由表、会话表都是各自维护的出现脑裂时处理起来很麻烦。JSRP 完全换了思路。它把 JUNOS Cluster 的集群技术和 NSRP 的冗余理念整合到了一起两台 SRX 机箱在启用 JSRP 之后对外呈现为一台逻辑设备。这意味着接口板卡顺序重排node 0 的槽位从 0 开始编号node 1 的槽位接着往后编比如 SRX5800 单机箱 12 个业务槽位两台机箱组成的集群就有 24 个槽位node 1 的第一个槽位是 12。配置只做一次系统自动同步到另一台不需要像 NSRP 那样分别在两台设备上配置再等同步。会话表、路由表、转发引擎状态全部一致主备切换对终端用户几乎是透明的。这带来的好处很明显运维变更的复杂度从“两台设备分别操作”降为“一台逻辑设备操作”而且排错时不用再对着两台设备的配置逐行 diff。代价是 JSRP 对硬件的要求非常苛刻——两台设备在软件版本、硬件型号、板卡数量、插槽位置及端口使用方面必须严格一一对应差一块板卡都可能导致集群同步失败。2.2 控制平面与数据平面为什么要两条互联链路SRX 是控制与转发完全分离的架构RE路由引擎管控制面SPU服务处理单元管数据面。JSRP 的 HA 互联也因此分成两个独立平面控制平面互联Control Port连接两个机箱的 RE负责 jsrpd 心跳1000ms 一次threshold 为 3 次、chassisd 通信、kernel 状态同步和配置信息同步。数据平面互联Fabric Link连接两个机箱的 SPU负责 RTO 对象同步和异步路由数据的回程传输。这两个平面用同一根链路是绝对不行的。控制平面的心跳丢失会导致双机频繁切换数据平面的流量如果和控制心跳抢带宽又会引起 session 同步延迟。实操中我的习惯是控制链路和数据链路各用独立的光纤直连不经过任何交换机也不复用业务口。素材里特别强调部分平台强制要求光纤链路直连原因在于直连可以避免中间网络设备故障对 HA 链路的干扰也能保证延迟可控。这里有一个容易误判的点既然 Fabric Link 是数据平面用的那 RE 上是不是能看到它的流量答案是否定的。Fabric Link 由 SPU 直接驱动RE 不参与转发路径所以在 RE 上用 tcpdump 或 monitor traffic interface 看不到 Fabric Link 的流量。如果你在 RE 上抓包想验证 Fabric Link 通不通那是在白费力气——正确做法是看 show interfaces fab0 的状态和集群数据平面的统计。2.3 槽位抽象接口命名的变化是第一个拦路虎JSRP 启用后接口命名会发生变化。比如你原来在单机上习惯叫 ge-0/0/0集群模式下这个名字可能变成 ge-13/0/0因为 node 1 的槽位号是从 12 开始的。对于刚接触 JSRP 的人来说这往往是最容易懵的地方。以 SRX5800 为例每个机箱有 12 个业务槽位。集群启用后node 0 的槽位号 0–11node 1 的槽位号 12–23。Fabric Link 的命名也是固定的fab0 固定用于 node 0fab1 固定用于 node 1。这类命名规则没有捷径只能靠记忆和配置时的仔细核对。我的血泪经验是先把两台设备每块板卡的实际槽位列一张对照表再换算成集群后的接口名避免在配置 reth 成员时把两台设备的接口搞颠倒。3. 七步落地 A/P 双机从 Cluster ID 到 Fabric Link 的 CLI 实操3.1 第 1 步配置 Cluster ID 和 Node IDJSRP 配置的第一步就是在两台设备上分别指定集群 ID 和节点 ID。这一步必须在 operational 模式下执行而且两个节点都要配置。执行后设备会自动重启因为启用集群后每个机箱内部各业务引擎通讯用的 TNP 地址需要重新分配重启才能生效。# 在 srx5800a 上执行operational 模式 set chassis cluster cluster-id 1 node 0 reboot # 在 srx5800b 上执行operational 模式 set chassis cluster cluster-id 1 node 1 reboot这条命令的逻辑很简单cluster-id 告诉两台设备它们属于同一个集群node 0 和 node 1 区分各自的角色。注意 cluster-id 的取值范围是 1–15当设置为 0 时会解除集群配置设备回到单机状态。这个机制很实用——如果双机出了问题想临时退回到单机运行把 cluster-id 改成 0 再重启就能脱离集群但切记这会导致集群内所有配置失效操作前一定要备份配置。参数说明node 0 和 node 1 只是节点编号不代表主备角色。真正的主备由 Redundancy Group 的优先级决定这一点我后面第 4 节会展开。另外这一步重启前一定确认两台设备的版本和型号完全一致否则可能在对端报出 cluster 校验失败。3.2 第 2 步指定 Control PortSRX3000 系列的 Control Port 是固化的在 SFB 上设计有专门的接口无需指定。但 SRX5000 系列的 RE 没有专门的 Control Port需要借用 SPC 上的千兆以太网口SFP 形式来实现而且目前只支持 SPC 的 port 0。# 在配置模式下两个节点都需要配置 # 注意fpc 编号是实际硬件槽位号这里配置以现场为准 set chassis cluster control-ports fpc 11 port 0 set chassis cluster control-ports fpc 23 port 0这里有个关键提示配置完 Control Port 之后系统配置会自动在两个节点之间同步后续的配置只需要在一个节点上进行即可。这是 JSRP 和 NSRP 在操作体验上最大的差异——你不再需要在两台设备上各敲一遍同样的命令。配置时有个坑Control Port 最好不要选在 CP当前控制平面所在的 SPC 上否则这块板卡既要处理业务又要承担心跳和同步单板故障会直接影响两个机箱的控制平面通信。参数说明fpc 11 和 fpc 23 分别为两台设备上物理槽位号。为什么是 11 和 23因为集群模式下槽位编号是连续的node 0 的第一个槽位是 0node 1 的第一个槽位是 12前 24 个槽位是物理槽位的抽象。但注意这里 control-ports 命令里的 fpc 号用的是实际硬件槽位号不是集群抽象后的编号——素材里没特别说清这一点实际配的时候容易混淆。我建议配置前用 show chassis hardware 核对每个机箱的实际槽位和板卡类型确保 fpc 号没有配错。3.3 第 3 步指定 Fabric LinkFabric Link 是数据平面的互联通道用于 RTO实时对象同步和异步路由数据的回程。它和 Control Port 一样也是用 SRX 业务板卡上的以太网接口来实现的但由 SPU 直接驱动RE 不干预。配置命令如下# 在配置模式下只需在一个节点上配置配置会自动同步 set interfaces fab0 fabric-options member-interfaces ge-1/0/0 set interfaces fab1 fabric-options member-interfaces ge-13/0/0这里的 fab0 固定用于 node 0fab1 固定用于 node 1。member-interfaces 指定实际参与 Fabric Link 的物理接口一般选择业务板卡上的千兆口或万兆口。推荐用千兆以太网捆绑的方式而不是单条万兆链路因为接口捆绑不仅能提供更大的互联带宽还能在单个成员接口故障时保证 Fabric Link 的可用性。关于接口捆绑素材里有个重要信息早期 JUNOS 10.1 之前的版本SRX3000/5000 系列尚不支持 Aggregate Interface 作为 Fabric Link 的成员升级到 10.1 及以后版本才能用捆绑。如果现场用的是老版本 JUNOS建议先确认版本再决定 Fabric Link 的带宽方案别配完发现 fab0 起不来。Fabric Link 的另一个作用是处理异步路由场景。JSRP 的数据平面是 A/A主主方式运作的两台设备的 SPU 始终处于 active 状态流量到哪个 node 就由哪个 node 转发。这种情况下可能出现“入口在 node 0出口在 node 1”的异步路由路径此时数据包需要经 Fabric Link 回程所以互联带宽不足会导致跨设备转发丢包。判断这类问题的方法观察 show interfaces fab0 的进方向流量统计如果业务高峰期 fab0 入方向有大量流量说明异步路由频繁发生应该考虑扩容 Fabric Link 带宽。3.4 第 4 步配置 Redundancy GroupRedundancy GroupRG是 JSRP 的核心抽象概念类似 NSRP 里的 VSD Group用来描述“一组可以互相热备切换的对象”。RG 有几个固定编号RG0固定用于 RE 切换即控制平面的主备。RG1用于第一组冗余接口的切换。RG2 及以后如果要实现 A/A 模式需要增加 RG把不同业务接口组的切换独立出来。配置命令如下只在一个节点上配置即可# 在配置模式下 set chassis cluster reth-count 10 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 100reth-count 10 是声明集群内冗余以太网接口reth的最大数量类似链路聚合接口的编号池。这里配置了 10 个意味着最多可以创建 reth0 到 reth9。优先级 200/100 的差值决定了谁是主谁是备数值大的为主。优先级差值是抢占行为的关键默认情况下高优先级的节点会在恢复后重新抢占主角色如果不希望抢占需要显式配置 no-preempt。这里要理解一个设计点RE 切换是独立于接口切换的。RG0 负责 RERG1 负责接口两层切换可以分别发生。比如 RE 切换可能导致控制平面主备互换但数据平面的接口不一定跟着切换——这取决于流量路径和 Interface Monitoring 的结果。这个独立性是 JSRP 一个非常实用的设计但也是很多人配置时想当然的地方。3.5 第 5 步每个机箱的个性化配置集群模式下大部分配置是共享的但有些配置需要按节点区分比如主机名、带外管理口 IP。JSRP 的处理方式和 JUNOS 的 apply-groups 机制一脉相承通过定义 node0 和 node1 两个 group 来实现。# 在配置模式下示例为 srx5800a set groups node0 system host-name srx5800a set groups node0 interfaces fxp0 unit 0 family inet address 172.27.11.196/25 set groups node1 system host-name srx5800b set groups node1 interfaces fxp0 unit 0 family inet address 172.27.11.197/25 set apply-groups ${node}这个配置的核心是 ${node} 变量。JSRP 会自动为每个节点注入一个名为 node 的变量值就是当前节点的角色名node0 或 node1。apply-groups ${node} 会让设备只应用与自己角色匹配的 group 配置。拿 fxp0带外管理口来说srx5800a 只会应用 node0 组里的地址 172.27.11.196srx5800b 只应用 node1 组的地址 172.27.11.197从而避免两台设备管理 IP 冲突。这个机制的巧妙之处在于所有个性化配置都写在同一个配置库里由变量自动分发而不是在每台设备上单独维护。这也意味着在集群模式下登录任何一台设备看到的配置树都是完整的个性化配置只是按节点生效而已。3.6 第 6 步配置 Redundant Ethernet Interfacereth 接口是 JSRP 对外提供业务接入的冗余接口它利用跨机箱的 802.3ad 链路聚合技术把两个节点上的物理接口聚合成一个虚拟接口。配置时先定义聚合接口和成员接口再把它绑定到指定的冗余组。# 在配置模式下 set interfaces reth0 vlan-id 1 set interfaces reth0 unit 0 family inet address 192.168.10.1/24 set interfaces ge-0/0/0 gigether-options redundant-parent reth0 set interfaces ge-13/0/0 gigether-options redundant-parent reth0 set interfaces reth0 redundancy-group 1这段配置的逻辑是创建 reth0 作为三层冗余接口IP 为 192.168.10.1/24把 node 0 的 ge-0/0/0 和 node 1 的 ge-13/0/0 都指定为 reth0 的成员最后把 reth0 绑定到 redundancy-group 1。这样 RG1 的主节点会激活自己的成员接口进行转发备节点的成员接口处于 standby 状态实现了跨机箱的接口级主备。reth 接口的虚拟 MAC 地址有固定格式。素材里给的计算公式是 00 10 DB 11 11 11 CCCC RR VV其中 CCCC 是 Cluster IDRR 是冗余组相关参数VV 与 NSR/ISSU 状态相关。这个 MAC 是两台设备共享的目的就是让上游交换机看到的 MAC 始终不变切换对二层网络透明。除非需要做 MAC 层面的排错否则这个公式不必手工逐个字节算知道它是虚拟 MAC、切换后不变化就够了。3.7 第 7 步配置 Interface Monitoring最后一步是配置接口监控。RG 数据层面的切换依据就是 Interface Monitoring当被监控的物理接口 down 掉时RG 会判定当前节点数据面不可用触发切换。# 在配置模式下 set chassis cluster interface-monitor ge-0/0/0 weight 255 set chassis cluster interface-monitor ge-13/0/0 weight 255监控的对象是 reth0 的两个物理成员接口权重 255 表示该接口故障时对 RG 可用性的影响程度。RG 的 failover 判定逻辑是被监控接口的累计权重达到阈值默认是 255时RG 判定当前节点失败备节点接管。如果只监控一个接口那 weight 255 就是这个接口的开关如果监控多个接口可以按接口重要性分配权重比如重要接口给 200次要接口给 100全部故障累计超过 255 才切换。这一步是很多人容易漏的只配了 RG 优先级和 reth 接口没有配 interface-monitor结果主节点的业务口被拔出后RG 仍然认为节点健康业务完全中断。实际切换的依据不是接口本身 down 掉而是监控机制发现接口 down 并上报给 RG 层。4. Redundancy Group 与 reth 的切换机制优先级、抢占与监控对象配置4.1 RG0、RG1 与 RG2控制面、数据面与 A/A 模式的分工前面配置里已经出现过 RG0 和 RG1这里把它们的运行机制讲透。RG0 永远服务 RE 切换两台设备的控制平面一主一备备 RE 的 jsrpd 不断接收主 RE 的心跳和配置同步。RG1 服务 reth 接口组的切换主节点的成员接口转发流量备节点成员接口 standby。A/A 模式怎么做核心是增加 RG。假设你有两段业务一段走 reth0一段走 reth1把 reth0 放进 RG1node 0 优先级 200node 1 优先级 100把 reth1 放进 RG2node 0 优先级 100node 1 优先级 200这样 node 0 是 RG1 的主、RG2 的备node 1 是 RG2 的主、RG1 的备两个节点各扛一部分流量实现了数据面 A/A。RG0 仍然是独立的主备通常跟 RG1 的主节点保持一致即可。这个设计的价值在于接口级切换不绑定 RE 切换。RE 主备互换不代表所有 reth 接口都要跟着动每个 RG 独立计算主备。实际项目里我一般建议控制面主节点和数据面主节点保持一致减少跨节点路径但遇到极端场景时可以靠这种独立性把故障域缩小到单个 RG。4.2 优先级与抢占切换行为由数值差决定RG 切换的决策依据是节点优先级和监控权重。每个 RG 里 node 0 和 node 1 都有自己的 priority 值数值大的为主。当主节点被监控的接口故障累计权重达到阈值时RG 判定主节点失能备节点自动接管即使备节点优先级较低也不影响这次切换——故障优先级高于静态优先级。等主节点恢复后是否抢回角色取决于 preempt 配置。JUNOS 里 RG 默认是允许抢占的即恢复了就抢回主角色。激进抢回对业务的影响很大接口 MAC 在二层网络中迁移需要时间频繁抢占可能导致瞬间丢包。我的习惯是默认开启抢占但在业务窗口内做切换演练时关闭抢占等确认业务稳定后再改回来。配置抢占的命令如下set chassis cluster redundancy-group 1 preempt注意 preempt 是 RG 级别配置不是节点级别。每个 RG 都可以独立设置是否抢占。A/A 场景下如果 RG1 和 RG2 都开启抢占任何一侧恢复都会触发一次接口 MAC 迁移网络抖动会被放大。建议生产环境里把非核心 RG 的抢占关闭减少无谓的切换。4.3 reth 的虚拟 MAC 与二层透明性reth 接口的核心价值是二层透明无论哪台节点转发流量reth 的虚拟 MAC 始终不变。公式 00 10 DB 11 11 11 CCCC RR VV 里CCCC 位与 cluster-id 有关RR 位与冗余组相关VV 位标记 NSR/ISSU 状态。同一集群内不同 RG 的 reth 接口MAC 也各不相同RR 位就是为了区分 RG 而设计的。实际排错中需要注意如果上游交换机始终学到的是同一个 MAC说明 reth 切换正常如果看到 MAC 在两个物理接口之间跳动大概率是两台设备的 reth 配置不一致或 RG 状态不稳定。这个检查手段比看 show chassis cluster status 更直观因为 MAC 学习反映的是数据面的实际转发状态。配置 reth 时有个隐藏细节reth 成员接口不能直接配置 IP所有三层配置都在 reth 接口上完成成员物理接口只做 redundant-parent 绑定。如果你习惯性地在 ge-0/0/0 上配了 IPredundant-parent 绑定会失败接口会保持普通物理接口状态。这是 JUNOS 一个很容易踩的配置陷阱。4.4 Interface Monitoring 的正确用法Interface Monitoring 是 RG 数据面切换的依据但很多人的理解停留在“监控接口 down 了就切换”。实际机制是每个被监控接口带一个 weight 值RG 内累计故障权重达到阈值才触发切换。默认阈值是 255所以常见配置里单个监控接口 weight 255 就是“一票否决”多个接口时按权重累计。set chassis cluster interface-monitor ge-0/0/0 weight 255 set chassis cluster interface-monitor ge-13/0/0 weight 255监控对象的选择有讲究。你监控的应该是 reth 的成员接口而不是 reth 本身——reth 是虚拟接口它的状态是 RG 计算结果不能作为自身的监控依据。另外不要把带外管理口 fxp0 加进监控列表否则管理链路抖动会触发业务切换影响面比你预期的要大得多。一个常被忽略的组合用法Interface Monitoring 与 RG 优先级的联动。当节点恢复到健康状态后RG 切换回主节点的条件是“优先级高 故障权重归零”。如果故障接口恢复但 RB 状态还没有同步完可能出现“抢回但接口未就绪”的中间态。稳妥做法是在演练前先查看 show chassis cluster interfaces 确认每个 reth 的成员接口都处于 active/standby 的正常状态再触发切换。5. JSRP 双机避坑实录五条常见故障的现象、原因与修复5.1 配置 cluster-id 重启后设备依然是单机现象执行完 set chassis cluster cluster-id 1 node 0 reboot设备正常重启但 show chassis cluster status 显示 cluster 状态为 disabled两台设备互相看不到对端。原因最常见的是两台设备配置的 cluster-id 不一致。比如 node 0 配的是 1node 1 配的是 2两台设备虽然都在集群模式下但集群编号不同无法组成一个集群。其次是命令在 EEPROM 写入前被中断比如误操作取消了 reboot导致 cluster 信息没有落盘。解决两台设备分别执行 show chassis cluster status 核对 cluster-id 和 node-id如果不一致把错误的那台重新执行 set chassis cluster cluster-id X node Y reboot。经验是每次配置这种持久化参数后都等设备完整重启、进入多用户模式后再进行下一步别抢时间。5.2 Control Port 配置后SPC 反复重启现象在 SRX5800 上配置 control-ports 后对应 fpc 上的 SPC 板卡反复重启RE 日志刷 jsrpd 相关错误。原因Control Port 选错了接口。SRX5000 只能使用 SPC 的 port 0如果把控制端口选到了 port 1 或更高的端口SPC 无法识别这个端口作为控制口持续报错并重启恢复。另一个原因是 Control Port 选在了当前 CP 所在的 SPC 上这块板既要处理控制流量又要承担业务转发负载异常触发保护机制重启。解决用 set chassis cluster control-ports fpc X port 0 重新指定确保每台 SPC 只用 port 0并把选中的 SPC 与承载 CP 的板卡分开。如果已经选错且设备进入异常状态先删除 control-ports 配置等板卡稳定后再重配。5.3 Fabric Link 起不来fab0 一直是 down现象配置完 Fabric Link 成员接口后show interfaces fab0 状态长时间 downshow chassis cluster>show chassis cluster status show chassis cluster interfaces show chassis cluster statistics第一条看 RG 状态重点是每个 RG 的 state 是否为 primary/backup 且节点分布正确。第二条看 reth 成员接口的角色active 和 standby 是否符合预期。第三条看会话同步的统计重点关注 sync errors 和 fabric link 的收发计数。如果 sync errors 持续增长说明 session 同步异常这种状态下切换必然丢会话。动态演练我一般按这个顺序做在主节点上 shutdown reth0 的一个成员接口例如 ge-0/0/0。观察 RG 是否在 1 秒内切换备节点的 ge-13/0/0 是否从 standby 变为 active。恢复 ge-0/0/0观察抢占是否按预期发生如果没开 preempt则不切换。在主节点上直接重启 RE模拟控制面故障。观察 RG0 是否切换业务接口是否跟着切换。拔掉主节点 Fabric Link 光缆模拟数据面互联中断。观察集群如何应对——Fabric Link 断了不会触发 RG 切换但会导致 session 同步失败和异步路由丢包这条是为了验证告警链路是否覆盖了 Fabric Link 故障。演练中我会同时在业务侧打流量用 ping 或 iperf 观察切换期间的丢包窗口。正常情况下 A/P 切换的丢包在秒级以内主要损耗在 ARP 收敛和 MAC 迁移。如果丢包超过 3 秒优先检查上游交换机的 MAC 学习和 STP 收敛而不一定是防火墙自身的问题。这套验证流程走过一遍双机配置才算真正落地。从那以后我每次做完 HA 变更都强制先做一次切换演练再收工哪怕只是加了一条监控接口策略也把切换窗口压到 30 秒以内确认无误。这种“嫌麻烦”的习惯救过我很多次生产事故。希望帮到你。本文还有配套的精品资源点击获取