简介面向网络工程师与安全运维人员的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走的是另一条路JSRPJuniper SRX Protocol直接把两台物理机箱抽象成一个逻辑机箱接口统一编号、配置自动同步、Session状态实时复制运维视角里基本不存在“两台设备”。这意味着你不需要像ScreenOS NSRP那样手工同步配置和会话但代价也摆在这——硬件型号、板卡数量、插槽位置、端口使用必须严格一一对应差一块板卡集群都起不来。这份配置步骤文档覆盖了从Cluster ID到Interface Monitoring的完整7步适合正在做SRX双机开局、或者从NSRP迁移到JSRP的同行。下面按我实际开局的顺序把每一步的命令、参数边界和坑位拆开讲。2. 开局先重启Cluster ID与Node ID的配置逻辑2.1 为什么Cluster ID必须写进EEPROMJSRP启用后两台机箱会被抽象成一台逻辑机箱这里面有个容易被忽略的底层细节Cluster ID和Node ID不是存在配置文件里而是写入EEPROM。为什么偏偏要放EEPROM因为组成集群后每台机箱内部各个业务引擎通讯用的TNPTrivial 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 1cluster-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就是连接两台机箱RERouting 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有一个血泪经验尽量不要选在CPControl Point所在的SPC上。CP是SRX5K上的控制面管理实体如果Control Port和CP在同一块卡上这块卡一挂控制链路和数据面管理一起断整个集群瞬间脑裂。我在生产环境见过一次SPC硬件故障后两台设备同时认为自己是master流量被黑洞了将近两分钟。从那以后我配置Control Port都会刻意避开CP所在槽位。注意配置完Control Port后系统配置会自动在两个node之间同步。从这一步起后面的配置只需在一个节点上完成不要两台上各配一遍。3.2 Fabric Link数据平面的Session同步与异步路由回程Fabric Link是虚拟的交换平面作用是把两台SRX机箱的数据平面连在一起。它主要干两件事RTOReal-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固定用于node0fab1固定用于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 GroupRG0、RG1、RG2的角色分工Redundancy GroupRG类似ScreenOS NSRP里的VSDVirtual 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属于RG1ge-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 MonitoringRG切换的数据面依据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 255weight 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都是onlineRG0和RG1的master都在期望的节点上。第二步看reth接口状态srx5800a show interfaces reth0 tersemaster节点的reth0成员接口应该是upbackup节点的成员接口是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双机不管客户多急都强制走一遍这套验证流程。双机的高可用性是配出来的但可靠性是切出来、练出来的。希望帮到你。本文还有配套的精品资源点击获取 JSRP双机热备深度解析：从集群原理到SRX切换排错
简介面向网络工程师与安全运维人员的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走的是另一条路JSRPJuniper SRX Protocol直接把两台物理机箱抽象成一个逻辑机箱接口统一编号、配置自动同步、Session状态实时复制运维视角里基本不存在“两台设备”。这意味着你不需要像ScreenOS NSRP那样手工同步配置和会话但代价也摆在这——硬件型号、板卡数量、插槽位置、端口使用必须严格一一对应差一块板卡集群都起不来。这份配置步骤文档覆盖了从Cluster ID到Interface Monitoring的完整7步适合正在做SRX双机开局、或者从NSRP迁移到JSRP的同行。下面按我实际开局的顺序把每一步的命令、参数边界和坑位拆开讲。2. 开局先重启Cluster ID与Node ID的配置逻辑2.1 为什么Cluster ID必须写进EEPROMJSRP启用后两台机箱会被抽象成一台逻辑机箱这里面有个容易被忽略的底层细节Cluster ID和Node ID不是存在配置文件里而是写入EEPROM。为什么偏偏要放EEPROM因为组成集群后每台机箱内部各个业务引擎通讯用的TNPTrivial 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 1cluster-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就是连接两台机箱RERouting 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有一个血泪经验尽量不要选在CPControl Point所在的SPC上。CP是SRX5K上的控制面管理实体如果Control Port和CP在同一块卡上这块卡一挂控制链路和数据面管理一起断整个集群瞬间脑裂。我在生产环境见过一次SPC硬件故障后两台设备同时认为自己是master流量被黑洞了将近两分钟。从那以后我配置Control Port都会刻意避开CP所在槽位。注意配置完Control Port后系统配置会自动在两个node之间同步。从这一步起后面的配置只需在一个节点上完成不要两台上各配一遍。3.2 Fabric Link数据平面的Session同步与异步路由回程Fabric Link是虚拟的交换平面作用是把两台SRX机箱的数据平面连在一起。它主要干两件事RTOReal-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固定用于node0fab1固定用于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 GroupRG0、RG1、RG2的角色分工Redundancy GroupRG类似ScreenOS NSRP里的VSDVirtual 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属于RG1ge-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 MonitoringRG切换的数据面依据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 255weight 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都是onlineRG0和RG1的master都在期望的节点上。第二步看reth接口状态srx5800a show interfaces reth0 tersemaster节点的reth0成员接口应该是upbackup节点的成员接口是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双机不管客户多急都强制走一遍这套验证流程。双机的高可用性是配出来的但可靠性是切出来、练出来的。希望帮到你。本文还有配套的精品资源点击获取