企业官网建设流程全解析

简介：面向网络工程师与安全运维人员的Juniper SRX防火墙HA双机配置PDF文档，系统讲解基于JSRP协议的双机热备部署方案，帮助读者理解A/P、A/A模式以及JSRP与NSRP的差异，并掌握从Cluster配置到接口监控的完整流程。资源仅含1个PDF文件，大小277KB，内容紧凑、步骤清晰，可直接用于生产环境配置参考或学习研究。目前已有120人学习下载。文档以配置步骤为主线，依次覆盖Cluster ID与Node ID设置、Control Port与Fabric Link指定、Redundancy Group配置、机箱个性化配置、Redundant Ethernet接口及Interface Monitoring等内容，还针对SRX5K与SRX3K的平台差异给出适用性说明和注意事项，并提供了具体配置命令样例。读者按文档顺序操作即可完成双机集群搭建，也可将其作为日常排错和运维的速查手册，适合有一定JUNOS基础的中高级工程师参考。

1. JSRP双机热备：把两台SRX“焊”成一台的逻辑设备

做防火墙HA，很多人第一反应是VRRP加配置同步脚本，但Juniper SRX走的是另一条路：JSRP（Juniper SRX Protocol）直接把两台物理机箱抽象成一个逻辑机箱，接口统一编号、配置自动同步、Session状态实时复制，运维视角里基本不存在“两台设备”。这意味着你不需要像ScreenOS NSRP那样手工同步配置和会话，但代价也摆在这——硬件型号、板卡数量、插槽位置、端口使用必须严格一一对应，差一块板卡集群都起不来。这份配置步骤文档覆盖了从Cluster ID到Interface Monitoring的完整7步，适合正在做SRX双机开局、或者从NSRP迁移到JSRP的同行。下面按我实际开局的顺序，把每一步的命令、参数边界和坑位拆开讲。

2. 开局先重启：Cluster ID与Node ID的配置逻辑

2.1 为什么Cluster ID必须写进EEPROM

JSRP启用后，两台机箱会被抽象成一台逻辑机箱，这里面有个容易被忽略的底层细节：Cluster ID和Node ID不是存在配置文件里，而是写入EEPROM。为什么偏偏要放EEPROM？因为组成集群后，每台机箱内部各个业务引擎通讯用的TNP（Trivial Network Protocol）地址要重新分配，这个重分配发生在系统启动早期，文件系统还没挂载，只有EEPROM里的信息能在这个阶段被引导代码读到。

所以配置完这一步必须重启，这不是Junos故意折腾人，是硬件寻址的硬约束。Cluster ID取值范围是1到15，当Cluster ID为0时等于把集群配置unset掉，设备退回单机模式。这个值在整个网络里最好全局唯一，后面reth接口的虚拟MAC地址会按Cluster ID计算，两台不同集群的设备如果Cluster ID撞了，二层广播域里会出现相同的虚拟MAC，交换机MAC表直接抖动。

2.2 配置命令与容易被忽略的参数细节

配置命令本身不复杂，但有一个细节我每次都要提醒自己：这一步要在operational模式下输入，不是进configure模式。命令长这样：

srx5800a> set chassis cluster cluster-id 1 node 0 reboot srx5800b> set chassis cluster cluster-id 1 node 1 reboot

两个节点都要配，第一台写node 0，第二台写node 1，cluster-id必须保持一致。命令末尾的reboot表示配完立即重启，如果不带这个参数，Junos也会提示需要手动重启才生效。我第一次开局图省事没带reboot，结果在设备前等了十分钟看集群状态一直起不来，翻回来一查设备压根没重启，TNP地址还是单机模式的，等于白等。

配置完重启之后，集群信息会固化到每台设备的EEPROM里。以后想改cluster-id，先把集群拆了，改完再重新组，别指望在线改。

2.3 重启后先看什么：集群状态确认

重启完成后不要急着配Control Port，先确认集群基础状态。我一般直接敲：

srx5800a> show chassis cluster status

正常输出里能看到Cluster ID、两个node的在线状态，以及RG0的master归属。如果只看到一个node在线，典型原因是两台设备的cluster-id不一致，或者node id配重了。我见过最快的一次翻车，是两台设备都配了node 0，第二台起来后集群直接报node id冲突，双双陷入反复重启的循环。

这个命令在后面的排错里会反复用到，建议开局时就把输出存一份留底，后续做变更时能对比基线。

2.4 JSRP与NSRP的本质差异：不是“两台”，是“一台”

这一步对从ScreenOS NSRP迁移过来的老手尤其重要。NSRP的模型是两台独立设备在配置和session同步的基础上各自运行，配置同步靠协议去“搬运”。JSRP是完全意义上的Cluster概念，两台设备被当成一台逻辑设备看待，接口板卡顺序编号、运维变更同时落到两台设备，不需要额外做配置同步和会话同步。

这个差异带来的实际后果是：JSRP对硬件一致性要求苛刻得多。软件版本、硬件型号、板卡数量、插槽位置、端口使用必须严格一一对应。版本差一个patch级别，集群可能起得来，但某些板卡会被标记为不兼容；板卡槽位不对应，reth接口的逻辑成员会找不到对端。做方案评审时，我会先把两台设备的show version和show chassis hardware输出拉出来逐项对比，确认一致再往下走。

3. 两个互联平面：Control Port与Fabric Link的分工与选型

3.1 Control Port：控制平面的心跳与配置同步通道

JSRP中两个机箱的控制平面以A/P方式运作，Control Port就是连接两台机箱RE（Routing Engine）的专用通道。这个口上跑的流量很杂：jsrpd心跳报文（默认1000ms一次，threshold为3次）、chassisd通信、kernel的ifstate状态同步，以及配置信息同步。

因为Control Port流量直接到达RE，排错时可以非常直观地抓包看心跳。SRX5K上我一般用：

srx5800a> monitor traffic interface ge-11/0/0

抓包能看到周期性的jsrpd心跳报文。如果心跳时断时续、乱序，Control Port物理链路质量大概率有问题；如果完全看不到，检查接口配置和光纤。

这里要说明SRX5K和SRX3K的差异。SRX3K的Control Port做在SFB板上，通过内部总线直连RE，出厂就固化了，不需要也不能配置。SRX5K的RE没有专门的控制口，需要借用SPC上的千兆以太网口（SFP形式）充当。由于LAG Feature限制，SRX5K目前只支持SPC的port 0作为Control Port，配置命令如下：

set chassis cluster control-ports fpc 11 port 0 set chassis cluster control-ports fpc 23 port 0

参数说明：fpc 11是node0机箱上的SPC槽位，fpc 23是node1机箱上对应的SPC槽位。这里用到了JSRP的槽位编号规则——node0槽位从0开始，node1槽位从12开始（SRX5800每个机箱12个业务槽位），所以fpc 23实际是node1机箱上的第11号槽，对应物理位置。

关于Control Port选哪块SPC，有一个血泪经验：尽量不要选在CP（Control Point）所在的SPC上。CP是SRX5K上的控制面管理实体，如果Control Port和CP在同一块卡上，这块卡一挂，控制链路和数据面管理一起断，整个集群瞬间脑裂。我在生产环境见过一次，SPC硬件故障后两台设备同时认为自己是master，流量被黑洞了将近两分钟。从那以后我配置Control Port都会刻意避开CP所在槽位。

注意：配置完Control Port后，系统配置会自动在两个node之间同步。从这一步起，后面的配置只需在一个节点上完成，不要两台上各配一遍。

3.2 Fabric Link：数据平面的Session同步与异步路由回程

Fabric Link是虚拟的交换平面，作用是把两台SRX机箱的数据平面连在一起。它主要干两件事：RTO（Real-time Object）同步，以及异步路由场景下的数据回程。

这里有个非常容易踩的认知误区：JSRP中两个机箱的数据平面是A/A模式运作的，也就是说不管控制平面谁是master，数据平面的SPU/NPU始终是Active状态，只要有流量经过就转发。这和VRRP那种“主设备转发、备设备standby”的模型完全不同。所以在异步路由场景下，流量从A机箱进、从B机箱出，出方向的流量全部要经过Fabric Link回程，带宽规划一旦做小了，瓶颈会非常明显。

Fabric Link基于SRX业务板卡的以太网接口实现，由SPU直接驱动，不需要RE参与转发。这意味着在RE上用monitor traffic interface是看不到Fabric Link流量的，别在这个上面浪费时间。确认状态要看fab接口本身：

srx5800a> show interfaces fab0 terse srx5800a> show interfaces fab1 terse

配置命令：

set interfaces fab0 fabric-options member-interfaces ge-1/0/0 set interfaces fab1 fabric-options member-interfaces ge-13/0/0

注意fab0固定用于node0，fab1固定用于node1。ge-1/0/0是node0上的接口，ge-13/0/0是node1上对应的接口，两台设备的Fabric Link物理接口应该直连。

接口捆绑方面，SRX 3K/5K在JUNOS 10.1之前不支持Aggregate Interface作为Fabric Link，只能单条口硬扛。10.1之后开始支持，建议优先用捆绑方式，原因有两个：带宽翻倍，且其中一条物理链路故障时Fabric Link不会断。配置示例：

set interfaces fab0 fabric-options member-interfaces ae0 set interfaces ae0 aggregated-ether-options lacp active

用捆绑接口时，两台设备都要把对应物理口加进ae0，并且LACP模式保持一致，否则捆绑组起不来。

3.3 判断链路可靠性的三个习惯

先说结论：Control Port和Fabric Link都用光纤直连，不经过中间交换机。Control Port本质是IP可达就能工作，但经过交换机意味着引入额外故障点——交换机端口down、VLAN配置错误、生成树阻塞，任何一个问题都能让双机集群在关键时刻掉链子。Fabric Link如果条件允许，优先用万兆口或千兆捆绑。我见过一个客户，出口流量才300Mbps，但Fabric Link跑满了千兆，因为流量分布不均衡，入向全在A机箱、出向全在B机箱，所有出向流量都要走Fabric Link回程，单口千兆根本扛不住。

另外，观察Fabric Link流量有个技巧。虽然RE上看不到详细报文，但可以通过接口计数器判断同步流量趋势：

srx5800a> show interfaces fab0 statistics

如果同步流量长时间为0，而业务有真实session在跑，基本可以断定Fabric Link配置有问题，session只在本机生效，切换必断。

4. RG与reth：切换策略和冗余接口怎么落地

4.1 Redundancy Group：RG0、RG1、RG2的角色分工

Redundancy Group（RG）类似ScreenOS NSRP里的VSD（Virtual Security Device），用来抽象两台机箱之间可以互相热备切换的一组对象。RG不是随便定义的，Juniper对它做了固定分工：RG0固定用于RE切换，RG1用于一组redundant interface的切换，如果要做A/A模式，还需要RG2。

这个分工背后的逻辑值得说透：RE切换和接口切换是解耦的。RG0的master决定控制平面归谁管，RG1的master决定reth接口数据面归谁转发。所以可能出现控制平面在node0、业务接口active在node1的“交叉”状态，这在JSRP里是合法的。

配置命令：

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 100

参数说明：reth-count是redundant ethernet接口数量，类似ae接口的count限制，可以大于实际用到的reth数，多出来的留作扩容。priority是节点优先级，越大越优先成为master。生产环境我一般给主节点200、备节点100，留出足够的优先级差。两个节点priority不要配成一样，否则节点间心跳抖动时没人能裁决谁是master。

生产环境我一般会把抢占关掉，避免故障恢复后频繁切换。切换是有代价的，session要重新同步、接口要重新收敛，不需要因为一次闪断就来回倒换：

set chassis cluster redundancy-group 1 no-preempt

配有这个命令后，只要当前master不故障，备节点priority再高也不会主动抢回角色。需要做计划内切换时手工执行failover命令即可。

4.2 reth接口：跨机箱的虚拟以太网与MAC计算

Redundant Ethernet接口是一组主备以太网接口，实现上利用了跨机箱的802.3ad link aggregate技术。跟普通ae接口的区别在于，reth的两个成员物理上分别位于两台机箱，逻辑上归属同一个冗余组。

reth接口的MAC地址是虚拟的，按如下公式计算：

MAC = 0010DB 111111 CCCC RR VV

其中CCCC是Cluster ID的十六进制表示，RR和VV是NSR/ISSU相关标记。所以同一个二层网络里，不同集群的Cluster ID必须唯一，否则两台集群设备的reth虚拟MAC会撞车，交换机MAC表来回抖动，流量转发随缘。

配置reth接口时，先定义冗余组归属，再加物理成员：

set interfaces reth0 redundant-ether-options redundancy-group 1 set interfaces reth0 unit 0 family inet address 192.168.1.1/24 set interfaces ge-1/0/1 gigether-options redundant-parent reth0 set interfaces ge-13/0/1 gigether-options redundant-parent reth0

参数说明：redundancy-group 1表示reth0属于RG1；ge-1/0/1是node0上的物理接口，ge-13/0/1是node1上对应的物理接口，两个接口都挂到reth0下。配置同步后，只有master节点的reth成员接口转发流量，备节点的成员接口处于down状态。

提示：reth成员接口的物理槽位在集群建立后不要随意更换。JSRP要求两台设备板卡数量、插槽位置、端口使用严格对应，换槽位后reth成员可能找不到对端，接口组直接异常。

4.3 个性化配置与apply-groups模板

JSRP两台设备大部分配置共享，但主机名、带外管理口IP这类“每台设备自己的配置”不能同步。Junos的做法是group模板加apply-groups，逻辑上跟JUNOS RE redundancy的group用法一致。

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自动注入的，node0设备自动应用node0组，node1设备自动应用node1组。apply-groups后面必须带双引号，让变量在提交时展开。我见过有人把node0和node1的配置都写进groups，但忘了写apply-groups，结果两台设备都没拿到个性化配置，主机名还是默认的，带外地址也没配上，管理上直接裸奔。

groups模板里还能放每台设备独有的路由、策略，只要逻辑上是“单机属性”，就放groups而不是全局配置。全局配置会被同步到对端，如果把node0的管理路由写进全局，node1的FIB里也会多一条无关路由，不影响业务，但排错时看着非常迷惑。

4.4 Interface Monitoring：RG切换的数据面依据

RG定义了优先级关系，但真正触发RG切换的是Interface Monitoring。它监控reth成员对应的物理接口状态，把down状态映射为RG内的weight扣分，当priority被扣到低于对端时，master角色完成切换。

set chassis cluster redundancy-group 1 interface-monitor ge-1/0/1 weight 255 set chassis cluster redundancy-group 1 interface-monitor ge-13/0/1 weight 255

weight 255的含义是：这个接口down掉，直接把该节点在RG1的priority扣光，立即让出master。如果某些接口故障不需要立即切换，可以把weight调小，比如50，让它只影响部分优先级。但注意weight调太小可能导致该切的不切，业务断了半小时没人发现。我这边核心业务口的weight统一给255，非核心链路给100左右。

5. 避坑与排查：JSRP配置的四个典型翻车现场

5.1 集群起不来：Cluster ID配置后两个节点反复重启

现象：配置完cluster-id node后reboot，两台设备反复重启，show chassis cluster status一直显示集群未建立。

原因：最常见的是两台的cluster-id不一致，或者node id重复——比如两台都配了node 0。另一种隐藏原因是两台设备软件版本不一致，JSRP对版本差异容忍度极低，差一个patch都可能出问题。

解决：登录每台设备确认cluster-id和node id，确保cluster-id一致且node id一个是0一个是1。用show version对比软件版本，不一致先升级到相同版本。另外确认是不是同型号设备，SRX5800和SRX5800能配，SRX5800和SRX5400槽位数不一样，逻辑机箱编号对不上，集群起不来是必然的。

5.2 配置同步失败：Control Port选错了SPC卡

现象：配置完control-ports后，两台设备配置没有自动同步，在node1上手工配的配置在node0上看不到。

原因：Control Port链路不通。要么光纤没插对端口，要么Control Port所在的SPC卡没起来。还有一种隐蔽原因：Control Port选在了CP所在的SPC上，CP异常导致控制链路不稳定，jsrpd心跳时断时续。

解决：先确认Control Port链路状态，在node0上ping node1的控制面地址。ping不通就检查光纤、检查SPC状态，用show chassis environment fpc确认板卡是否在线。如果Control Port恰好配在CP所在的SPC上，改到其他SPC的port 0，这个不强制但强烈建议。

5.3 Session不同步：Fabric Link接反的典型症状

现象：集群状态正常，两个node都是online，但A/B切换后已建立的TCP会话全部断开，新建连接偶尔也失败。

原因：最典型的物理层问题是fab0和fab1接反。node0的fab0必须对node1的fab1，光纤插错口时物理链路照样up，但数据平面同步逻辑完全错乱，RTO报文发到了错误的对端。

解决：用show interfaces fab0 terse和fab1 terse确认接口状态，然后回到物理层重新核对跳线。这里的“对端”指实际光纤连接，不是看接口名称，要顺着物理拓扑查。插反的情况下接口up，但同步数据发不到正确对端，现象非常迷惑，不仔细查物理连接根本发现不了。

5.4 切换后丢流量：Interface Monitoring权重没配

现象：主节点断电后，备节点接管了master角色，但业务流量大量丢失，网关ping不通。

原因：控制平面RG0切换了，但数据平面的reth接口没有跟随切换——因为RG1的interface-monitoring没配或者weight不对。RG0和RG1的切换是独立事件，RE切过来不代表reth成员接口也切过来，备节点的reth成员接口还是down状态，流量物理上过不去。

解决：确认reth接口和RG的绑定关系，把关键业务接口全部加入interface-monitoring并设置足够大的weight。然后主动做一次切换测试，验证reth成员接口的链路状态是否跟随RG切换。我有一次做完配置没做切换测试，三个月后真出故障才发现reth根本没绑定成功。双机配置不上演练等于没配，这句话是真金白银买来的。

6. 验证双机切换：show命令与故障演练清单

配置完JSRP，最重要的一件事是验证，而且是主动制造故障去验证。下面是我每做完一套双机必走的验证流程。

第一步，看集群整体状态：

srx5800a> show chassis cluster status

确认两个node都是online，RG0和RG1的master都在期望的节点上。

第二步，看reth接口状态：

srx5800a> show interfaces reth0 terse

master节点的reth0成员接口应该是up，backup节点的成员接口是down。如果两边都是up，说明reth没有正确跟随RG状态，先回去查redundancy-group配置。

第三步，做一次手动切换：

srx5800a> request chassis cluster failover redundancy-group 1 node 1

这个命令把RG1的master角色强制切到node1。切换后确认业务流量是否无损，再看reth0状态是否跟着翻转。如果流量中断超过几个包，回头查session同步和Fabric Link配置。

第四步，把RG0也切一次：

srx5800a> request chassis cluster failover redundancy-group 0 node 1

这一步验证控制平面切换，确认配置同步和jsrpd心跳在切换后正常。切换完记得切回来，让业务回到规划的主节点。从那以后，我每做完一套SRX双机，不管客户多急，都强制走一遍这套验证流程。双机的高可用性是配出来的，但可靠性是切出来、练出来的。希望帮到你。

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