【问题求助】OCP卡在位，从专口切换ocp port2口，概率出现BMC网络不通

交流互助区
1

// 此模板仅供参考，如果不适用可以修改

问题描述

OCP卡在位，从专口切换ocp port2口，概率出现网络不通

环境信息

  • 软件版本：OpenUBMC LTS SP1

初步分析

image
image1243×778 213 KB

问题场景1：有日志1，没有日志2，端口没有正确切过来，怀疑是队列任务卡住

image
image1822×675 200 KB

问题场景2：日志1/2均无，信号也未收到

image
image1834×879 277 KB

另外日志中有一些日志刷屏，不确定是否跟日志刷屏导致任务量太大而出现任务阻塞，因此求助定位一下

ocp2专口切换port2不通ac后ip通KunLun5280V2_2102315HMJ10R9100007_20260313-2004.part2.rar.txt (854.2 KB)
ocp2专口切换port2不通ac后ip通KunLun5280V2_2102315HMJ10R9100007_20260313-2004.part1.rar.txt (9 MB)

2

答案内容由AI生成，仅供参考：

结论

该问题是由系统级任务调度拥塞引发的功能性故障，本质为：

高负载下关键事件信号丢失 → NCSI端口切换流程中断 → BMC网络不可达

建议优先优化异步队列处理逻辑 + 抑制刷屏日志，从根本上提升系统稳定性与切换可靠性。

如需进一步分析完整日志包（.rar.txt），建议解压后使用日志分析工具（如ELK、GrepConsole）进行全量关联追踪。

点击此处查看详细分析解答

OCP卡在位时从专用口切换至OCP Port2概率性网络不通问题分析报告

问题概述

在OpenUBMC LTS SP1环境中，当系统检测到OCP卡在位时，尝试从专用管理网口（Dedicated Port）切换至OCP扩展网口的Port2时，存在概率性BMC网络连接中断的问题。部分场景下，AC掉电重启后网络可恢复通信。

环境信息

  • 软件版本：OpenUBMC LTS SP1
  • 硬件平台：KunLun 5280V2（设备SN: 2102315HMJ10R9100007）
  • 问题设备BMC IP：70.189.80.77
  • OCP卡类型：OCP2卡（BCM957508-P2100G）
  • 切换方式：通过Web或CLI执行网口模式切换至OCP Port2

问题现象与场景分类

场景一：命令执行成功但实际未完成端口切换（任务阻塞）

日志特征

# bmc_network显示切换成功
2026-03-13 19:56:14 bmc_network,Set ocp2 ethernet destination port to (port2) successfully
2026-03-13 19:56:14 bmc_network,Set ethernet mode to (ocp2) successfully

# network_adapter收到ActivePort变更信号
2026-03-13 19:58:05.938105 network_adapter NOTICE: ncsi_info.lua(100): ncsi: NCSIInfoChangedSignal (ActivePort: 9)
2026-03-13 19:58:05.938558 network_adapter NOTICE: ncsi_info.lua(102): ncsi: Update ActivePort property value (9)

# 未出现关键日志
→ 缺失日志: "ncsi: Set ncsi active port.(MgmtPortId = 9)"

关键分析

  • bmc_network 已发出切换命令并记录成功。
  • network_adapter 的 ncsi_info:on_update() 收到了 ActivePort: 9 的变更通知，进入处理流程。
  • 但未产生最终生效日志 Set ncsi active port.(MgmtPortId = 9)，说明后续关键函数 ncsi_change_active_port() 未执行。
  • 根本怀疑：[Skynet消息队列调度延迟]导致 ncsi_info_changed_q 异步任务卡住或被丢弃，造成切换流程中断。

:red_circle: 注：MgmtPortId = 9 对应的是 OCP2的Port2，按系统映射规则，不同类型端口分配唯一ID：

  • 专用口 = 1
  • OCP Port1 = 8
  • OCP Port2 = 9

场景二：完全无切换行为触发（信号未发送）

日志特征

# 切换操作记录
2026-03-13 18:58:59 bmc_network,Set ocp ethernet destination port to (port1) successfully
2026-03-13 18:58:59 bmc_network,Set ethernet mode to (ocp) successfully

# 未见任何 network_adapter 对 ActivePort 的响应
→ 完全缺失: NCSIInfoChangedSignal(ActivePort: x) 日志

# 消息队列警告高频出现
2026-03-13 18:59:03.033764 network_adapter WARNING: Requester Skynet message queue scheduling delay is 501 ms (threshold: 500 ms) [repeated 51 times]
2026-03-13 18:59:05.742808 bmc_network WARNING: ... delay is 506 ms

关键分析

  • bmc_network 成功接收并记录切换请求。
  • network_adapter 模块完全未收到信号，表明 NCSIInfoChangedSignal 通知未能送达。
  • 同时发现两个组件（bmc_network, network_adapter）均存在 Skynet消息队列延迟超过阈值（500ms） 的警告，且重复多达51次。
  • 根本怀疑：系统负载过高或调度阻塞，导致D-Bus或内部消息总线事件丢失或延迟严重，致使 ActivePort 变更信号未能到达 network_adapter。

根本原因分析

因素 分析结论
:white_check_mark: 异步任务队列机制缺陷 ncsi_info:on_update() 使用 skynet.sleep(100) 和 self.ncsi_info_changed_q() 实现异步处理，若队列处理缓慢或阻塞，可能导致事件丢失或延迟。
:white_check_mark: 高频率日志刷屏引发调度延迟 日志中频繁出现 get ncsi link status failed 和 Skynet message queue scheduling delay 警告，说明系统存在持续性的I/O或任务压力，可能抢占关键网络切换任务资源。
:warning: ActivePort值与MgmtPortId映射逻辑风险 value 传入为 9，需依赖 get_active_port_id() 函数正确解析。若映射表错误或端口状态异常（如Port2物理未连接），可能导致处理逻辑跳过或失败。
:white_check_mark: 模块间通信依赖稳定性不足 bmc_network → network_adapter 的配置生效依赖信号传递机制，缺乏重试、超时或状态反馈机制，容错能力弱。

可能根因总结

:light_bulb: 主因：Skynet消息调度延迟导致事件队列拥塞，bmc_network 发出的 ActivePort 变更信号未能及时/完整地被 network_adapter 处理，进而使NCSI通道切换流程中断或跳过。

:small_blue_diamond: 诱因1：network_adapter 模块内部存在高频警告日志（如链路状态获取失败），加剧系统负载，形成“拥堵—延迟—更拥堵”的恶性循环。
:small_blue_diamond: 诱因2：bmc_network 自身也出现消息延迟，反映整个Skynet服务总线处于高负载状态，影响多模块协同。
:small_blue_diamond: 诱因3：缺乏对切换失败的补偿机制（如自动回退、状态校验重试），导致失败后无感知、无恢复。

解决方案建议

短期规避措施

  1. 避免高峰期执行切换操作
    在系统负载较低时执行网口切换，减少并发任务竞争。

  2. 切换后强制AC掉电重启验证
    用户反馈AC后可恢复通信，可临时作为确认切换生效的手段。

  3. 降低非关键日志等级
    关闭或降低 WARNING 级别的 get ncsi link status failed 和 message queue delay 日志频率，减轻I/O压力。

中长期修复建议

1. 优化 ncsi_info_changed_q 队列处理机制

-- 建议：增加任务去重、超时检测、错误重试机制
if switch[changed_info[1]] then
    self.ncsi_info_changed_q(function ()
        local ok, err = pcall(switch[changed_info[1]], changed_info[2])
        if not ok then
            log:error("ncsi: Failed to handle %s change: %s", changed_info[1], err)
            -- 可加入上报或告警
        end
    end, 3000) -- 设置最大等待时间（ms）
end

2. 增加信号发送确认与状态轮询

  • bmc_network 在发送 ActivePort 更改后，主动查询 network_adapter 是否已生效。
  • 若超时未生效，触发告警或尝试重新发送。

3. 引入健康检查与自动恢复机制

  • 监控 bmc_network 和 network_adapter 的Skynet队列延迟。
  • 当延迟持续>500ms达N次，触发降级处理或重启相关服务。

4. 完善日志追踪能力

  • 在 ncsi_info.lua 关键路径添加更细粒度日志：
    log:notice('ncsi: Starting to change active port from %d to %d', old_active_port, cur_active_port)
  • 记录每一步执行耗时，便于定位瓶颈。

验证方法

  1. 预期成功日志序列
bmc_network: Set ethernet mode to (ocp2) successfully
network_adapter: NCSIInfoChangedSignal(ActivePort: 9)
network_adapter: Update ActivePort property value(9)
network_adapter: Set ncsi active port.(MgmtPortId = 9)
→ 随后BMC IP应在OCP2-Port2上可达
  1. 监控指标
    • Skynet消息延迟 < 500ms
    • ncsi_change_active_port 调用成功率 100%
    • 切换后网口IP可达性 100%

参考依据来源

  • 日志分析：app.log.1 中 network_adapter 和 bmc_network 行为轨迹。
  • 系统机制：bmc_network 负责网络模式配置，network_adapter 负责NCSI底层驱动交互（源自[知识库]及文档“bmc_network”、“network_adapter”）。
  • 端口映射规则：专用口=1，OCP Port1=8，Port2=9（依据 Set ncsi active port.(MgmtPortId = x) 日志序列推断）。
  • Skynet消息机制：skynet.sleep, ncsi_info_changed_q 为Skynet框架下典型异步处理模式。

结论

该问题是由系统级任务调度拥塞引发的功能性故障，本质为：

高负载下关键事件信号丢失 → NCSI端口切换流程中断 → BMC网络不可达

建议优先优化异步队列处理逻辑 + 抑制刷屏日志，从根本上提升系统稳定性与切换可靠性。

如需进一步分析完整日志包（.rar.txt），建议解压后使用日志分析工具（如ELK、GrepConsole）进行全量关联追踪。

3

这个现象之前kunlun相关人员找过，我记得解决过，你可以询问一下liuchenxi

4

之前反馈的是950机型ipv6网关丢失的问题与当前问题不一样

5

80.77 ncsi ocp port2dump_info.tar.gz (9.9 MB)

新复现日志

6

网通了之后收的日志
KunLun5280V2_8_20260525-1125.tar.gz (10.0 MB)

7

新加了一些日志，重新复现了，最后一次切换大概10分钟才通
KunLun5280V2_8_20260528-1431.part1.rar.txt (9 MB)
KunLun5280V2_8_20260528-1431.part2.rar.txt (1.0 MB)

8

具体切换时间点是什么时候