BMC-IPV6命令设置静态路由1

[l00012320 (kunlun_luzhanghui)]

调用标准命令ipmitool lan6 set 1 nolock static_rtc 1 FD00::90:90:132:0:1 3c:c7:86:0f:fb:4d 90:90:: 96
用IPMI标准命令设置静态路由1，发现BMC Web上的网关也会被覆盖，而网关对应的应该是默认路由吧？
手动在BMC Web上设置网关，查询静态路由1，不会跟着变，这两个应该是不同的东西，设置静态路由1，也不应该影响到网关。

设置静态路由2就跟网关没有任何互动，这是符合预期的。

请帮忙排查一下，这个应该是闭源仓bmc_network里。

[ubmc_assistant (openUBMC_Assistant)]

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

关于通过IPMI命令设置IPv6静态路由影响网关的问题分析与排查

根据您提出的问题，通过 ipmitool 命令设置 IPv6 静态路由 1 时意外覆盖了 BMC Web 界面中的网关配置（默认路由），而设置静态路由 2 却不影响网关，这表明系统在处理 IPv6 静态路由 1 时存在异常行为。以下基于所提供的 知识图谱数据（KG） 和 文档内容（DC） 进行综合分析与排查。

---

问题核心总结

• 操作命令：

  ipmitool lan6 set 1 static_route FD00::90:90:132:0:1 90:90:: 96
  

  （注：原文 nolock static_rtc 应为笔误，标准命令应为 static_route）

• 现象：

  • 设置 静态路由1 会 覆盖 Web 页面上的“网关”配置（即默认路由）。
  • 设置 静态路由2 不影响网关 → 行为正常。
  • 手动在 Web 设置网关，静态路由1 不随之改变 → 说明两者应独立。
  • 因此，设置静态路由1 影响默认路由属于异常行为。

• 初步判断：

  • 该问题可能源于闭源组件 bmc_network 对“静态路由 1”的特殊处理逻辑。
  • 可能存在 静态路由1 与默认路由耦合或映射错误 的实现缺陷。

---

相关实体与机制分析

1. Bmc Network 组件的角色

"entity": "bmc_network", "type": "service", "description": "..."

bmc_network 是 BMC 中负责网络配置的核心服务，管理 IPv4/IPv6 设置、静态与 DHCP 模式、LLDP 发现等。它直接参与网络资源树的初始化和网络对象配置。

• 它被明确描述为：
  • 管理 IPv6 配置（包括地址、前缀、网关）；
  • 涉及 Redfish 协议通信和日志记录；
  • 有版本号（如 1.70.42），属于 openUBMC 构建体系；
  • 存在 构建不完整风险（如缺少 CMakeLists.txt、post_hpm 方法）；
  • 在数据库中重复保存失败、对象不唯一等问题。

结论： bmc_network 是目标排查组件，其对 IPv6 路由处理逻辑可能存在 bug。

---

2. IPv6 静态路由与默认路由的区别

在正常网络模型中：

类型	用途	目标地址	典型前缀长度
默认路由（Default Gateway）	所有非本地流量	::/0	/0
静态路由1 / 静态路由2	特定子网路由	如 FD00::/64	/64 ~ /128

根据文档《【已评审】EthGroup对象新增属性和方法》（DC8）：

• 新增了 SetIpv6DefaultGateway 方法 —— 明确用于设置默认网关；
• 同时有 SetIpv6PrefixGateway 可设置包含前缀的完整路由。

因此系统设计上 默认路由和静态路由是两个独立配置项。

---

3. Web 配置与 ipmitool 命令路径差异

Web 界面配置网关（默认路由）：

通常调用 D-Bus 接口：

busctl --user call bmc.kepler.bmc_network /bmc/kepler/Managers/1/EthernetInterfaces/Ipv6 \
  bmc.kepler.Managers.EthernetInterfaces.Ipv6 SetIpv6PrefixGateway a{ss}sis 3 \
  Interface a UserName a ClientAddr a xxxx:xx:... 112 xxxx:xx:...

ipmitool lan6 set 命令执行流程：

ipmitool lan6 set 1 static_route <prefix> <gateway> <prefix_len>

• 通过 IPMI 协议传入请求；
• BMC 内部由 ipmitool 或底层守护进程解析；
• 最终交由 bmc_network 模块处理并应用配置。

关键点：

若 bmc_network 在处理 static_route index=1 时错误地将该路由识别为“默认路由”或触发了网关同步逻辑，则会导致网关被覆盖。

---

4. 为何静态路由2 不受影响？

这说明系统的静态路由管理是 索引区分的。

根据 bmc_network 的设计，静态路由1 的索引可能被硬编码为“默认路由”的后备路径或映射通道。例如：

• 当前仅支持最多两条静态路由；
• 系统误将第一个静态路由（index=1）当作“主路由”并自动提升为默认路由；
• 或者在未设置默认路由时，自动用 static_route 1 替代。

此类行为不符合 RFC 规范，但在闭源实现中可能出现。

---

5. Ipv6 数据库约束异常

从 KG 数据中发现：

"Ipv6 refers to the Internet Protocol version 6, a class of network objects that failed to save in the database due to a constraint violation."

更严重的是：

"Multiple records with identifiers such as 's10' and 's13' have been observed, raising questions about its uniqueness"
"NOT NULL constraint violations" during save attempts

这意味着：

• IPv6 相关配置数据在持久化时存在潜在冲突；
• 静态路由1 可能因 ID 冲突或键值混淆，错误地更新了默认路由记录。

---

排查建议

1. 检查 bmc_network 的静态路由处理逻辑

• 定位闭源模块 bmc_network 中对 static_route index=1 的处理逻辑；
• 查看是否含有类似：

  if (route_index == 1) {
      set_default_gateway(...);  // ❌ 错误地更新默认路由
  }
  

• 确认 static_route 与 default_gateway 是否共用同一张配置表或 DB key。

2. 对比 Web 设置与 IPMI 设置的底层 D-Bus 调用

• 使用 busctl monitor 监听 /bmc/kepler/bmc_network 接口；
• 分别执行：
  • Web 设置网关；
  • ipmitool 设置静态路由1；
  • 观察 D-Bus 调用的方法和参数是否重叠；
• 特别关注 SetIpv6PrefixGateway 与 SetIpv6DefaultGateway 是否被混用。

3. 验证默认路由是否应为 ::/0

• 查询当前默认路由：

  ipmitool lan6 print 1 | grep "IPv6 Default Gateway"
  

• 正常情况下，其前缀为 ::/0；
• 若设置 FD00::/96 后，此字段变为 FD00::/96，则确认被覆盖。

4. 测试静态路由1 与默认路由分离配置

1. 在 Web 上手动设置默认网关为 G1；
2. 使用 ipmitool 设置静态路由1 为目的 N1；
3. 使用 ipmitool lan6 print 1 检查：
   • 是否静态路由1 = N1
   • 是否默认路由仍为 G1 （若变更为 N1，则为 bug）

---

当前问题定位结论

该问题是由于 bmc_network 组件在实现上将“静态路由1”的设置逻辑与“默认路由”错误绑定所致，特别是在 IPMI 接口处理中未能正确区分两者，导致配置外溢。

---

建议解决方案

措施	说明
修复 bmc_network 的路由索引逻辑	确保 static_route index=1 不触发默认路由更新；确保各路由条目独立存储。
明确区分 D-Bus 接口职责	SetIpv6PrefixGateway 仅用于静态路由，SetIpv6DefaultGateway 专用于 ::/0 路由。
添加配置合法性校验	设置静态路由时，若目标前缀非 ::/0，禁止写入默认路由字段。
升级版本并验证修复	若 bmc_network 已发布新版本（如 1.80.69），进行回归测试。

---

总结

项目	说明
问题本质	使用 IPMI 命令设置 IPv6 静态路由1 时错误修改了默认路由（网关）。
根本原因	bmc_network 模块对静态路由索引 1 的处理存在耦合缺陷，可能因数据库设计或逻辑硬编码导致。
影响范围	仅 static_route 1 存在异常；static_route 2 正常。
修复方向	闭源模块 bmc_network 需隔离静态路由与默认路由的写入逻辑，强化输入验证与 D-Bus 接口分工。

建议提交至 bmc_network 开发团队，并附带复现脚本与 D-Bus 日志抓取。

相关链接：

1. 双因素关闭命令咨询急
2. 【BMC Studio】BMC Studio新特性介绍：基于Qemu进行代码调试与资源协作接口调试
3. 【iTestSmart 1.0.36】静态模式修改备份IP、备份掩码测试
4. 选用OCP扩展网口概率性分配不到ip，且使能扩展网口概率性失败
5. 网络管理常见问题指南 | 文档中心 | openUBMC

[wangxin]

你好，在当前bmc_network的代码实现中，下发设置静态路由1的命令后，会同时设置静态路由1和默认路由为设置值，该现象是符合预期的。

[l00012320 (kunlun_luzhanghui)]

符合预期，不符合逻辑。静态路由1的命令不应该去设置默认路由，这是两码事，分开的

[grlxw (xijie)]

设置静态路由1的ip同步设置默认网关是沿用了历史实现逻辑，目前实现为保持历史功能不受影响，如有解耦诉求可以收集相关背景，后续进行评审。