SNMP 请求响应报文传输分片定位

本文为博主原创，转载请注明出处：

　　在业务环境中，通过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)

参数	值	含义
/* by 01022.hk - online tools website : 01022.hk/zh/chaicp.html */ proto=UDP 17	UDP协议，协议号17	传输层协议类型
/* by 01022.hk - online tools website : 01022.hk/zh/chaicp.html */ 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=185

4.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.102

6. 网络优化建议

6.1 避免分片的方法

# 调整应用层数据大小
应用程序设置: MTU - IP头 - UDP头 = 1500 - 20 - 8 = 1472字节

# 系统级MTU配置
ifconfig eth0 mtu 1500

6.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 参数，将这个参数调小，每次响应得数据变小，就可以正常响应了。