4、配置管理工具：使用 ibswitches、ibqueryerrors、saquery 等工具检查配置

核心原理：从“被动等故障”到“主动查配置”

在 IB（InfiniBand）交换机大规模组网环境中，配置错误往往不会像链路中断那样立即暴露，而是以“性能劣化”“偶发丢包”“路由不对称”等隐性方式潜伏。等到业务受损再去定位，排查成本极高。因此，配置管理工具的核心价值在于：通过查询子网管理器（Subnet Manager, SM）维护的子网数据库，将全网交换机的实际运行配置、端口状态、链路错误计数、路径可达性等信息以结构化方式导出，供工程师比对、审计和验证。

这些工具本质上都是 IB 管理报文（MAD，Management Datagram）的客户端。它们向 SM 或直接向交换机发送查询请求，SM 返回包含节点信息、端口属性、链路状态、性能计数器等内容的响应。理解这一点，就能明白为什么这些工具能“看到”全网拓扑——它们读取的是 SM 已经发现并维护的子网视图，而非逐台登录设备执行 CLI 命令。

方法流程：三工具组合排查配置问题

第一步：ibswitches 确认拓扑与节点配置

ibswitches 是最基础的拓扑查看工具，它列出子网中所有交换机节点及其关键属性。当怀疑配置错误时，首先用它确认：

• 交换机是否全部被发现：如果实际有 32 台交换机，但 ibswitches 只显示 30 台，说明有节点未成功加入子网，可能是 GUID 冲突、分区配置错误或固件异常。
• 端口速率与宽度是否一致：例如预期所有 spine 交换机上行端口为 EDR（100Gbps），但某台显示为 FDR（56Gbps），说明线缆或配置不匹配。
• 固件版本是否统一：混用固件版本可能导致部分交换机不支持某些管理属性。

# 查看全网交换机列表及关键属性
$ ibswitches

# 输出示例（节选）
# Switch  : 0x00117501a300a1a1
#   Type  : SLX 7740
#   Ports : 36
#   State : Active
#   LID   : 0x2
#   GUID  : 0x00117501a300a1a1
#   FW    : 10.4.2.1
#   Rate  : EDR (100Gb/s)

第二步：ibqueryerrors 扫描链路错误计数

配置错误往往会在链路上产生可观测的错误计数。ibqueryerrors 读取每个端口的性能计数器，帮助快速定位“配置了但质量差”的链路。重点关注以下计数器：

计数器名称	含义	配置错误关联
SymbolErrors	物理层符号错误	信号完整性差、线缆/光模块问题
LinkErrorRecovery	链路错误恢复次数	端口配置不匹配、FEC 设置不一致
RcvErrors	接收错误包数	MTU 不一致、缓冲区配置错误
RcvSwitchRelayErrors	交换机转发错误	路由表/转发表配置异常
XmitDiscards	发送丢弃包数	流控配置错误、缓冲区不足

# 扫描全网所有端口的错误计数（超过阈值才显示）
$ ibqueryerrors -c 100

# 输出示例（节选）
# Errors for 0x00117501a300a1a1 Port 24:
#   SymbolErrors: 0
#   LinkErrorRecovery: 0
#   RcvErrors: 0
#   XmitDiscards: 1523   <-- 发送丢弃异常
#   RcvSwitchRelayErrors: 0

第三步：saquery 验证路径与服务

saquery 是 SA（Subnet Administrator）查询工具，用于验证 SM 提供的路径计算和分区服务是否正常。当拓扑和链路都正常，但业务仍不通时，使用 saquery 检查：

• 路径是否可达：查询两个 LID 之间是否存在有效路径。
• 分区成员关系：确认端节点是否在正确的 P_Key 分区中。
• 服务记录：检查 SM 是否注册了预期的服务（如性能管理器）。

# 查询从 LID 2 到 LID 8 的路径是否存在
$ saquery -p 2 8

# 查询某个端口的 P_Key 分区成员
$ saquery -P 0x00117501a300a1a1

# 输出示例（节选）
# Path from LID 2 to LID 8: OK
#   Hop 1: Switch A (LID 2) Port 24 → Switch B (LID 5) Port 12
#   Hop 2: Switch B (LID 5) Port 36 → Node (LID 8) Port 1

案例/场景：一次典型的配置错误排查

某数据中心部署了 24 台 IB 交换机（12 台 leaf + 12 台 spine），业务反馈跨 leaf 通信延迟抖动严重。工程师按以下流程排查：

1. ibswitches 检查：发现 24 台交换机全部在线，但其中一台 leaf 交换机的固件版本为 10.2.1，其余均为 10.4.2。进一步查看端口速率，发现该交换机上行端口协商为 FDR，而其他交换机为 EDR。
2. ibqueryerrors 扫描：针对该交换机所有上行端口执行 ibqueryerrors -c 500，发现 3 个上行端口的 LinkErrorRecovery 计数超过 10,000，且持续增长。
3. saquery 路径验证：查询从该 leaf 下挂服务器到远端 spine 的路径，发现路径存在但经过的链路均为上述高错误端口。

根因定位：该 leaf 交换机固件版本过旧，不支持与 spine 交换机相同的 FEC（前向纠错）模式，导致链路层持续进行错误恢复。升级固件并统一 FEC 配置后，错误计数归零，延迟抖动消失。

误区/复盘：工具使用中的常见错误