SR6608设备堆叠分裂模拟，发现设备无响应

当前固件版本 SR6600-CMW710-SYSTEM-R7809P24-RPEX5.bin

1. 问题概述

1.1 故障现象

在模拟核心路由堆叠节点故障的应急演练中，发现以下异常：

• 测试场景一（异常）：

  1. 断开一号路由设备R1与一号防火墙FW1之间的业务链路。

  2. 模拟二号路由设备R2故障（断开堆叠线）。

  3. 结果：R1设备失控，Console口无响应，业务完全中断。

• 测试场景二（正常）：

  1. 保持R1与FW1之间的业务链路连通。

  2. 模拟R2故障（断开堆叠线）。

  3. 结果：R2设备离线，R1设备工作正常，符合预期。

1.2 核心疑问

根据网络设计原理，单纯的业务链路断开和堆叠分裂，不应导致设备控制平面（Console）无响应。此现象表明系统存在超出常规逻辑的深层问题。

2. 网络拓扑与关键配置

2.1 物理拓扑

网络为“日”字形冗余拓扑，如下图所示：

2.2 关键配置

• 堆叠： R1与R2组成IRF堆叠。

• 多主检测： 配置MAD-BFD，使用独立的物理专线。

• 路由协议：

  • 三条互联网业务线路：

    1. 线路1： OSPF协议（外部单线）

    2. 线路2： 静态路由

    3. 线路3： 静态路由

  • 一条内部互联链路：

    • R1与FW1之间也运行OSPF协议。

3. 故障根因分析

经过逐步的排查与信息补充，故障根因最终被锁定为一个与OSPF协议状态和堆叠分裂机制交互相关的设备操作系统Bug。

3.1 故障链条精确还原

1. 初始操作：断开R1→FW1的OSPF内部链路。

   • 后果：该链路上的OSPF邻居关系状态变为 Down。OSPF进程进行了一次拓扑收敛。

2. 触发操作：断开堆叠链路，模拟R2故障。

   • 后果：MAD-BFD检测到堆叠分裂，通知系统各模块（包括OSPF进程）进入分裂处理流程。

3. Bug触发：

   • OSPF进程在处理堆叠分裂这个复杂事件时，需要遍历并处理所有OSPF接口的状态。

   • 当它处理到那个处于 Down 状态的OSPF接口（R1-FW1）时，在堆叠分裂的特殊语境下，一段有缺陷的代码路径被触发。

   • 这段有问题的代码可能导致：

     • 内存访问违规（如空指针解引用）

     • 进程死循环，耗尽CPU资源

     • 内核态恐慌，导致系统崩溃

4. 系统崩溃：OSPF进程的异常直接拖垮了设备的主控板管理平面，导致整个系统无响应，表现为Console死机。

3.2 为什么场景二正常？

在测试场景二中，R1→FW1的OSPF链路保持连通，其邻居关系处于 Full 状态。

• 当堆叠分裂发生时，OSPF进程遍历到该接口，执行的是另一段稳定、正常的代码路径来处理分裂。

• 因此，系统成功度过了堆叠分裂事件，R1作为独立主设备继续正常运行。

3.3 结论

这是一个在特定边界条件下触发的设备操作系统软件Bug。

触发条件：在堆叠分裂发生时，系统中存在处于 Down 状态的OSPF接口。
该Bug位于堆叠分裂处理模块与OSPF协议栈模块的交互代码中，在常规测试中难以发现，但在您此次严谨的故障模拟中被成功复现。

4. 解决方案与建议

4.1 临时规避方案

• 在进行堆叠相关维护操作（如重启、拔插堆叠线）或模拟故障前，务必确保所有OSPF接口及邻居关系处于稳定正常（Up/Full）状态。

• 如果必须在有OSPF接口异常的情况下操作，可尝试先临时禁用OSPF进程 (ospf 1 shutdown)，待操作完成后再启用。

4.2 根本解决方案

1. 信息收集：在设备重启后，立即通过Console口登录，执行以下命令收集日志：

   bash

   display logbuffer display ospf event display ospf error

   重点关注故障时间点附近是否有内核错误、看门狗超时或OSPF进程异常记录。

2. 联系厂商：将本报告描述的精确场景提交给H3C技术支持。提供以下关键信息：

   • 拓扑： “日”字形，堆叠+透明防火墙。

   • 配置： 启用了MAD-BFD。

   • 精确重现步骤： “先断OSPF内网链路 -> 再触发堆叠分裂” 导致死机。

   • 对比实验： “保持OSPF内网链路正常 -> 触发堆叠分裂” 则正常。

   • 收集的日志。

3. 系统升级： 咨询H3C官方，确认您使用的软件版本是否存在已知的类似Bug，并按照指导升级到已修复该问题的稳定版本。