多個 IPMI 消息橋接解釋

假設我想通過with將Get Device Id命令從LAN一個通道發送到另一個通道，我需要完成這些步驟：IPMB``BMC``message tracking

1. Get Device Id在命令中封裝Send Message命令
2. 發送Send Message命令LAN以BMC提供所需的數據，如目標IPMB地址、所有這些NetFns、LUNs 和在這種情況下最相關的：請求唯一 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甚至提供範例描述：

例如，假設Get Device ID命令已封裝在從 LAN 通道定向到 IPMB 的Send Message命令中。BMC 將立即在 LAN 上發送對Send Message命令的響應。BMC 將提取封裝的Get Device ID消息內容並將其格式化為 IPMB 的Get Device ID請求。IPMB 上的目標設備以 IPMB 格式的Get Device ID響應消息進行響應。**BMC 獲取發出發送消息命令時儲存的跟踪資訊，並使用它來創建 LAN 格式的獲取設備 ID響應。

我是 FreeIPMI 的維護者。在我使用過的所有主機板中，“B”一直是受支持的實現。我個人從未見過“A”的實現。我會認為“A”實現最低限度是“非標準”的（即使在 IPMI 規範中找到了“A”的法律措辭，行業已經對“B”進行了標準化）。

不確定您的最終目標，但如果您正在開發產品，我可以肯定地說“B”將適用於大多數 IPMI 伺服器。如果您有能力與“A”供應商交談，我肯定會推動他們實施“B”。

引用自：https://serverfault.com/questions/833397