![多种 IPMI 消息桥接解释](https://linux22.com/image/699024/%E5%A4%9A%E7%A7%8D%20IPMI%20%E6%B6%88%E6%81%AF%E6%A1%A5%E6%8E%A5%E8%A7%A3%E9%87%8A.png)
假设我想通过 从一个通道发送命令到另一个Get Device Id
通道,我需要执行以下步骤:LAN
IPMB
BMC
message tracking
Get Device Id
将命令封装在Send Message
命令中- 发送
Send Message
命令从LAN
提供BMC
所需数据,如目标IPMB
地址、所有这些NetFn
s、LUN
s 以及本例中最相关的数据:请求唯一Sequence Number
和message tracking
参数位设置
我的困惑开始于此...因为我看到了两种不同的解决方案来BMC
处理此类请求:
A
响应Get Device Id
返回Send Message
响应中
B
分开Send Message
并IPMB
响应
,结果取决于BMC
生产者。
所以我需要一些专家的知识:
这就是IPMI
标准所代表的,BMC
实施可以提供A
和/或B
?或者这是BMC
生产商的误导性解释?
在我看来以及我的理解IPMI 2.0 spec
,唯一的B
解决方案就是唯一兼容的流程,其工作方式如下6.13.4 Bridged Request Example
:
当请求消息通过封装在发信息命令(来自系统接口以外的源通道),BMC立即返回响应发信息命令本身。同时,请求从发信息命令并转发到指定的目标频道。
IPMI 2.0 spec
甚至提供示例描述:
例如,假设获取设备 ID命令已被封装在请求中发信息命令从 LAN 通道发送到 IPMB。BMC 将立即向发信息命令返回 LAN。BMC 将提取封装的获取设备 ID消息内容并将其格式化为获取设备 ID请求 IPMB。IPMB 上的目标设备会响应获取设备 IDIPMB 格式的响应消息。BMC 会获取在发信息命令发出后,并使用它来创建一个获取设备 ID以 LAN 格式响应。
答案1
我是 FreeIPMI 的维护者。在我使用过的所有主板中,“B”一直是受支持的实现。我个人从未见过“A”的实现。我认为“A”实现至少是“非标准的”(即使在 IPMI 规范中找到了“A”的合法措辞,但业界已经将“B”标准化了)。
不确定您的最终目标是什么,但如果您正在开发产品,我可以肯定地说“B”可以在大多数 IPMI 服务器上工作。如果您有能力与“A”供应商交谈,我肯定会推动他们实施“B”。