RoCE 节点之间能够建立连接，带宽和稳定性却明显不符合预期，问题有时不在物理链路或 PFC，而在应用选用了错误的 GID。GID 表把 RDMA 端口与网络地址语境联系起来，同一端口可能因 IPv4、IPv6、VLAN、RoCE 类型或网络配置出现多个条目。固定抄一个 GID index 在实验室可用，换到另一台服务器、重建网络或调整 VLAN 后就可能指向不同条目。因而 index 只能作为当时查询结果，不能充当跨主机的永久配置。
为什么“能 ping”证明不了 GID 正确
普通 IP 连通说明内核网络栈存在可达路径，RDMA 应用实际选择的设备、端口、GID 和源地址仍可能不同。多张网卡、bond、VLAN 子接口、容器网络和策略路由都会扩大差异。若应用自动选择，它可能依据 rdma_cm、路由和绑定地址决定；若应用手工指定设备或 index，则要确认指定值与系统当前状态一致。排查时应同时保存 IP 路由、邻居、RDMA link、GID 表和应用启动参数，而不是只截一张 ping 结果。
地址族与 RoCE 类型要成对检查
源端和目的端必须在可互通的地址与 RoCE 语境中工作。双栈环境里，一个进程可能绑定 IPv6，另一个服务只监听 IPv4；VLAN 环境里，物理接口与子接口对应的 GID 也可能不同。检查时要明确应用使用主机名还是地址，DNS 返回顺序是否变化，源地址由谁选择，以及路径中交换设备的 MTU、QoS 和路由是否覆盖该地址。不要为了让测试通过而随意尝试多个 index，最终留下一个无法解释的数字。
网络命名空间会改变观察位置
容器或 Kubernetes Pod 内看到的接口与宿主机不同，RDMA 设备怎样暴露、IP 地址配置在哪个命名空间、应用进程从哪里查询路由，都可能影响 GID 选择。宿主机命令显示正确，不代表容器内部路径正确。应从实际运行进程所在的命名空间执行查询，并记录设备插件、网络附件和安全上下文。若使用 SR-IOV VF，还要把 PF 策略、VF 设备身份和交换网络配置连接起来，避免把另一个租户或另一条业务网的条目选进来。
性能异常要回到逐层证据
选对 GID 后仍需检查物理速率、PCIe、NUMA、MTU、拥塞控制和应用消息模型。GID 问题常与其他问题叠加，不能因为修正后带宽提高就宣布所有配置已经正确。建议先用小消息确认连接和基础延迟，再用不同消息大小、队列深度和双向模式观察；同时查看端口误码、ECN/CNP、丢包和 CPU 绑定。测试工具与真实应用使用的连接方式也可能不同，最终必须回到业务程序复测。
节点扩容时还应把 GID 语义检查做成准入任务：同一角色节点应拥有预期的地址类型、VLAN 和端口集合，数量或顺序出现差异就转人工复核。这样可以在作业进入节点前发现镜像、网络配置或驱动差异，而不是等多节点通信出现偶发失败后再逐台比对。
可维护的配置方式
- 按稳定设备身份、接口名称、VLAN 和地址查询 GID，不把单一 index 写成通用常量。
- 记录两端地址族、RoCE 类型、命名空间、路由与应用绑定方式。
- 在每台节点上自动校验目标条目是否存在且含义一致，发现偏差就阻止上线。
- 用基础 RDMA 测试与真实应用分别验证，并同步采集链路和拥塞计数。
- 在网卡更换、固件或驱动升级、VLAN 变更后重新生成并审核映射。
GID 表与配置命令会随驱动和系统环境变化，操作前应从 NVIDIA Networking Documentation进入当前 MLNX_OFED、DOCA-OFED 或网卡相关手册核对。工程记录应描述“选择了哪种地址和路径以及为何选择”，而不是只保留一个 index。这样在节点扩容或系统升级后，自动化才有能力判断配置仍然有效。
WeChat
Profile