Mellanox -- tcpdump抓包

在当今高性能计算与大规模分布式存储的舞台上，RDMA技术正扮演着越来越关键的角色。它绕过操作系统内核，直接在应用与网卡间传输数据，带来了极低的延迟与极高的吞吐量。然而，这种“旁路”特性也让传统的网络监控手段部分失效。当你的RDMA应用性能不达预期，或者出现难以捉摸的通信故障时，如何像侦探一样，深入网络底层，抓取并解读那些高速流转的RoCE数据包，就成了开发者与运维工程师必须掌握的硬核技能。本文将带你从零开始，手把手搭建抓包环境，深入剖析RDMA报文结构，并分享一系列从实战中总结出的避坑经验，助你精准定位网络层问题。

1. 环境构建：打造你的RDMA抓包工具箱
   工欲善其事，必先利其器。分析RDMA流量，你需要一套能够识别RoCE协议栈的专用工具链。默认情况下，许多Linux发行版自带的tcpdump可能无法正确解析或捕获RDMA网卡（如Mellanox的mlx5系列）上的特定流量。因此，从源码编译是获得完整功能的关键第一步。

1.1 编译支持RDMA的tcpdump与libpcap
tcpdump的强大抓包能力依赖于底层的libpcap库。为了确保对InfiniBand和RoCE流量的完整支持，我们需要从the-tcpdump-group维护的官方仓库获取最新源码进行编译。

首先，解决编译依赖。在Ubuntu/Debian系统上，你需要安装必要的开发工具和库：

sudo apt-get update
sudo apt-get install -y git build-essential autoconf automake libtool bison flex
一键获取完整项目代码
bash
接下来，按顺序编译安装libpcap和tcpdump：

获取并编译libpcap：

git clone https://github.com/the-tcpdump-group/libpcap.git
cd libpcap
./autogen.sh
./configure --prefix=/usr/local
make
sudo make install
一键获取完整项目代码
bash
./autogen.sh会生成配置脚本，./configure检查系统环境并生成Makefile，--prefix指定了安装目录。执行sudo ldconfig更新动态链接库缓存，确保系统能找到新安装的库。

获取并编译tcpdump：

git clone https://github.com/the-tcpdump-group/tcpdump.git
cd tcpdump
./autogen.sh
./configure --prefix=/usr/local
make
sudo make install
一键获取完整项目代码
bash
编译完成后，验证安装是否成功，并确认其支持的网络接口类型：

tcpdump --version
tcpdump -D | grep mlx
一键获取完整项目代码
bash
如果看到类似mlx5_0、mlx5_1的接口，说明编译成功，并能识别你的RDMA网卡。

注意：编译过程如果遇到configure: error: cannot find pcap-config的错误，通常是因为上一步libpcap安装后，其pcap-config工具未被系统路径识别。可以尝试在configure时显式指定其路径，如./configure --with-pcap=/usr/local。

1.2 配置Wireshark以增强RDMA解析
Wireshark是我们的“解剖刀”，用于可视化分析抓取到的数据包。虽然通过包管理器安装的Wireshark通常已包含基础协议解析器，但对于RDMA的深度分析，确保其使用最新协议定义文件至关重要。

通过APT安装Wireshark：

sudo apt-get install -y wireshark
一键获取完整项目代码
bash
安装过程中，系统可能会询问是否允许非root用户抓包。为了操作方便，建议将当前用户加入wireshark组：

sudo usermod -aG wireshark $USER
一键获取完整项目代码
bash
需要重新登录才能使组权限生效。

Wireshark对RoCE（特别是v2）协议的支持在持续演进。为了获得最佳的解析效果，特别是对IB传输层头（BTH）和载荷的解析，建议定期从Wireshark官网更新协议插件，或确保你的发行版提供了较新的Wireshark版本（3.6以上为佳）。

2. 精准捕获：tcpdump抓取RDMA流量的核心技巧
   有了趁手的工具，下一步就是去“案发现场”采集证据。在RDMA环境中抓包，与普通以太网抓包有显著区别，参数设置和时机把握直接影响抓包结果的有效性。

2.1 识别与选择正确的网络接口
这是第一个容易踩坑的点。在支持RDMA的服务器上，你可能会看到多种与网卡相关的接口名：

以太网接口：如eth0、ens1f0。这是承载RoCE v2流量的物理以太网接口。在此接口抓包，能看到UDP封装的RoCE报文。
RDMA设备接口：如mlx5_0、mlx5_1。这是Mellanox驱动暴露的RDMA Verbs接口。在此接口抓包，能捕获到更底层的InfiniBand语义流量，对于分析RC/UC/QP状态等高级信息更有帮助。
如何选择？

目标为分析网络路径问题（如丢包、路由）：应在以太网接口（如ens1f0）上抓包。因为RoCE v2报文最终是在IP网络上传输的，丢包、乱序等问题发生在这个层面。
目标为分析RDMA传输层逻辑（如ACK、序列号）：应在RDMA设备接口（如mlx5_0）上抓包。这里能看到完整的IB传输层协议头。
使用ip link show或ibv_devices配合ibv_devinfo可以帮你理清对应关系。

2.2 执行抓包命令与参数详解
一个典型的抓取RDMA流量的命令如下：

sudo tcpdump -i mlx5_0 -s 0 -w rdma_capture.pcap 'udp port 4791'
一键获取完整项目代码
bash
让我们拆解每个参数的意义与避坑点：

-i mlx5_0：指定抓包接口。如前所述，根据你的分析目标选择合适的接口。
-s 0：设置抓包长度（snaplen）为0，意为捕获整个数据包，不受默认96字节的限制。这是关键！ RDMA报文（尤其是涉及大数据传输的）可能很长，如果截断，你将丢失关键的载荷信息，导致Wireshark无法解析后续协议层。
-w rdma_capture.pcap：将原始数据包写入文件，格式为标准的pcap。
'udp port 4791'：过滤表达式。RoCE v2标准使用UDP目的端口4791。加上此过滤器可以极大减少抓取的无关流量（如管理流量、其他应用流量），聚焦于RDMA数据流，并减小pcap文件体积。
提示：在开始抓包前，最好先确定你的RDMA流量是否确实使用了4791端口。有些定制化环境可能使用其他端口。可以先不用过滤器抓几秒钟，然后用tcpdump -nn -r rdma_capture.pcap | head -20快速查看UDP端口号。

2.3 触发RDMA流量与抓包时机
抓包命令在后台运行后，你需要生成RDMA流量。常见的方式有：

使用性能测试工具：如Mellanox的perftest套件。
服务端：ib_send_bw -d mlx5_0
客户端：ib_send_bw -d mlx5_0 <server_ip>
运行实际应用：启动你的分布式AI训练任务（如使用NCCL）、分布式数据库或存储应用。
避坑指南：控制抓包时长与范围

问题：长时间抓取高带宽RDMA流量会产生巨大的pcap文件（每秒可达GB级），很快填满磁盘。
解决方案：
使用-c参数限制抓包数量：sudo tcpdump -i mlx5_0 -s 0 -c 10000 -w rdma_capture.pcap 只抓1万个包。
更精确的过滤：如果你知道通信的对端IP，可以增加过滤条件，如'host 10.110.0.21 and udp port 4791'。
分阶段抓包：在应用启动初期、稳定运行期、出现问题时分别进行短时抓包，对比分析。
抓取足够的数据后，在终端按Ctrl+C停止tcpdump。

3. 庖丁解牛：在Wireshark中解析RoCE协议栈
   现在，我们得到了一个包含RDMA流量的pcap文件，是时候用Wireshark打开它，像阅读一本打开的书一样解读每一层协议了。

3.1 初始加载与协议着色
将rdma_capture.pcap文件拖入Wireshark。Wireshark会尝试自动解析每个数据包。对于RoCE v2流量，你应该能看到协议列显示为“UDP”和“RRoCE”（Routable RoCE，即RoCE v2）。

为了提高可读性，建议启用针对RDMA的着色规则：

点击“视图” -> “着色规则”。
你可以创建或修改规则，例如，将所有“RRoCE”协议的数据包标记为浅蓝色背景，这样可以在包列表窗口中快速定位RDMA流量。
3.2 逐层解析RoCE v2报文结构
在包列表窗口选中一个RRoCE报文，中间的面板会展示分层的协议详情。理解每一层是诊断问题的基石。从上到下，一个典型的RoCE v2报文包含：

协议层 对应Wireshark解析字段 关键信息与诊断意义
Frame (物理层) Frame X: 512 bytes on wire 数据包的原始长度、捕获时间戳。用于判断报文大小是否异常。
Ethernet II (链路层) Src: a0:36:9f:xx:xx:xx, Dst: a0:36:9f:yy:yy:yy 源和目的MAC地址。验证流量是否在预期的物理链路上。
Internet Protocol Version 4 (网络层) Src: 10.110.0.21, Dst: 10.110.0.25 源和目的IP地址。用于路由追踪、验证IP配置是否正确。RoCE v2要求无损网络，任何IP层的分片（Fragmentation）都可能导致性能严重下降或失败。
User Datagram Protocol (传输层) Src Port: 58891, Dst Port: 4791 UDP端口。确认目的端口为4791。UDP校验和（Checksum）错误可能表明硬件或驱动问题。
IB Transport (BTH) (RDMA传输层) Opcode: RC SendOnly (First), Sev: 0, ... 这是RDMA的核心。包含操作码（Opcode，如Send、Write、Read）、数据段（PSN）、QP号等。PSN不连续或ACK缺失指向丢包或重传。
IB Payload (数据载荷) Data (256 bytes) 实际传输的应用数据。
重点剖析IB传输层（BTH）： 点击展开“InfiniBand Transport (BTH)”层，你会看到类似下面的关键字段：

Opcode：指示RDMA操作类型。例如，RC SendOnly (First)表示一个可靠连接（RC）的Send操作的第一个包。
PSN (Packet Sequence Number)：数据包序列号。在可靠服务（RC）中，PSN用于确认和重传机制。观察PSN是否连续增长。
AckReq (Acknowledge Request)：标志位，指示发送者是否请求接收方立即回复ACK。
QP (Queue Pair)：队列对号，标识唯一的通信端点。可以用于过滤特定QP的流量。
3.3 使用Wireshark高级功能进行诊断
Wireshark不仅仅是查看单个数据包，其统计和过滤功能对于宏观分析至关重要。

流量图（IO Graph）： 点击“统计” -> “I/O图表”。你可以看到带宽随时间的变化曲线。一个平稳的高带宽曲线是健康的。如果出现锯齿状或频繁的零值，可能表明有间歇性拥塞或PFC（优先级流量控制）在起作用（甚至可能是“PFC死锁”的征兆）。

专家信息（Expert Info）： 点击底部状态栏的“专家信息”按钮（通常是一个彩色圆圈）。这里汇总了警告和错误。例如，大量的“Previous segment not captured”警告可能意味着在抓包过程中发生了丢包（可能是抓包进程自身丢包，也可能是网络真实丢包）。

过滤特定流： 在包列表右键点击一个报文，选择“追踪流” -> “UDP流”。Wireshark会创建一个过滤器，只显示该四元组（源IP、源端口、目的IP、目的端口）的完整对话。这对于分析一次具体的RDMA交换过程非常有用。

统计TCP流（虽非TCP，但概念类似）： 对于RC服务，其ACK/PSN机制与TCP有相似性。你可以通过编写显示过滤器，模拟分析“序列号”和“确认号”的行为，例如观察ACK包的PSN与下一个数据包PSN的关系。

4. 实战案例：定位典型RDMA网络问题
   理论结合实践，我们通过几个虚构但常见的场景，演示如何运用上述工具链进行分析。

4.1 案例一：带宽不达预期
症状：使用ib_send_bw测试，带宽远低于网卡规格（例如，100Gbps的网卡只能跑到40Gbps）。

分析步骤：

抓包：在客户端和服务端的以太网接口上同时开始抓包，持续约10秒。
Wireshark分析：
查看报文大小：在Wireshark中，使用统计功能（“统计” -> “分组长度”），查看数据包长度的分布。理想的满带宽传输应该充满MTU大小的包（例如，对于标准以太网，是1500字节；对于开启巨帧（Jumbo Frame）的环境，可能是9000字节）。如果大量是小包（如几百字节），说明应用或协议本身无法有效填充数据链路。
检查I/O图表：查看带宽曲线是否平稳。如果呈周期性波动，可能与PFC或ECN有关。你需要检查交换机的PFC配置和网卡的ECN设置。
查找重传：使用显示过滤器 roce && roce.bth.ackreq == 1 过滤出所有请求ACK的包。如果这些包之后很快有相同PSN的包出现，可能是重传。大量重传会严重消耗有效带宽。
可能原因与解决：
MTU不匹配：确认交换机、服务器两端网卡的MTU设置一致且已启用巨帧。
PFC配置不当：流量控制过于激进，导致链路频繁暂停。
应用瓶颈：发送端应用准备数据的速度跟不上网络速度。
4.2 案例二：偶发性通信超时
症状：分布式训练任务偶尔会卡住几十秒后恢复，或直接报超时错误。

分析步骤：

抓包：这个问题需要在问题发生时抓包。可以编写一个监控脚本，当应用日志出现超时警告时，自动触发抓包（抓取30秒）。
Wireshark分析：
时间线分析：在包列表，注意看“Time”列。寻找两个连续数据包之间异常大的时间间隔（例如，从几毫秒突然变成几百毫秒或几秒）。这直接指示了通信停顿的发生点。
围绕停顿点分析：定位到时间间隔大的地方，仔细查看前后几个报文。
停顿前最后一个数据包是什么？它的PSN是多少？是否设置了AckReq？
停顿后第一个数据包是什么？是期待的ACK吗？还是一个重复的PSN（重传）？
检查ARP/NDP：在停顿时间点附近，过滤arp或icmpv6，看是否有地址解析协议在运行。这可能是IP地址缓存过期导致的短暂中断。
可能原因与解决：
网络微突发丢包：瞬间流量超过交换机缓冲区，导致丢包，触发RDMA重传机制（Go-Back-N），造成延迟。解决方案是优化流量模式或调整交换机缓冲区管理策略。
慢速ARP/路由收敛：在虚拟化或SDN环境中，底层网络路径变化可能导致短暂中断。
对端应用处理延迟：接收端应用未能及时消费接收队列中的数据，导致QP的接收队列满，发送端被流控。
4.3 案例三：验证RoCE v2的可靠传输机制
很多人疑惑，基于不可靠UDP的RoCE v2如何保证可靠传输（RC服务）。通过抓包，我们可以亲眼见证这一机制。

抓取一次RC Send操作的完整过程（从开始到结束）。
在Wireshark中，使用过滤器 roce，并按PSN排序（点击PSN列）。
观察：
发送方会发送一系列PSN连续递增的数据包。
某些数据包的BTH层中，AckReq标志位被置为1（在Wireshark中显示为.... ...1 = AckReq: Ack requested）。
随后，你会看到来自接收方的ACK包。ACK包本身也是一个IB传输层报文（Opcode为ACK），其“Acknowledge PSN”字段会确认收到的最后一个连续PSN。
如果发送方没有在预期时间内收到ACK，它会重传从某个PSN开始的数据包。你会在抓包中看到PSN序列出现“回退”和重复。
这个过程清晰地展示了在UDP之上的IB传输层协议是如何实现确认与重传，从而在不可靠的IP网络上构建起可靠连接的。理解这一点，对于调试复杂网络环境下的RDMA问题至关重要。

掌握RDMA流量的捕获与分析，如同获得了透视高性能网络内部运作的“X光眼”。它不仅能帮助你在出现问题时快速定位根因，更能让你在日常工作中，通过观察流量模式来优化应用性能，预防潜在风险。从编译工具时的耐心，到抓包过滤时的精准，再到Wireshark分析时的洞察，每一步都凝结着对技术深度的追求。记住，最有效的分析往往来自于对“正常”流量模式的熟悉，这样当“异常”出现时，你才能一眼识别。不妨现在就为你手头的RDMA集群做一次“体检”，建立属于你的基准流量档案吧。

————————————————
https://blog.csdn.net/weixin_29250403/article/details/158116053
https://zhuanlan.zhihu.com/p/657265815