企业官网建设流程全解析

简介：面向IT运维人员与服务器技术支持工程师的超微（Supermicro）服务器IPMI RAW命令技术规格文档，聚焦BMC带外管理场景下的故障排查与远程运维需求。包内共1个docx文件，压缩包约35KB，内容为英文原版命令手册，按OEM命令集逐条列出NetFN、Command、Subcmd及请求/响应数据格式。文档涵盖获取UUID、BMC IP地址与MAC地址、清除机箱入侵状态、UID指示灯开关、LAN模式切换、获取系统MAC地址及Snoop Byte等命令，并标注X9及后续主板支持情况，附有版本修订记录。已有679人学习下载，适合需要快速定位服务器硬件状态、减少现场维护的中高级运维人员对照查阅。

1. 一条命令背后的管理通道：为什么 IPMI RAW 值得搞懂

服务器宕机了，操作系统进不去，SSH 连不上，显示器接上去只有黑屏——这时候还能救你的，往往不是操作系统里的任何工具，而是主板上一颗独立供电、独立运行的小芯片。它叫 BMC，而你和它对话的语言就是 IPMI。超微（Supermicro）服务器把这套语言扩展出了一批 OEM 命令，用raw方式直接发字节就能调用，不需要装任何厂商工具。很多人天天用ipmitool看传感器、开关机，却从没想过：为什么一条raw 0x30 0x70 0x66 ...就能改风扇转速？这些字节到底被谁解析、又落到哪里？搞懂这层机制，你才能在带外管理翻车时不再抓瞎，也才能看懂那份命令文档里每个 Data 字节的真正含义。

2. IPMI 的分层结构：raw 命令到底绕过了什么

2.1 从 ipmitool 到 BMC 的完整链路

要理解 RAW 命令，先得看清 IPMI 的分层。IPMI 规范把一次管理操作拆成几个层次：最上层是「命令语义」，比如「读 CPU 温度」；往下是「NetFn + Command」这对寻址坐标；再往下是传输层，可以是 KCS（系统接口）、LAN（网络）、BT 等；最底层才是物理总线或网络包。

ipmitool这类工具在正常模式下，会帮你把语义翻译成 NetFn/Command/Data，再封装成传输层报文。而raw子命令做的事情非常直接：你给它一串十六进制字节，它几乎原样塞进 IPMI 消息体，跳过所有语义解析和参数校验。换句话说，raw是 IPMI 协议栈的「后门」——它不关心你发的是什么，只负责把字节送到 BMC。

这就解释了一个常见困惑：为什么有些命令用ipmitool sensor能读，用raw却要自己拼字节？因为前者走的是标准语义层，后者走的是裸协议层。标准命令由 IPMI 规范统一定义，而 OEM 命令（NetFn 为 0x30 这类厂商自定义段）根本没有标准语义，工具不认识，只能靠raw手动发。

2.2 NetFn 与 Command：两个字节如何定位一个功能

IPMI 消息体的头两个关键字段是 NetFn（网络功能码）和 Command（命令码）。NetFn 相当于「功能大类」，Command 是「大类下的具体操作」。标准 NetFn 有固定的分配，比如 0x06 是应用类、0x0C 是传输类、0x30 是厂商自定义 OEM 段。超微这份文档里绝大多数命令都落在 0x30，说明它们是超微自己扩展的私有功能。

这里有个容易被忽略的细节：NetFn 在消息里实际占一个字节的高 6 位，最低 2 位是 LUN（逻辑单元号），通常为 0。所以你在raw里写0x30，BMC 解析时取的是高 6 位0x0C作为真正的 NetFn 值，LUN 为 0。这也是为什么有些文档写 NetFn 0x30、有些写 0x0C，其实是同一件事的不同表示层。理解这一点，你在对照不同厂商文档时才不会懵。

Command 字节则是 NetFn 内部的索引。比如文档里NetFN 30h Command 70h反复出现，0x70就是超微 OEM 段里的一个「多功能入口」，后面再跟一个 Subcmd 字节来细分具体操作——风扇控制是 Subcmd 0x66，端口服务是 0x67，网络链路状态是 0x60。这种「一级 Command + 二级 Subcmd」的设计，本质是在有限的命令码空间里做二级寻址，是 OEM 扩展的常见手法。

2.3 请求与响应：Data 字节的约定

一条 IPMI 消息除了 NetFn 和 Command，还带请求数据和响应数据。响应数据的第一个字节永远是 Completion Code（完成码），0x00 表示成功，非零表示各类错误。这是 IPMI 的硬约定，也是排查问题的第一入口——任何raw命令返回的第一个字节不是 0x00，就说明 BMC 拒绝了这次请求，后面的数据都不可信。

请求数据的布局则完全由命令自己定义。文档里每个命令都列了 Request Data 的 Data0、Data1……这些字节的含义是厂商约定的，没有通用规则。比如Get & Set Fan mode（NetFN 0x30, Command 0x45）里，Data0 是操作类型（0 读、1 写、2 查支持的模式），Data1 在写模式下才是风扇模式值。这种「一个字节兼作操作码和参数」的设计在 OEM 命令里非常普遍，读文档时必须逐字节对照，不能想当然。

3. 超微 OEM 命令的字节级拆解：从 UUID 到风扇控制

3.1 标识类命令：UUID、MAC、BIOS 信息怎么取

标识类命令是运维里用得最多的一类，因为它们回答「这台机器是谁」。文档里的Get UUID（NetFN 0x06, Command 0x37）虽然落在标准应用类 NetFn 下，但它是超微的 OEM 实现，返回 Data1-6 是 ASCII 格式的标识，Data7-12 是 BMC MAC 地址。注意这里 UUID 用的是 ASCII 而非二进制 16 字节，这是超微的私有约定，和标准 IPMI 的Get Device ID返回的二进制 UUID 不是一回事。

取 BMC IP 和 MAC 则走传输类 NetFn 0x0C、Command 0x02，靠 Data1 区分：0x03 取 IP、0x05 取 MAC。请求里 Data0 固定是通道号 0x01。响应里 Data1 是保留的 0x11，Data2 开始才是真正的地址数据。这个 0x11 保留字节经常让人困惑——它不是错误码，只是占位，跳过即可。

BIOS 信息走 NetFN 0x30、Command 0xAC，Data0 选 0 取版本、选 1 取发布日期，响应是 ASCII 字符串，版本 8 字节、日期 16 字节。这类命令的价值在于：当系统起不来、dmidecode用不了时，你依然能从带外拿到固件版本，判断是不是 BIOS 升级导致的兼容问题。

3.2 状态与告警类：机箱入侵、Snoop Byte、链路状态

Clear Chassis Intrusion（NetFN 0x30, Command 0x03）是个典型的状态清除命令，请求无数据，响应只有完成码。机箱入侵是 BMC 独立监测的，即使系统断电（只要 BMC 有待机电），开盖事件也会被记录。清除它意味着告诉 BMC「这次开盖是合法的」，常用于维护后复位告警。

Get Snoop Byte（NetFN 0x30, Command 0x2A）返回一个 Snoop Byte，这是超微用于内部调试和状态追踪的字节，文档没有展开其位定义。这类命令的存在说明 OEM 段里有一部分是给 FAE 排障用的「黑匣子」接口，普通运维未必用得上，但出问题时厂商支持会要你抓这个值。

Get Network Link Status（NetFN 0x30, Command 0x70, Subcmd 0x60）信息量最大：Data1 是 LAN 模式（0 专用、1 共享、2 故障切换），Data2 是活动端口，Data3-6 是 MII 接口状态（自协商、双工、物理连接、速率），Data7-9 是 NCSI 接口状态。这里 MII 和 NCSI 是两条不同的网络路径——MII 偏 BMC 自身管理口，NCSI 是共享给主系统的侧带通道。排查「BMC 能 ping 通但系统网络异常」时，对比这两组状态往往能定位到是共享模式配置问题还是物理链路问题。

3.3 控制类命令：UID、风扇模式、看门狗

UID 控制是文档 1.01 版新增的，Enable UID走 Command 0x0D、Disable UID走 0x0E，请求无数据、响应只有完成码。UID 灯是机房定位机器的物理手段，带外开关它意味着你不用跑到机柜前按按钮。这种「一个功能一个 Command」的设计很直白，但也暴露了 OEM 段命令码的碎片化——同样是开关，风扇模式却用「一个 Command + 操作码字节」的紧凑设计。

风扇控制有两套接口，容易混淆。Get & Set Fan mode（Command 0x45）管的是「模式」：0 标准、1 全速、2 优化、3 PUE、4 重 IO，Data0 选操作、Data1 给模式值，查支持模式时 Data0 填 2，响应 Data1 是按位表示的支持掩码。而Get & Set Fan Control（Command 0x70, Subcmd 0x66）管的是「占空比」：Data0 选 0 读占空比、1 写占空比、2 开关 SDHM 模式，Data2 给 1-100 的占空比值。前者是策略层，后者是执行层，混用会导致「设了全速但转速没变」的假象——因为占空比可能被另一条路径覆盖。

看门狗走 Command 0x97（Set WDT）和 0x98（Reset WDT），Data0 是 0 禁用、1 启用，Data1 是超时分钟数。这里有个坑：超时单位是分钟，不是秒，填 1 意味着 60 秒后才动作，调试时容易误以为没生效。

3.4 复位与配置类：恢复出厂的三条路径

文档里Reset to factory default有三条命令，区别在保留什么：Command 0x40 保留 LAN 和 FRU 设置，0x41 擦除 LAN 和 FRU，0x42 擦除 LAN 但保留 FRU。这个设计很务实——恢复出厂最怕把网络配置也清了，导致 BMC 失联只能现场救。0x40 就是「安全恢复」，0x41 是「彻底重置」，0x42 是折中。

对应的ipmicfg工具参数也印证了这点：-fd对应 0x40、-fde对应 0x41、-fdl对应 0x42。如果你只有raw没有ipmicfg，记住这三个命令码就能完成同样的操作。另外Reset SDR to default（Command 0x44）单独重置传感器数据记录，Reset HTTP config to default（Subcmd 0xB7）和Reset Riser card config to default（Subcmd 0xB8，请求 Data0 必须是 0xA0）则是更细粒度的局部复位。这种「整体 + 局部」的复位命令矩阵，是 OEM 设计里比较成熟的做法。

4. 避坑与排查：raw 命令翻车的五个现场

4.1 返回 0xC1 或 0xFF：先分清是拒绝还是没响应

现象：发raw 0x30 0x70 0x66 0x00 0x00读风扇占空比，返回Unable to send RAW command或完成码 0xC1。原因通常有两类：一是 NetFn/Command 组合在当前固件版本不存在（比如 X9 主板发 X10 才有的命令），BMC 直接回「无效命令」；二是通道或权限不对，某些命令要求通过 KCS 接口而非 LAN 发送。解决方法是先确认主板代际——文档里每条命令都标了 X9 或 X10 支持，跨代发命令是最常见的翻车点。其次用ipmitool mc info确认固件版本，再对照文档的 Revision History 看该命令是否在你这版固件里。

4.2 字节顺序搞反：IP 地址和端口号的高低字节

现象：用Get BMC IP Address拿到的 IP 是反的，或者Get & Set Port Service设的端口号完全不对。原因：IPMI 多字节字段的字节序没有全局统一，IP 地址在响应里 Data2-5 通常是网络序（大端），而端口号在 Subcmd 0x67 里明确写了 Data2 是 LSB、Data3 是 MSB（小端）。解决方法是逐字段对照文档的 LSB/MSB 标注，不要假设所有多字节字段同序。端口号这类小端字段，拼装时记得port = data2 | (data3 << 8)。

4.3 风扇设了没反应：模式与占空比是两条路径

现象：发Set Fan mode设成全速，风扇转速纹丝不动。原因：风扇模式（Command 0x45）和占空比（Subcmd 0x66）是两套独立控制，某些固件下占空比会覆盖模式设置，或者 SDHM 模式处于开启状态接管了控制。解决方法是先用 Subcmd 0x66 的 Data0=2 查 SDHM 开关状态，必要时先关掉 SDHM，再设模式，最后用 Data0=0 读回占空比确认实际生效值。别只看命令返回 0x00 就以为成了，读回验证才是硬道理。

4.4 恢复出厂后 BMC 失联：没选对保留项

现象：执行Reset to factory default后 BMC 网络不通，只能现场接显示器。原因：用了 Command 0x41（擦除 LAN 和 FRU），把 BMC 的 IP 配置也清了。解决方法是远程操作时优先用 0x40（保留 LAN 和 FRU），确需彻底重置再考虑 0x41，且重置前先把当前 IP/MAC 记下来。这条血泪经验值得写进运维手册：任何「恢复出厂」类命令，先确认它保留什么。

4.5 看门狗超时单位误判

现象：设了看门狗超时 1，以为 1 秒后动作，结果等了一分钟才重启。原因：Set WDT的 Data1 单位是分钟，文档写得很清楚但容易被忽略。解决方法：调试阶段用较大的分钟值配合Reset WDT手动喂狗，确认逻辑无误后再缩短。另外注意看门狗一旦启用，系统里必须有对应的喂狗程序，否则会周期性重启，这种「玄学重启」排查起来很费时间。

5. 设计取舍：OEM 命令为什么长这样

把这份文档从头翻到尾，会发现超微的 OEM 命令设计有几条清晰的取舍逻辑，值得单独想一想。

第一是「命令码空间的分层复用」。NetFn 0x30 下，Command 0x70 被做成了一个多路复用入口，靠 Subcmd 字节再分支出十几个功能（链路状态、风扇占空比、端口服务、PECI、HTTP 复位等）。这种设计的好处是节省宝贵的 Command 码空间，坏处是可读性差——同样是 0x70，Subcmd 不同含义天差地别，文档必须逐条列。对比之下，UID 控制、机箱入侵清除这些用独立 Command 的功能反而更直观。这其实是「空间效率」和「认知成本」的权衡，没有绝对优劣，但读文档时必须意识到这个结构。

第二是「代际兼容的显式标注」。每条命令都标了 X9 或 X10 支持，这不是形式主义。BMC 固件在不同代主板上的命令集是增量演进的，X10 新增了 DNS 主机名、看门狗、功耗温度读取、AOC MAC、证书清除等，而 X9 只有基础集。这种「按代际分层」的做法让老固件不必实现新命令，但也意味着跨代批量运维时不能一套脚本打天下，得先探测代际再分支。

第三是「安全恢复优先」。三条恢复出厂命令里，保留 LAN 的那条（0x40）被放在最前面，ipmicfg也把它作为默认的-fd。这体现了一个务实判断：远程管理场景下，网络配置是最不该被误清的东西，因为清了就意味着必须人到现场。这种「默认安全」的设计取向，比很多只提供一个「一键恢复」的实现要成熟。

如果要验证这些命令在你手上的机器是否可用，最稳妥的路径是：先用ipmitool mc info确认固件和代际，再挑一条只读命令（比如Get BIOS Information或Get 1st System MAC Address）试发，确认完成码为 0x00 且数据合理，再逐步过渡到写操作。写操作前一定先读回当前值存档，尤其是网络和风扇相关配置。

我自己的习惯是：任何带外写命令执行前，先把「读回原值」的那条 raw 命令跑一遍并记下来，出问题能立刻回滚。这份文档的价值不在于教你敲哪条命令，而在于它把每个字节的含义摊开给你看——看懂字节布局，你就能自己拼出工具没覆盖的操作，也能在返回码异常时判断是命令不存在、参数越界还是权限问题。希望这份拆解帮到你，下次面对一条陌生的 raw 命令时，能先问一句：它的 NetFn 落在哪、Command 后面还有没有 Subcmd、Data 字节的字节序是什么。

本文还有配套的精品资源，点击获取