网络基础：以太网与InfiniBand技术对比、RoCE协议栈
在开始排查RoCE与InfiniBand混合组网故障之前，必须先厘清两种网络技术的本质差异。很多工程师在排障时陷入困境，根源并非配置错误，而是对底层协议行为理解偏差——例如用排查以太网丢包的思路去分析InfiniBand的链路层重传，或者忽略了RoCE依赖无损以太网这一前提。本节将从技术原理层面建立对比框架，并深入RoCE协议栈的内部结构。
2.1 以太网与InfiniBand：设计哲学的分野
以太网与InfiniBand诞生于完全不同的应用场景。以太网追求“尽力而为”的通用互联，协议栈轻量、成本低廉、部署灵活；而InfiniBand从设计之初就面向高性能计算（HPC）与数据中心，将可靠传输、低时延、高带宽作为第一优先级，为此不惜牺牲通用性和成本优势。
两者最核心的差异体现在以下三个层面：
- 网络层与传输层职责：以太网的IP路由负责寻址，TCP负责可靠传输，二者分离且均可独立配置；InfiniBand则将网络层（子网路由）与传输层（可靠连接/不可靠数据报）统一在IB规范中，由Channel Adapter（CA）硬件完成全部协议处理。
- 流控机制：以太网采用端到端TCP滑动窗口，中间交换机只做缓存转发，拥塞时直接丢包；InfiniBand采用基于信用的链路层流控（Link-Level Flow Control），每个VL（Virtual Lane）独立分配信用，接收端缓冲区不足时发送端暂停，从机制上杜绝了因缓冲区溢出导致的丢包。
- 报文格式：以太网帧头包含MAC地址、EtherType等字段，最大MTU通常为1500字节（Jumbo Frame可达9000）；InfiniBand报文包含LRH（Local Routing Header）、BTH（Base Transport Header）等，MTU可达4096字节，且支持原子操作（如Compare-and-Swap）。
| 对比维度 | 以太网（标准） | InfiniBand |
|---|---|---|
| 可靠传输实现 | TCP软件栈（CPU开销大） | 硬件CA实现（RDMA） |
| 拥塞控制 | TCP拥塞窗口（丢包触发） | 基于信用的链路层流控 + 拥塞控制（CC） |
| 时延（典型值） | 交换机转发 ~300ns，TCP端到端 ~10μs | 交换机转发 ~100ns，端到端 ~1μs |
| 寻址方式 | IP地址 + MAC地址 | LID（Local ID）+ GID（Global ID） |
| 多路径支持 | ECMP（哈希可能不均） | 自适应路由（AR）与动态负载均衡 |
| 丢包容忍度 | 高（TCP重传恢复） | 极低（RDMA语义下重传代价极高） |
排障启示：当你在混合组网中看到“丢包率0.01%”时，对普通TCP业务可能毫无影响，但对RoCEv2流量可能意味着吞吐量断崖式下降——因为RoCE的RDMA语义假设底层网络无损，一旦丢包，硬件重传机制会触发指数退避，性能损失远超同比例丢包的TCP场景。
2.2 RoCE协议栈：从V1到V2的演进逻辑
RoCE（RDMA over Converged Ethernet）的本质，是将InfiniBand的RDMA语义移植到以太网物理层上。理解其协议栈分层，是后续排查“为什么RoCE流量走了IP路由却不通”等问题的关键。
RoCE协议栈自下而上分为三个版本，其核心差异在于网络层封装方式：
- RoCEv1：直接在以太网链路层（EtherType 0x8915）之上承载IB报文，无IP头，因此只能在同一个二层广播域内通信，无法跨VLAN或子网。
- RoCEv2：在UDP/IPv4或IPv6之上封装IB报文（目标端口4791），将RoCE从二层扩展到三层路由域，但引入了IP分片、ECMP哈希不均等新问题。
- InfiniBand原生协议：作为对照，其LRH+GRH+BTH结构完整运行在IB子网内，不涉及以太网帧格式。
下图展示了RoCEv2协议栈与标准TCP/IP协议栈、InfiniBand协议栈的层次对应关系，以及各层承载的关键字段：
从图中可以清晰看到，RoCEv2的协议栈实际上是一个“混合体”：它保留了IB传输层的语义（如可靠连接、RDMA操作），但将网络层替换为UDP/IP，链路层替换为以太网。这种设计让RoCEv2能够利用现有以太网基础设施，但也引入了两个关键依赖：UDP端口4791的连通性和以太网无损传输能力。
2.3 核心原理：为什么RoCE需要“无损”以太网？
要理解混合组网故障，必须深入RoCE对底层网络的核心假设。IB原生网络通过链路层信用机制保证不丢包，而RoCEv2运行在标准以太网上时，这种保证消失了。为此，RoCEv2依赖以下两个机制来模拟无损环境：
- 优先级流控（PFC，IEEE 802.1Qbb）：在以太网交换机上为RoCE流量划分独立优先级队列（通常为优先级3），当接收端缓冲区超过阈值时，交换机向对端发送PFC暂停帧，阻止发送端继续发送该优先级的数据。这相当于在以太网链路上实现了类似IB的信用流控。
- 显式拥塞通知（ECN，IEEE 802.1Qau）：当交换机检测到队列长度超过阈值时，在IP头中标记CE（Congestion Experienced）位，接收端收到后通知发送端降低发送速率。这是端到端的拥塞反馈机制，类似TCP的ECN但作用于RDMA流。
常见误区：许多工程师认为“只要交换机支持PFC，RoCE就不会丢包”。实际上，PFC只能防止因缓冲区溢出导致的丢包，但无法处理以下情况：
- 链路物理错误（如光模块信号劣化）导致的FCS校验失败丢包；
- PFC死锁（多个交换机互相等待暂停帧释放）；
- ECN标记后发送端未及时降速导致的持续拥塞。
在混合组网中，这些非典型丢包原因往往比简单的缓冲区溢出更难定位。
2.4 案例场景：RoCEv2跨子网通信的MTU陷阱
某金融数据中心部署了RoCEv2存储网络，服务器A（IP 10.0.1.10）与存储阵列B（IP 10.0.2.20）位于不同IP子网，中间经过三层交换机。配置完成后，ib_write_bw测试带宽仅为理论值的30%，且伴随大量重传计数。
排查过程如下：
# 在服务器A上检查RoCE接口状态
rdma link show
# 输出：link rocev2/1 state ACTIVE physical_state LINK_UP
# 检查是否有重传
perfquery -l 1 | grep -i "port rcv errors"
# 发现 rcv_errors 持续增长
# 检查MTU设置
ip link show eth0
# eth0: mtu 1500
# 而存储阵列B的接口MTU为9000（Jumbo Frame）问题根源：RoCEv2报文封装了IB数据包后，总长度可能超过1500字节。当服务器A发送一个8KB的RDMA写请求时，IP层需要将其分片为多个1500字节的以太网帧。而存储阵列B虽然支持9000字节MTU，但中间三层交换机接口MTU设置为1500，导致分片后的报文在交换机上被丢弃（因为IP分片重组在接收端进行，交换机不负责重组）。
解决方案：
- 将服务器A、存储阵列B及所有中间交换机接口的MTU统一设置为9000；
- 或者启用RoCEv2的
IP fragmentation功能（不推荐，会显著增加CPU开销）； - 更优做法：在RoCE网卡上启用
UDP segmentation offload，让网卡硬件处理大报文分段。
复盘要点：RoCEv2的MTU问题在混合组网中极具隐蔽性——因为普通TCP流量（如SSH、管理面）使用1500字节MTU完全正常，只有RoCE流量会触发分片。排查时应使用ping -M do -s 8972（ICMP携带DF标志）测试端到端MTU，而非仅检查接口配置。
2.5 误区与复盘：RoCE与IB混合组网的典型认知偏差
在长期排障实践中，以下误区反复出现，值得专门总结：
| 误区描述 | 实际真相 | 排障影响 |
|---|---|---|
| “RoCE和IB都是RDMA，可以无缝互通” | RoCEv2与IB使用不同的报文格式和寻址方式，不能直接互通，必须通过路由器或网关转换 | 混合组网中误以为两端可以直连，实际需要配置IB-to-RoCE网关 |
| “PFC开启后网络就是无损的” | PFC只保护特定优先级队列，且可能引发死锁或公平性问题 | 忽略PFC死锁检测，导致故障时无法自愈 |
| “ECN标记等同于TCP的ECN” | RoCE的ECN反馈机制依赖网卡驱动实现，不同厂商实现差异大 | 跨厂商设备混用时，ECN协商失败导致拥塞控制失效 |
| “IB子网管理器（SM）可以管理RoCE网络” | RoCE没有SM概念，路径计算由IP路由完成 | 误用ibnetdiscover排查RoCE拓扑，得到错误结果 |