4、Wireshark快速上手：安装配置、界面布局、抓包过滤、显示过滤、着色规则与时间戳设置
RoCEv2（RDMA over Converged Ethernet version 2）报文分析对工具的要求极为苛刻：既要能解析UDP端口4791上的Rohc（RDMA over Converged Ethernet）头部，又要能准确呈现CNP（Congestion Notification Packet）、ACK、NACK等InfiniBand传输层语义。Wireshark作为业界最主流的开源协议分析器，其3.6以上版本已内置完整的RoCEv2解析器。本章将围绕Wireshark的安装配置、界面布局、双过滤机制、着色规则与时间戳设置五个维度展开，帮助学员在30分钟内搭建一套适合RoCEv2深度分析的抓包环境。下图展示了Wireshark分析RoCEv2报文的完整工作链路，从原始以太网帧到RoCEv2各层头部解析的流程一目了然。
在开始具体操作之前，需要明确一个核心原则：捕获过滤器与显示过滤器是两种完全不同的机制。捕获过滤器在数据包进入Wireshark内存之前就由底层libpcap/WinPcap驱动执行，只保留匹配的报文，不匹配的直接丢弃，因此无法事后恢复；而显示过滤器则是在已捕获的报文集合中做条件筛选，不删除任何数据，可以随时修改条件重新过滤。对于RoCEv2分析，建议在捕获阶段使用宽泛的端口过滤（udp port 4791），而在显示阶段使用精细的协议字段过滤（如rocev2.opcode、rocev2.aeth.syndrome等），这样既能控制抓包文件体积，又不丢失后续深入分析的可能性。
4.1 安装配置：从源码编译到功能验证
核心原理：Wireshark的RoCEv2解析能力依赖于其内置的epan/dissectors/packet-roce.c模块。自3.4版本起，该模块已支持BTH（Base Transport Header）、RETH（RDMA Extended Transport Header）、Atomic、ImmData、CNP等完整解析。对于CentOS/RHEL 7等使用旧版libpcap的系统，建议使用源码编译方式安装，以获得最新的协议解析支持。
操作流程：以Ubuntu 22.04 LTS为例，推荐使用官方PPA源安装最新稳定版：
# 添加Wireshark官方PPA源
sudo add-apt-repository ppa:wireshark-dev/stable
sudo apt update
# 安装无图形界面的tshark和图形界面wireshark
sudo apt install wireshark tshark
# 将当前用户加入wireshark组，避免每次sudo
sudo usermod -aG wireshark $USER
# 验证安装版本及RoCEv2解析支持
wireshark --version | grep "Wireshark"
tshark -G protocols | grep -i roce安装完成后，需要进入Preferences → Protocols → RoCE检查解析参数。默认情况下，Wireshark将UDP端口4791识别为RoCEv2数据端口，将端口4792识别为RoCEv2 CNP端口。如果实际环境中使用了非标准端口（例如某些交换机配置为4790），必须在此处手动添加端口映射，否则报文会被解析为普通UDP而无法看到RoCEv2头部。
| 配置项 | 默认值 | 推荐设置 | 说明 |
|---|---|---|---|
| RoCEv2 UDP port | 4791 | 4791（或实际端口） | 数据报文端口 |
| CNP UDP port | 4792 | 4792（或实际端口） | 拥塞通知报文端口 |
| Attempt RoCEv2 decoding | Enabled | Enabled | 强制尝试解析RoCEv2 |
| Ignore CRC errors | Disabled | Enabled（分析时） | 忽略FCS错误，便于分析 |
ethtool -K eth0 rx-udp-gro-forwarding on，否则大包（如256KB的RDMA Write）会被分片，导致Wireshark无法重组完整报文。4.2 界面布局：三栏联动与自定义工具栏
核心原理：Wireshark主界面采用经典的三栏布局——报文列表（Packet List）、报文详情（Packet Details）、报文字节（Packet Bytes）。三栏之间通过点击联动：在列表中选择一个报文，详情栏立即显示该报文的协议树，字节栏以十六进制和ASCII形式展示原始数据。对于RoCEv2分析，这种联动机制尤为重要，因为需要同时查看BTH中的OpCode、PSN（Packet Sequence Number）以及对应的原始字节偏移。
操作流程：建议对界面做以下定制以提升RoCEv2分析效率：
- 调整列显示：右键点击报文列表的列标题，选择"Column Preferences"，添加以下自定义列：
rocev2.bth.opcode（显示OpCode）、rocev2.bth.psn（显示PSN）、rocev2.bth.dest_qp（显示目的QP号）。 - 启用协议着色：在"View → Coloring Rules"中，为RoCEv2的CNP报文设置红色背景，为ACK报文设置绿色背景，为普通数据报文保留默认白色。
- 使用Profile：在右下角Profile切换器创建"RoCE_Analysis"专用配置，保存所有自定义设置，避免与日常抓包配置混淆。
案例拆解：某存储阵列性能调优场景中，工程师需要快速区分同一QP（Queue Pair）上的Write请求与Read响应。通过添加rocev2.bth.opcode列，并设置显示过滤器rocev2.bth.dest_qp == 0x1234，可以在数千个报文中迅速定位到目标QP的完整交互序列。此时，报文列表中的OpCode列直接显示为"Write"、"Read"、"ACK"等可读字符串，无需逐个展开详情树。
4.3 抓包过滤与显示过滤：双过滤机制实战
核心原理：捕获过滤器使用BPF（Berkeley Packet Filter）语法，在操作系统内核层面执行，只支持协议栈底层字段（如IP、TCP、UDP端口）。显示过滤器使用Wireshark的dsfilter语法，在用户空间执行，支持所有已解析的协议字段。对于RoCEv2，捕获过滤器只能过滤到UDP端口4791，而显示过滤器可以精确到OpCode、PSN、SL（Service Level）等RoCEv2特有字段。
操作流程：以下是一套完整的双过滤配置方案：
# 捕获过滤器（Capture Filter）—— 只抓取RoCEv2数据面和CNP报文
udp port 4791 or udp port 4792
# 显示过滤器（Display Filter）—— 常用RoCEv2过滤条件
# 查看所有RoCEv2报文
rocev2
# 查看CNP拥塞通知报文
rocev2.opcode == 0x81
# 查看特定QP的报文
rocev2.bth.dest_qp == 0x1a2b
# 查看特定SL（服务等级）的报文
rocev2.bth.sl == 3
# 查看带重传标记的报文（FECN/BECN）
rocev2.bth.fecn == 1 || rocev2.bth.becn == 1
# 组合过滤：查看QP 0x1a2b的Write请求
rocev2.bth.dest_qp == 0x1a2b && rocev2.opcode == 0x0a案例拆解：在一次RoCEv2网络拥塞排障中，工程师需要确认CNP报文的来源和去向。首先使用捕获过滤器udp port 4792单独抓取CNP流量，然后使用显示过滤器rocev2.bth.dest_qp == 0x8001筛选出目标QP的CNP。通过分析CNP中的rocev2.cnp.qp字段（被拥塞影响的QP号），可以快速定位到具体的流。进一步结合rocev2.bth.psn字段，能够还原拥塞发生时的PSN序列，判断是发送端还是接收端触发了拥塞控制。
| 过滤类型 | 语法示例 | 执行位置 | 适用场景 |
|---|---|---|---|
| 捕获过滤 | udp port 4791 | 内核BPF | 减少抓包文件体积 |
| 捕获过滤 | host 192.168.1.10 | 内核BPF | 只抓特定主机流量 |
| 显示过滤 | rocev2.opcode == 0x0a | 用户空间 | 精确筛选Write请求 |
| 显示过滤 | rocev2.bth.psn > 1000 | 用户空间 | 按PSN范围筛选 |
udp port 4791而忘记包含4792端口，那么所有CNP报文都将丢失。因此，在生产环境抓包时，建议使用udp port 4791 or udp port 4792作为捕获过滤器，将更精细的筛选留给显示过滤器。4.4 着色规则：让异常报文一目了然
核心原理：Wireshark的着色规则基于显示过滤器表达式，对匹配的报文应用预设的前景色和背景色。着色规则按顺序从上到下匹配，第一条匹配的规则生效。对于RoCEv2分析，合理的着色方案能够显著提升排障效率——工程师可以在数百个报文中一眼识别出CNP、重传、NACK等异常报文。
操作流程：进入"View → Coloring Rules"，点击"New"创建以下规则：
# 规则1：CNP拥塞通知（红色背景，白色文字）
rocev2.opcode == 0x81
# 规则2：ACK确认（绿色背景，黑色文字）
rocev2.opcode == 0x00
# 规则3：NACK否定确认（橙色背景，黑色文字）
rocev2.opcode == 0x01
# 规则4：FECN/BECN标记（黄色背景，黑色文字）
rocev2.bth.fecn == 1 || rocev2.bth.becn == 1
# 规则5：Read请求（蓝色背景，白色文字）
rocev2.opcode == 0x06案例拆解：在数据中心RoCEv2网络验收测试中，测试团队需要验证拥塞控制机制是否正常工作。通过上述着色规则，当注入背景流量触发拥塞时，红色CNP报文会立即在报文列表中凸显。此时，工程师可以快速统计CNP报文的频率和分布，结合rocev2.bth.sl字段判断拥塞是否被限制在预期的服务等级内。如果红色报文出现在所有SL中，说明PFC（Priority Flow Control）配置可能存在问题。
4.5 时间戳设置：精确测量RTT与延迟
核心原理：Wireshark的时间戳精度取决于捕获接口和操作系统。对于RoCEv2延迟分析，需要微秒级甚至纳秒级精度。Linux系统下，使用AF_PACKET套接字可以获得纳秒级时间戳；Windows下，WinPcap/Npcap默认提供微秒级精度。Wireshark支持三种时间显示格式：时间（UTC或本地）、相对时间（相对于第一个报文）、增量时间（相对于上一个报文）。
操作流程：在"View → Time Display Format"中，推荐以下设置组合：
- 主时间列：选择"Seconds Since Beginning of Capture"（相对于捕获开始），便于计算整体时间跨度。
- 辅助时间列：添加自定义列，使用"Seconds Since Previous Captured Packet"（相对于上一个报文），用于观察报文间隔。
- 精度设置：在"Preferences → Appearance → Layout"中，将时间精度设置为"Automatic (nanoseconds)"，确保显示完整精度。
案例拆解：测量RoCEv2 Write请求的RTT，需要找到一对匹配的Write请求和对应的ACK响应。使用显示过滤器rocev2.opcode == 0x0a || rocev2.opcode == 0x00筛选出Write和ACK报文，然后通过rocev2.bth.psn字段匹配请求与响应。在报文列表中选择Write请求，记录其时间戳T1；再找到对应的ACK报文，记录时间戳T2。RTT = T2 - T1。如果使用增量时间格式，可以直接在ACK报文的"Time"列看到与上一个报文的间隔，但需要注意该间隔可能包含其他报文，因此更精确的做法是使用"Statistics → Flow Graph"功能，它会自动计算并显示请求-响应延迟。
| 时间格式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| UTC时间 | 多机协同抓包 | 可跨设备对比 | 需要时钟同步 |
| 相对时间 | 单机分析 | 直观显示时间跨度 | 无法跨设备对比 |
| 增量时间 | 报文间隔分析 | 快速发现异常间隔 | 受无关报文干扰 |
总结复盘：本章围绕Wireshark的五个核心操作维度展开，重点强调了捕获过滤与显示过滤的本质区别、着色规则在异常报文识别中的价值、以及时间戳精度对RoCEv2延迟测量的影响。在实际项目中，建议按照"先宽后窄"的原则配置过滤条件——捕获阶段保留尽可能多的RoCEv2报文，显示阶段再逐步缩小范围。同时，将着色规则与显示过滤器配合使用，可以构建一套高效的RoCEv2报文快速诊断体系。最后，务必在正式抓包前验证时间戳精度和端口映射配置，避免因基础设置错误导致整个分析工作返工。