特殊地址在抓包里的样子
排障时常见几类特殊地址组合：DHCP 客户端在拿到地址前用 0.0.0.0 作为源地址，目标写受限广播 255.255.255.255；ARP 请求以广播帧发出询问某地址的 MAC；OSPF 与 VRRP 等协议使用固定组播地址在段内找邻居。掌握几条抓包过滤器，就能快速判断是协议根本没发出去，还是发出后被网络丢弃。
基本信息
| DHCP 发现 | 源 0.0.0.0:68，目标 255.255.255.255:67 |
|---|---|
| ARP | 请求为广播帧，目标 MAC 为全 F |
| OSPF | IP 协议号 89，常用组播 224.0.0.5 与 224.0.0.6 |
| VRRP | IP 协议号 112，使用 224.0.0.18 |
| PIM | 使用 224.0.0.13 建立邻居 |
| 抓包工具 | Linux 用 tcpdump，Windows 用 pktmon 或 Wireshark |
常用抓包过滤器
常用抓包过滤器
tcpdump -ni eth0 'udp port 67 or udp port 68' # DHCP 完整交互
tcpdump -ni eth0 'src host 0.0.0.0' # 尚未获得地址的客户端
tcpdump -ni eth0 'dst host 255.255.255.255' # 受限广播
tcpdump -ni eth0 vrrp # VRRP 报文
tcpdump -ni eth0 'ip proto 89' # OSPF
tcpdump -ni eth0 arp # ARP 请求与应答
tcpdump -ni eth0 'ip multicast and ip[8] < 2' # TTL 为 1 的链路本地组播过滤条件与用途
| 过滤条件 | 观察目标 |
|---|---|
| udp port 67 or 68 | DHCP 四步交互是否完整 |
| src host 0.0.0.0 | 客户端是否真的发出了请求 |
| dst host 255.255.255.255 | 受限广播是否被送出或被丢弃 |
| arp | 地址解析是否到达对端 |
| ip proto 89 | OSPF 邻居报文是否双向 |
| ip multicast | 组播报文与 TTL 是否符合预期 |
典型使用场景
- 用户报告拿不到地址：抓包确认 DISCOVER 是否发出、是否有 OFFER 返回，快速区分客户端与服务端问题
- 跨网段不通：观察 ARP 或 NDP 是否到达网关，判断三层转发是否正常发起
- 路由协议邻居起不来：抓 OSPF 或 PIM 报文，确认组播双向可达
- VRRP 主备切换异常：抓 VRRP 报文看通告间隔与优先级是否符合设计
- 排查组播业务无流量：确认接收端是否发出 IGMP 加入报文
Windows 侧
Windows 侧
pktmon start --capture --pkt-size 0
pktmon filter list
# 或使用 Wireshark 的显示过滤器：bootp / arp / vrrp / ospf
# 抓包结束：pktmon stop看到 0.0.0.0 作为源地址是正常现象：客户端尚未获得地址时只能这样标识源，尤其在 DHCP 交互初期与重复地址检测阶段。
抓包位置选择
- 客户端侧抓包能确认报文是否发出，服务端侧抓包能确认是否收到，两端一起抓才能定位丢在哪一段
- 有中继或三层设备时，在中间设备上抓包可确认转发是否发生，这比只在一端抓更有价值
- 抓包时优先使用简短过滤条件并限制报文数量，避免高流量下缓冲区被填满而遗漏关键报文
- 保存原始报文文件便于后续用图形工具复查，避免现场反复复现