从抓包看原理：手把手教你用Wireshark调试Mellanox RoCEv2网络性能问题

在AI训练集群和分布式存储系统中，RoCEv2协议的性能抖动问题常常让网络工程师彻夜难眠。当传统的ping和traceroute无法定位问题时，数据包层面的深度分析就成为破局关键。本文将带您走进Wireshark的微观世界，通过三个典型报文特征（ECN标记、CNP报文、DSCP映射），构建一套逆向诊断RoCEv2网络问题的实战方法论。

1. 搭建RoCEv2诊断环境

在开始抓包分析前，需要确保测试环境具备以下条件：

• 硬件准备：

  • Mellanox ConnectX-5及以上版本网卡
  • 支持PFC和ECN的TOR交换机（如NVIDIA Spectrum系列）
  • 服务器间直连或通过无损网络互联

• 软件配置：

  bash复制# 验证RoCEv2模式
  cma_roce_mode -d mlx5_1 -p 1 -m 2 | grep "RoCE v2"
  
  # 开启DCQCN拥塞控制
  echo 1 > /sys/class/net/ens1np0/ecn/roce_np/enable/3
  echo 1 > /sys/class/net/ens1np0/ecn/roce_rp/enable/3
  

注意：生产环境中建议在非业务高峰时段进行抓包，避免大流量冲击影响分析准确性。

2. 关键报文特征解析

2.1 ECN标记（0x3）的临床意义

在Wireshark过滤栏输入ip.dsfield.ecn == 0x3，可以捕获到所有携带ECN拥塞标记的报文。这些"网络血压计"读数能揭示以下问题：

python复制# 用tshark统计ECN标记分布
tshark -r rocev2.pcap -Y "ip.dsfield.ecn == 0x3" -T fields -e frame.time_relative \
  | awk '{print int($1)}' | uniq -c | head -n 10

2.2 CNP报文（Opcode 0x81）解码

CNP（Congestion Notification Packet）是RoCEv2的"急救信号"，通过过滤infiniband.bth.opcode == 0x81可定位到这些关键报文。一个健康的网络应该：

• CNP占比小于总流量的0.1%
• 分布均匀无突发
• 与ECN标记存在合理的时间关联

典型异常场景处理流程：

1. 发现密集CNP报文（>100个/秒）
2. 追溯对应QP的ECN历史
3. 检查cnp_dscp与交换机队列映射

   bash复制# 验证CNP的DSCP标记
   cat /sys/class/net/ens1np0/ecn/roce_np/cnp_dscp
   

2.3 DSCP字段的拓扑映射

DSCP值如同网络流量的"邮政编码"，其映射关系直接影响服务质量：

mermaid复制graph TD
    A[应用TOS=96] -->|dscp=24| B(网卡队列3)
    B --> C{交换机}
    C -->|PFC触发| D[CNP dscp=48]
    D --> E[网卡队列6]

关键检查点：确保mlnx_qos --trust=dscp已启用，且交换机端口配置匹配的DSCP信任模式。

3. 性能问题诊断四步法

3.1 建立基线流量

使用标准工具生成可控流量：

bash复制# 发送端
ib_send_bw -d mlx5_1 -R -T 96 -D 10 192.168.1.2

# 接收端
ib_send_bw -d mlx5_1 -R -T 96 -D 10

3.2 实施分层抓包策略

• 第一层过滤：udp.port == 4791
• 第二层过滤：ip.dsfield.dscp == 24
• 第三层过滤：infiniband.bth.opcode == 0x81

3.3 关键指标关联分析

通过Wireshark的IO Graphs功能，叠加显示以下指标：

1. ECN标记出现频率
2. CNP报文分布
3. 吞吐量波动曲线
4. 延迟变化趋势

3.4 配置反推验证

当发现异常报文模式时，按此逻辑逆向检查：

code复制观测到持续ECN标记
→ 检查交换机端口ecn配置
→ 验证mlnx_qos的ets权重
→ 确认应用层TOS设置
→ 测试端到端PFC触发机制

4. 典型故障案例库

4.1 案例：AI训练中的周期性延迟抖动

现象：每15分钟出现约200ms的延迟峰值

抓包发现：

• 同步出现ECN标记和CNP报文激增
• 交换机计数器显示PFC暂停帧爆发

根因：

bash复制# 错误配置：队列3权重过低
mlnx_qos -i ens1np0 -t 10,10,10,10,10,10,0,0

# 修正方案：提升RoCEv2队列权重
mlnx_qos -i ens1np0 -t 10,10,10,50,10,10,0,0

4.2 案例：分布式存储的吞吐量下降

现象：大块写入时吞吐量下降30%

报文特征：

• CNP报文集中在特定源QP
• 对应流的DSCP值异常（dscp=0）

修复步骤：

1. 确认应用设置了正确的TOS：

   c复制// RDMA CM建立时设置
   attr.qp_init_attr.tos = 96;
   

2. 验证网卡信任模式：

   bash复制mlnx_qos -i ens1np0 --trust=dscp
   

5. 高级调试技巧

5.1 时间序列分析

使用Wireshark的tcp.time_delta过滤器观察微突发：

code复制frame.time_delta > 0.0005 && udp.port == 4791

5.2 交换机镜像端口配合

在TOR交换机上配置：

cisco复制monitor session 1 source interface Ethernet1/1 both
monitor session 1 destination interface Ethernet1/10

5.3 硬件计数器验证

通过ethtool交叉验证：

bash复制ethtool -S ens1np0 | grep -E 'pause|ecn|discard'

在实际处理某金融客户HPC集群问题时，我们发现交换机的ECN标记间隔时间与网卡DCQCN响应时间存在10ms偏差，通过调整roce_np_ecn_response参数后性能提升22%。这种精细调优往往需要结合具体硬件型号和流量特征进行定制化处理。