Wireshark抓包实战：深度解析RoCEv2、RRoCE与IB协议报文结构与故障排查

1. 项目概述：为什么我们需要拆解RoCEv2、RRoCE与IB报文？

如果你是一名数据中心网络工程师、高性能计算（HPC）架构师，或者正在研究低延迟网络技术，那么“RoCEv2”、“RRoCE”和“IB”这几个词对你来说一定不陌生。它们代表了当前数据中心内部，尤其是AI/ML训练、分布式存储和金融交易等场景下，追求极致网络性能的几种核心协议。然而，无论是技术文档还是厂商白皮书，往往都侧重于各自协议的优点和配置，很少将它们放在一起，从最底层的网络报文层面进行直观的对比。这就导致了一个问题：我们理论上知道RoCEv2跑在UDP/IP上，IB是独立的链路层协议，但它们在线上“长”什么样？RRoCE这个“路由版RoCE”又带来了哪些报文结构上的变化？不搞清楚这些，当网络出现性能抖动、丢包或者兼容性问题时，排查起来就像隔着一层毛玻璃看问题，始终不得要领。

这正是本次“抓包实战”的核心价值所在。我们不满足于概念，而是要拿起 Wireshark 这把“网络手术刀”，亲手捕获、解析并并排对比这三种协议的原始报文。通过一步步的拆解，你将能清晰地看到：

• RoCEv2 ：一个承载在传统UDP/IP网络之上的“贵宾”，它的InfiniBand传输层头是如何“嵌入”到IP报文里的。
• RRoCE ：当RoCEv2需要跨越三层网络边界时，它经历了怎样的“包装”和“寻址”改造。
• IB ：作为原生贵族，它的报文结构是如何从一开始就为高性能而设计的，与前者有何根本不同。

理解这些差异，不仅能让你在技术选型时心中有数，更能让你在故障排查时，通过几个关键的报文字段（如BTH头中的OpCode、DETH头中的QPN/QKey）快速定位问题根源——是应用配置错误，还是网络路由或ACL策略拦截，亦或是网卡Offload功能未生效。接下来，我们就从环境准备开始，一步步揭开它们的神秘面纱。

2. 环境准备与抓包策略设计

工欲善其事，必先利其器。一次成功的抓包分析，80%的功夫在于前期的环境准备和策略设计。盲目抓包只会得到海量无关数据，让你陷入信息的泥潭。

2.1 软硬件环境搭建

首先，你需要一个能够产生或转发这三种协议流量的实验环境。对于个人学习或概念验证，我有以下几种推荐方案：

1. 基于Linux的软实现环境（最经济灵活） ：

   • 主机 ：一台安装有最新版Linux发行版（如Ubuntu 22.04 LTS或CentOS Stream 9）的物理机或性能足够的虚拟机（建议预留至少4核CPU、8GB内存）。虚拟机方案需要注意虚拟交换机的性能可能成为瓶颈。
   • 软件栈 ：
     • RDMA核心 ：安装 rdma-core 软件包。这是用户态RDMA库和内核驱动的基础。
     • IPoIB ：安装 libibverbs-utils 和 infiniband-diags ，用于配置IP over InfiniBand，这是让IB网络兼容TCP/IP应用的关键。
     • Perftest ：安装 perftest 包，它包含了 ib_send_bw 、 ib_write_lat 等强大的RDMA性能测试工具，是我们生成流量的“发动机”。
   • 网络 ：至少需要两台这样的主机，并通过一个支持二层交换的以太网交换机（用于RoCEv2）或InfiniBand交换机（用于IB）连接起来。对于RRoCE，则需要一个支持三层路由的网络设备（如Linux主机开启IP转发，或一台支持ECMP的三层交换机）。

2. 商用网卡与交换机环境（最贴近生产） ：

   • 网卡 ：配备支持RoCEv2的以太网卡（如Mellanox ConnectX-5/6/7系列，或Intel E810系列）或InfiniBand HCA卡（如Mellanox ConnectX-6/7 IB版）。
   • 交换机 ：支持数据中心桥接（DCB）和显式拥塞通知（ECN）的以太网交换机（用于RoCEv2），或InfiniBand交换机。
   • 这种环境能测试硬件Offload（如CRC校验、数据分段）的真实效果，但成本较高。

我的实操心得 ：对于初学者，强烈建议从 方案1 开始。利用两台虚拟机配合Linux Bridge或Open vSwitch构建一个简单的二层网络，先搞定RoCEv2的抓包和分析。这能让你专注于协议本身，避免初期被复杂的硬件配置和驱动问题困扰。等概念清晰后，再迁移到物理机或更复杂的拓扑中。

2.2 Wireshark配置与抓包点选择

Wireshark是我们的主分析工具，正确的配置至关重要。

• 安装与版本 ：请务必从 Wireshark官网 下载最新稳定版。新版通常包含更多协议解析器（Dissector）和更完善的RDMA协议支持。
• 关键配置 ：
  1. 开启“解析传输层” ：在“编辑” -> “首选项” -> “协议” -> “UDP”中，确保勾选了“尝试解析UDP流为DCE/RPC”。虽然名字叫DCE/RPC，但这个选项有助于Wireshark更积极地尝试解析UDP端口之上的自定义协议，对识别RoCEv2流量有奇效。
  2. 准备IB/RDMA解析器 ：Wireshark默认可能未启用所有IB解析器。你需要确认已安装或启用了 opendissectors 中的相关插件。可以在“帮助” -> “关于Wireshark” -> “插件”中查看。
• 抓包点策略（这是核心！） ：
  • RoCEv2 ：在 发送端或接收端的物理网卡接口 上抓包。因为RoCEv2报文最终是以太网帧，在这里你能看到完整的Ethernet -> IP -> UDP -> InfiniBand传输层的封装结构。 避免在Docker容器或某些虚拟网络接口上抓包 ，这些地方报文可能已被转换或丢失关键头部信息。
  • RRoCE ：抓包点需要 至少两个 。一是在 发送主机 的出口，抓取原始的RoCEv2报文；二是在 路由设备 （如Linux路由器）的“出方向”接口，或者 接收主机 的入口。在路由设备上，你能看到IP头的变化（TTL减1，源/目MAC地址改变）；在接收主机上，你看到的是经过路由封装后的报文。
  • IB ：在 发送或接收端的IB接口 （如 ib0 ）上抓包。这里捕获到的是纯粹的InfiniBand链路层帧，没有Ethernet和IP头的“累赘”。

注意 ：在Linux上，你可能需要 sudo 权限来运行Wireshark或 tcpdump 进行抓包。一个更安全高效的做法是使用 tcpdump 抓取原始数据包保存为pcap文件，再用Wireshark离线分析。例如： sudo tcpdump -i eth0 -s 0 -w rocev2.pcap port 4791 抓取RoCEv2默认端口的流量。

3. 核心协议报文结构与Wireshark解析实战

现在，让我们进入最激动人心的环节：用Wireshark打开抓取的报文，像解剖麻雀一样，逐层解析它们的结构。我会用对比表格和关键字段截图（文字描述）来清晰展示异同。

3.1 RoCEv2报文深度解析

RoCEv2（RDMA over Converged Ethernet version 2）是当前应用最广泛的协议。它的核心思想是： 在标准的UDP/IPv4或IPv6报文载荷中，承载InfiniBand的传输层和数据层头。

抓包示例与分层拆解 ：

当你用Wireshark打开一个RoCEv2数据包（例如一个 ib_write_lat 测试产生的写操作包），解码窗口通常会显示如下层次结构：

Frame (物理层信息)
Ethernet II (链路层)
Internet Protocol Version 4 (网络层)
User Datagram Protocol (传输层)
InfiniBand (Transport) (RDMA传输层)
    BTH: Base Transport Header
    RETH: RDMA Extended Transport Header (对于Write操作)
InfiniBand (Data) (RDMA数据层)
    Payload: 实际的应用数据

关键字段解读 ：

1. UDP层 ：

   • 目的端口 ：默认为 4791 。这是IANA为RoCEv2分配的官方端口。这是Wireshark能自动识别并解析上层为InfiniBand协议的关键依据。
   • 源端口 ：通常是一个随机的高端口。

2. InfiniBand传输层 - BTH头 ： 这是RDMA操作的“指令头”，所有RDMA操作都有。

   • OpCode ：操作码。这是最重要的字段之一，直接定义了报文类型。例如：
     • 0x0a : RDMA WRITE FIRST
     • 0x0b : RDMA WRITE MIDDLE
     • 0x0c : RDMA WRITE LAST
     • 0x10 : RDMA READ REQUEST
     • 0x11 : RDMA READ RESPONSE FIRST
     • 0x14 : SEND FIRST
   • PSN ：数据包序列号。用于数据包的按序交付、丢包检测和重传。 在抓包分析网络乱序或丢包时，PSN的连续性是你首要关注的指标。
   • DstQP ：目标队列对号。标识接收端用于处理此报文的特定队列对（QP）。如果应用配置错误，这里可能会指向一个不存在的QP，导致接收端静默丢弃报文。

3. InfiniBand传输层 - 扩展头 ： 根据OpCode不同，BTH后面会跟着不同的扩展头。

   • RETH ：用于RDMA Write和Read Request。包含 远程虚拟地址（RVA） 和 数据长度（DMA Length） 。Write操作的数据直接跟在RETH后面；Read Request则用RETH告诉对方“请把这段内存的数据读给我”。
   • ImmDt ：用于Send with Immediate Data操作。一个32位的立即数，随数据一起送达，可用于快速通知对端。

4. InfiniBand数据层 ： 就是实际的用户数据载荷。

Wireshark实战技巧 ：

• 在Wireshark的过滤栏输入 udp.port == 4791 ，可以快速筛选出所有RoCEv2流量。
• 点击 InfiniBand (Transport) 层，Wireshark会在下方窗格高亮显示BTH头的原始字节，并给出每个字段的友好解释。你可以清晰地看到OpCode被解析成了可读的操作名。
• 如果你发现Wireshark没有正确解析，可以尝试右键点击UDP层 -> “解码为...” -> 在“当前”列选择 InfiniBand 。这手动指定了解析方式。

3.2 RRoCE报文解析与路由封装观察

RRoCE（Routed RoCE）解决了RoCEv2的一个关键限制： 只能在同一个二层网络（同一个子网）内通信 。RRoCE通过将整个RoCEv2报文（从UDP头开始）作为载荷，封装在另一个IP/UDP头中，从而实现跨三层网络的路由。

抓包对比分析 ：

在 发送主机 抓到的包，看起来和普通的RoCEv2包一模一样。但当你到 路由设备 或 接收主机 抓包时，你会看到截然不同的结构：

Frame
Ethernet II
Internet Protocol Version 4 (外层IP头)
User Datagram Protocol (外层UDP头)
[封装载荷开始]
    Internet Protocol Version 4 (内层IP头，即原始的RoCEv2 IP头)
    User Datagram Protocol (内层UDP头，目的端口4791)
    InfiniBand (Transport) (原始的BTH等头)
    InfiniBand (Data)
[封装载荷结束]

核心变化与字段解读 ：

1. 外层IP/UDP头 ：

   • 外层IP头 ：源IP是发送主机的IP，目的IP是 接收主机的IP （注意，是最终目标，不是路由器）。
   • 外层UDP头 ：目的端口号是一个 新的、用于标识RRoCE封装协议的端口 。不同厂商实现可能不同（例如，有些使用 4791 ，有些使用其他端口）。这需要根据你的网络设备配置来确定。
   • 关键点 ：路由器根据 外层IP头 进行路由决策，完全不需要理解内层封装的RoCEv2是什么。这实现了与现有IP网络基础设施的无缝集成。

2. 内层IP/UDP头 ：

   • 它们被完整地保留，作为载荷的一部分。其源/目IP地址是发送和接收主机的 原始地址 ，目的端口依然是 4791 。
   • 当报文到达接收主机后，网络驱动或硬件会剥离外层封装，将内层的RoCEv2报文提交给协议栈处理，对上层应用透明。

Wireshark实战技巧 ：

• Wireshark可能无法自动识别这种双层封装。你需要手动帮助它。
• 找到外层UDP层，右键点击 -> “解码为...”。在弹出窗口中，找到该UDP端口对应的行，在“当前”列的下拉菜单中，尝试选择 VXLAN 、 GENEVE 或 GRE 等隧道协议。如果都不对，你可能需要自定义解析器。更简单的方法是，直接查看内层载荷的原始字节，如果能看到 0x1b （BTH头的起始模式）和 4791 端口，就能确认这是RRoCE封装。
• 过滤时，可以使用 udp.dstport == <外层封装端口> 来筛选RRoCE流量。

3.3 InfiniBand原生报文解析

InfiniBand（IB）是这一切的“祖师爷”。它的报文是原生的，不依赖于任何其他网络协议栈。

抓包示例与分层拆解 ：

在IB接口上抓包，Wireshark显示的结构非常简洁有力：

Frame
InfiniBand (链路层)
InfiniBand (Transport) (传输层)
InfiniBand (Data) (数据层)

关键字段解读 ：

1. InfiniBand链路层头 ：

   • 包含了 本地标识（LID） 和 全局路由头（GRH，用于跨子网通信） 等信息。LID类似于以太网中的MAC地址，但在IB网络中是一个16位的短标识，用于二层交换。
   • 与RoCEv2的根本区别 ：这里没有Ethernet MAC地址，没有IP地址，也没有UDP端口。IB网络使用LID和GID（全局标识，类似IP地址）进行寻址。

2. InfiniBand传输层头 ：

   • BTH头 ：与RoCEv2中的BTH头 完全同源同构 。OpCode、PSN、DstQP等字段的定义和功能一模一样。这是因为RoCEv2本质上就是借用了IB的传输层语义。
   • 扩展头 ：同样包含RETH、ImmDt等，与RoCEv2一致。

3. 数据层 ：用户数据。

Wireshark实战技巧 ：

• 在接口选择时，务必选择 ib0 、 ib1 这样的IB接口，而不是 eth0 。
• 过滤语法不同。例如，要过滤特定QP的流量，可以使用 ib.dstqp == <QP号> 或 ib.srcqp == <QP号> 。
• 由于没有IP/UDP层，传统的基于五元组的过滤方式不再适用。分析时需要更关注LID、GID和QP信息。

3.4 异同对比总览

为了让你一目了然，我将三者的核心差异总结如下表：

我的核心观察 ：从报文结构可以清晰看出， RoCEv2是IB传输层在IP网络上的“适配器” ，而 RRoCE是这个适配器的“长途运输包装箱” 。IB协议本身的设计极为精简高效，所有头部都是为了RDMA操作最优而设计。RoCEv2和RRoCE为了兼容现有网络，不得不增加封装开销，这也是它们在极致延迟上始终略逊于原生IB的原因之一。

4. 实战抓包案例：从建立连接到数据传输

光看静态报文不够过瘾，我们模拟一个完整的RDMA Write流程，用Wireshark追踪整个过程。假设有两台主机：Client (192.168.1.10) 和 Server (192.168.1.20)。

4.1 连接建立与配置交换

在RDMA通信开始前，双方需要建立连接。这通常通过一个“控制路径”来完成，例如使用 ibv_rc_pingpong 这样的示例程序，或者依赖像 RDMACM （RDMA通信管理器）这样的服务。控制信息通常通过TCP或IB的UD（不可靠数据报）传输。

抓包观察 ：

1. 启动Server端： ibv_rc_pingpong -g 0 -d mlx5_0
2. 启动Client端： ibv_rc_pingpong -g 0 -d mlx5_0 192.168.1.20
3. 在Client端的网卡上抓包。

你会先看到一些TCP或UDP的流量（端口可能是7471或7472，这是RDMACM的默认端口），交换诸如 本地QP号、PSN初始值、GID信息 等。Wireshark可能无法解析这些私有协议格式，但你能看到连接建立的握手过程。之后，真正的RDMA流量才开始。

4.2 RDMA Write操作报文序列分析

连接建立后，Client发起一个RDMA Write操作。我们抓取这个数据流。

Wireshark中的报文序列可能如下 ：

1. SEND操作（可选，用于发送元数据或信号） ：

   • 过滤器： ib.opcode == 0x14 (SEND FIRST) 或包含 0x15 (SEND MIDDLE)、 0x16 (SEND LAST)。
   • 这个SEND报文里可能包含了一个描述远程内存地址和长度的“描述符”。Server端的应用需要预先准备好内存并告知Client这个描述符。

2. RDMA WRITE操作 ：

   • WRITE FIRST ( ib.opcode == 0x0a )：这是第一个数据包。展开BTH头，你能看到 DstQP （Server的QP号）。紧接着的RETH头里，包含了 RVA （远程虚拟地址，例如 0x7f2a8a000000 ）和 数据长度 。后面跟着第一部分数据载荷。
   • WRITE MIDDLE ( ib.opcode == 0x0b )：如果数据很大，一个包装不下，会有多个MIDDLE包。它们只有BTH头（包含连续的PSN）和数据， 没有RETH头 。因为RVA已经在FIRST包中指定了，后续包只需按序追加数据即可。
   • WRITE LAST ( ib.opcode == 0x0c )：最后一个数据包。同样只有BTH头和数据。
   • 关键点 ：在整个Write序列中，只有FIRST包需要RETH头来指定起始地址，这极大地减少了协议开销。所有包的PSN必须严格连续。

3. ACK确认（对于可靠连接RC） ：

   • 对于RC（可靠连接）服务类型，Server在成功将数据写入内存后，会返回一个 ACK 报文。
   • 过滤器： ib.opcode == 0x13 (ACKNOWLEDGE)。
   • 查看ACK报文的BTH头，其中的 PSN 字段是对应它确认的那个数据包的PSN。 通过对比发送的WRITE PSN和接收的ACK PSN，可以判断是否有丢包或乱序。

实操心得 ：在分析一个RDMA流时，我习惯先用 ib.dstqp == <目标QP> 或 ib.srcqp == <源QP> 过滤出特定QP的流量。然后， 按照PSN排序 （在Wireshark表格中点击PSN列），这样可以清晰地看到数据包的顺序流。如果发现PSN不连续，中间有缺失，那很可能发生了丢包，这是网络或接收端拥塞的强烈信号。

5. 高级故障排查与性能分析实战

掌握了报文结构，Wireshark就从一个查看器变成了强大的诊断工具。下面分享几个我实践中遇到的典型问题及排查思路。

5.1 常见问题排查速查表

5.2 性能深度分析：ECN与PFC的报文证据

在无损网络中，拥塞管理至关重要。Wireshark能直观展示两种主要机制的运作。

• ECN（显式拥塞通知） ： 当网络设备发生拥塞时，它会在经过的IP报文头中标记ECN位。对于RoCEv2，支持ECN的网卡在收到被标记的报文后，会生成一个 CNP（拥塞通知包） 返回给流量发送方，通知其降速。

  • Wireshark过滤 ： ib.opcode == 0x81 可以过滤出CNP报文。
  • 分析 ：查看CNP报文，里面会包含引发拥塞的原始流的QP号和PSN信息。如果你在流量中看到大量CNP，说明网络存在持续拥塞，需要调整流量模式或检查PFC配置。

• PFC（基于优先级的流量控制） ： 这是一种“暂停”机制。当接收端缓冲区快满时，它会向发送方发送一个 PFC暂停帧 （以太网类型0x8808），告诉对方“暂停发送特定优先级的流量”。

  • Wireshark过滤 ： eth.type == 0x8808
  • 分析 ：捕获到PFC帧后，查看其内容，可以知道是针对哪个优先级（Priority）发出的暂停指令，以及暂停时间。频繁的PFC帧意味着链路一端有瓶颈，可能导致HOL（队头阻塞）问题。

一个典型的排障流程 ：发现吞吐量下降 -> 抓包 -> 发现大量CNP和零星PFC帧 -> 判断网络存在拥塞 -> 检查交换机队列配置、应用流量突发情况 -> 调整PFC阈值或应用发送节奏。

5.3 Wireshark高级功能应用

1. 流量图 ： 统计 -> 流量图 。对于RDMA流，选择 Limit to display filter 并应用你的QP过滤条件。这可以图形化地展示PSN序列、ACK响应时间，一眼就能看出乱序、丢包或延迟间隙。
2. 专家信息 ：Wireshark左下角的“专家信息”标签会汇总警告和错误。例如，它可能会提示“Previous segment not captured”，这暗示了可能的丢包。
3. IO图表 ： 统计 -> IO图表 。你可以添加多个过滤器，例如分别绘制RC、UC、UD流量的吞吐量曲线，或者绘制带有ECN标记的报文速率，直观对比不同服务类型或拥塞状态下的流量特征。
4. 跟踪流 ：在某个RDMA报文上右键 -> 跟踪 -> UDP流 （对于RoCEv2）或 跟踪 -> InfiniBand流 。这会将属于同一个会话的所有报文提取出来，并按时间顺序排列，非常适合分析一个完整的事务。

6. 总结与延伸思考

通过这一趟从理论到实战的Wireshark抓包之旅，我们亲手剥离了RoCEv2、RRoCE和IB协议的外衣，直视其骨骼。你会发现，无论上层封装如何变化，其核心—— InfiniBand的传输层语义（BTH, RETH等） ——始终如一。这正是RDMA高性能的基石：一个为零拷贝、内核旁路、远程直接内存访问而设计的精简协议层。

我个人最深刻的体会是 ：在RDMA网络里， PSN 和 OpCode 是你最忠实的朋友。几乎所有的顺序、丢包、操作类型问题，都能从这两个字段找到突破口。而 QPN 则是连通应用的钥匙，一个配置错误就会让整个通信静默失败。

对于想进一步深入的同学，我建议可以尝试：

1. 对比不同服务类型 ：用 ibv_uc_pingpong （不可靠连接）和 ibv_ud_pingpong （不可靠数据报）进行测试抓包，观察它们的报文序列和ACK机制与RC有何不同。你会发现UC没有ACK，UD的报文头甚至没有PSN。
2. 分析大型消息 ：发送一个远超MTU的消息，观察Wireshark如何展示被分割成的多个 WRITE FIRST/MIDDLE/LAST 包序列，理解RDMA的“分段”与TCP“分片”在概念上的不同。
3. 制造故障 ：在测试环境中，手动丢弃一个PSN连续的包（可以用 tc 命令模拟），观察后续的ACK和可能的恢复行为。

最后，记住一点：网络协议的本质是约定。Wireshark让我们能看见这些约定在线上是如何被一丝不苟（或出现偏差）地执行的。这份“看见”的能力，是定位和解决一切复杂网络问题最强大的起点。当你再遇到令人头疼的RDMA性能问题时，不妨静下心来，抓个包，从第一个比特开始，跟着协议的逻辑走一遍，真相往往就藏在那些十六进制数字的背后。