📚 课程目录第2章 RoCE基础

RoCE基础：RoCEv1/v2协议栈、帧格式、与以太网和IB的对比

核心原理：从IB到以太网的“协议移植”

RoCE（RDMA over Converged Ethernet）的本质，是将InfiniBand（IB）网络中成熟的RDMA（远程直接内存访问）语义与机制，移植到以太网物理与链路层之上。IB网络凭借其无损、高可靠的传输特性，天然适合RDMA；而以太网成本低、部署广，却存在丢包与拥塞问题。RoCE的出现，正是为了在“普通以太网硬件”上获得接近IB的RDMA能力，同时保留IB协议栈中上层（网络层以上）的完整语义。

理解RoCE的关键，在于区分其两个版本对“承载层”的不同选择：

RoCEv1：将IB的报文直接封装在以太网类型字段（EtherType 0x8915）中，要求两端必须处于同一二层广播域（即同一VLAN），无法跨子网路由。
RoCEv2：在IB报文之外，额外添加IP头（IPv4或IPv6）和UDP头（目的端口4791），使报文可被三层路由转发，从而支持跨子网组网，成为当前数据中心的主流选择。

从协议分层看，RoCEv1/v2都保留了IB传输层（可靠连接RC、不可靠数据报UD等）与报文语义，仅替换了链路层之下的承载方式。这种“上层不变、下层替换”的设计，使得上层RDMA应用无需修改即可运行在以太网上。

  核心要点：RoCEv1是“二层承载”，RoCEv2是“三层承载”。RoCEv2通过UDP封装实现了路由能力，但也因此引入了IP分片、ECMP哈希不均等新问题，这些将在后续拥塞控制章节中详细展开。

帧格式详解：RoCEv1与RoCEv2的报文结构差异

RoCEv1的帧格式相对简单，它直接复用以太网II帧头，将EtherType设置为0x8915，随后紧跟IB的LRH（Local Route Header，12字节）、GRH（Global Route Header，40字节）以及BTH（Base Transport Header，12字节）等IB协议头。由于没有IP和UDP头，RoCEv1报文无法被传统三层设备识别和路由，只能依赖二层交换。

RoCEv2的帧格式则是在IB GRH之前插入了IP头和UDP头。具体而言，以太网帧头之后是IP头（IPv4通常20字节，IPv6为40字节），IP头之后是UDP头（8字节），UDP目的端口固定为4791（IANA分配的RoCEv2端口）。UDP头之后才是IB的BTH及后续报文。值得注意的是，RoCEv2中IB的GRH仍然保留，但通常不再用于路由（因为IP头已承担此功能），而是用于携带全局ID等信息。

这种封装差异带来了几个关键影响：

MTU限制：RoCEv2因额外增加IP+UDP头（至少28字节），有效载荷空间减少。若以太网MTU为1500字节，RoCEv2最大IB Payload约为1448字节（需扣除IB BTH等），而RoCEv1约为1472字节。实际部署中常启用巨型帧（MTU 9000）以提升吞吐。
ECMP支持：RoCEv2的UDP源端口可由网卡基于流特征动态生成，从而在数据中心网络中实现基于五元组的负载均衡（ECMP）。RoCEv1因无IP/UDP头，无法参与ECMP哈希。
拥塞信号：RoCEv2的IP头中ECT/CE位可用于ECN（显式拥塞通知），配合DCQCN等拥塞控制算法实现端到端降速。RoCEv1则只能依赖二层PFC（优先级流控）进行链路级流控。

方法流程：如何识别与解析RoCE报文

在实际网络运维中，抓包分析是定位RoCE问题的第一步。以下是通过Wireshark或tcpdump识别RoCEv1/v2报文的关键流程：

抓取报文：在服务器网卡或交换机镜像端口执行tcpdump -i eth0 -s 96 -w roce.pcap，注意RoCEv2使用UDP 4791端口，可加过滤条件udp port 4791。
快速判别版本：查看以太网帧的EtherType字段——若为0x8915则为RoCEv1；若为0x0800（IPv4）且UDP目的端口为4791，则为RoCEv2。
解析IB头部：在Wireshark中，识别出RoCE报文后，展开IB BTH（Base Transport Header）查看OpCode（操作码），例如0x00表示RC的SEND，0x01表示RC的WRITE，0x02表示RC的READ请求等。
检查PSN与丢包：记录BTH中的PSN（Packet Sequence Number），若发现序列号跳变，则说明存在丢包或乱序。

# 抓取RoCEv2流量（过滤UDP 4791）
tcpdump -i eth0 -nn 'udp port 4791' -c 100 -w roce_v2.pcap

# 抓取RoCEv1流量（过滤EtherType 0x8915）
tcpdump -i eth0 -nn 'ether proto 0x8915' -c 100 -w roce_v1.pcap

# 查看抓包结果中的RoCEv2报文摘要
tcpdump -nn -r roce_v2.pcap -c 5
输出示例：
12:33:45.123456 IP 10.0.0.1.4791 > 10.0.0.2.4791: UDP, length 1448
        0x0000:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000

案例/场景：RoCEv1与v2的典型部署对比

对比维度	RoCEv1	RoCEv2
承载网络	仅限二层以太网（同VLAN）	三层IP网络（可跨子网/路由）
封装开销	无IP/UDP头，开销小	额外28字节（IPv4）或60字节（IPv6）
拥塞控制	依赖PFC（链路级流控）	支持ECN + DCQCN（端到端）
多路径	不支持ECMP（无IP头哈希）	支持ECMP（UDP源端口哈希）
适用场景	小型单集群、低延迟要求极高	大规模数据中心、跨机柜/跨园区

一个典型的迁移案例：某金融企业原先在单个接入交换机下部署RoCEv1存储网络，随着业务扩展需要跨汇聚层连接两个机房。RoCEv1无法跨三层路由，被迫使用VXLAN等隧道技术，导致性能下降。迁移至RoCEv2后，存储流量可直接通过IP路由转发，配合DCQCN拥塞控制算法，在跨机房场景下仍能保持90%以上的线速吞吐。

误区/复盘：RoCE版本选择中的常见错误

误区一：认为RoCEv2一定优于RoCEv1。实际上，RoCEv2虽然支持路由，但引入了UDP封装和IP层处理，增加了延迟（约1-2μs）。在极低延迟要求的单一二层环境中，RoCEv1可能更优。选择应基于实际组网需求，而非盲目追新。

误区二：忽略RoCEv2对ECMP哈希的依赖。RoCEv2的UDP源端口由网卡生成，但部分老旧网卡或驱动可能生成固定源端口，导致所有流量哈希到同一物理链路上，造成链路拥塞。部署前应验证网卡是否支持动态UDP源端口生成。

复盘建议：在规划RoCE网络时，先画出物理拓扑，明确是否需要跨子网通信。若需要，直接选择RoCEv2；若仅在单个接入交换机下，可评估RoCEv1的延迟优势。同时，无论选择哪个版本，都必须提前规划PFC/ECN等无损网络机制，否则RDMA性能将因丢包而急剧恶化。

最后需要强调的是，RoCEv1与RoCEv2并非互斥关系，同一张网卡可以同时支持两种模式（通过配置选择）。但在一个网络中，所有通信节点必须使用相同的RoCE版本，否则无法互通。版本切换时，需同步调整交换机配置（如PFC优先级映射、ECN阈值等），并验证端到端连通性。