本文为博主原创，转载请注明出处：
在业务环境中，通过snmp轮询采集设备信息时，会偶遇 snmp 响应报文在解析过程中异常，于是采用tcpdump抓包进行报文分析。
1.分片报文
通过tcpdump 抓包，查看响应报文得内容如下：
有一段很关键得报文内容如下：
"6876","2025-10-16 15:56:25.677396","172.16.25.13","172.16.11.102","IPv4","1516","Fragmented IP protocol (proto=UDP 17, off=0, ID=007b)"这段报文得主要内容：
| 字段 | 值 | 含义 |
|---|---|---|
| 序列号 | 6876 | 报文在捕获中的编号 |
| 时间戳 | 2025-10-16 15:56:25.677396 | 精确到微秒的捕获时间 |
| 源IP | 172.16.25.13 | 发送方IP地址 |
| 目的IP | 172.16.11.102 | 接收方IP地址 |
| 协议 | IPv4 | 网络层协议 |
| 长度 | 1516 bytes | 报文总长度 |
| 详细信息 | Fragmented IP protocol... | IP分片详情 |
2.分片参数详解
2.1 分片参数详解
Fragmented IP protocol (proto=UDP 17, off=0, ID=007b)| 参数 | 值 | 含义 |
|---|---|---|
proto=UDP 17 |
UDP协议，协议号17 | 传输层协议类型 |
off=0 |
分片偏移量=0 | 这是第一个分片 |
ID=007b |
分片标识符=0x007b(123) | 同一数据包的所有分片共享此ID |
2.2 分片技术细节
IP分片头部字段 ：
-
总长度 : 1516 bytes
-
标识 : 0x007b (123)
-
分片标志 : MF=1 (More Fragments，还有后续分片)
-
分片偏移 : 0 (这是第一个分片)
3. 网络流量分析
3.1 通信方向
172.16.25.13 → 172.16.11.102-
源 : 172.16.25.13 (可能是客户端或服务请求方)
-
目的 : 172.16.11.102 (可能是服务器或服务提供方)
3.2 分片原因分析
为什么需要分片 ：
-
MTU限制 : 路径上某个链路的MTU小于1516字节
-
常见MTU值 :
-
以太网: 1500字节
-
PPPoE: 1492字节
-
隧道协议: 更小值
-
计算 ：
原始UDP数据包:
[IP头20][UDP头8][数据1488] = 总长1516字节
分片后:
分片1: [IP头20][UDP头8][部分数据] + 分片标志MF=1, Offset=0
分片2: [IP头20][剩余数据] + 分片标志MF=0, Offset=1480/8=1854.2 协议栈层次
应用层数据
↓
UDP头部 (8字节)
↓
IP头部 (20字节) + 分片信息
↓
网络传输5. 可能的应用场景
5.1 常见的UDP大包应用
# DNS响应 (通常不会这么大)
# NTP协议
# SNMP Trap
# TFTP文件传输
# 视频流媒体
# 自定义UDP应用5.2 网络诊断
# 检查路径MTU
ping -M do -s 1472 172.16.11.102 # 测试MTU
# 使用traceroute检查路径
traceroute 172.16.11.1026. 网络优化建议
6.1 避免分片的方法
# 调整应用层数据大小
应用程序设置: MTU - IP头 - UDP头 = 1500 - 20 - 8 = 1472字节
# 系统级MTU配置
ifconfig eth0 mtu 15006.2 监控建议
# 监控分片统计
netstat -s | grep -i fragment
# 使用tcpdump持续监控
tcpdump -i any -n 'host 172.16.25.13 and host 172.16.11.102'7. 解决方法
** 1.设置调整路由设备得mtu值**
** 2. 设置snmp 采集轮询中每次walk数据量得大小；即设置 snmp 在 getBulk时得 MaxRepetition 参数，将这个参数调小，每次响应得数据变小，就可以正常响应了。**