2. 网络嗅探入门：使用Wireshark/Tcpdump抓取广播报文

排查广播丢包，第一步是什么？

不是看配置，不是翻日志。是先把报文抓下来，亲眼看看网络里到底在发生什么。

我个人习惯，遇到广播相关的问题，第一反应就是开抓包。你想想看，广播报文是看不见摸不着的东西，光靠猜，效率太低了。抓包工具就像网络工程师的听诊器，能让你听到网络里的「心跳」和「杂音」。

2.1 抓包前的准备工作

别急着敲命令。先想清楚几个问题：

  • 在哪抓？ 广播域边界？终端侧？还是交换机镜像口？
  • 抓什么？ 所有广播？还是特定类型的广播（比如ARP、DHCP）？
  • 怎么抓？ 用Tcpdump还是Wireshark？命令行还是图形界面？
我的建议： 如果是在服务器上排查，优先用Tcpdump。它轻量、稳定，不占GUI资源。如果是客户端环境，或者需要做深度协议分析，Wireshark更直观。

2.2 Tcpdump实战：命令行抓广播

Tcpdump是Linux下的抓包神器。它的核心逻辑很简单：监听网卡，匹配规则，输出报文。

先看一个最基础的广播抓包命令：

# 抓取所有广播报文（以太网广播地址 ff:ff:ff:ff:ff:ff）
tcpdump -i eth0 ether broadcast

# 或者更精确一点，抓IPv4广播
tcpdump -i eth0 ip broadcast

嗯，这里要注意。广播报文的目标MAC地址是 ff:ff:ff:ff:ff:ff。Tcpdump的 ether broadcast 就是匹配这个地址。

我在项目中遇到过一个问题：某台服务器间歇性丢包，但ping网关却正常。后来我用Tcpdump抓了5分钟广播报文，发现每秒有超过200个NetBIOS广播在网络上泛滥。交换机CPU撑不住了，开始丢包。这就是典型的广播风暴前兆。

常用的Tcpdump广播抓取参数：

参数 作用 示例
-i 指定网卡接口 -i eth0
-n 不解析域名，加快速度 -n
-e 显示MAC层头部信息 -e
-v 显示更详细的报文信息 -v
-c 抓取指定数量后停止 -c 100
-w 保存为pcap文件 -w broadcast.pcap
避坑指南： 我曾经在排查广播问题时，直接在核心交换机上执行 tcpdump -i any 抓所有流量。结果瞬间抓了几GB数据，服务器直接卡死。记住：先加过滤条件，再开抓包。尤其是广播环境，流量可能比你想象的大得多。

2.3 Wireshark实战：图形化分析广播

Wireshark是Tcpdump的图形化升级版。它不仅能抓，还能帮你分析。

抓取广播报文的步骤：

  1. 选择正确的网卡接口
  2. 在过滤栏输入 eth.addr == ff:ff:ff:ff:ff:ff
  3. 点击开始捕获

Wireshark的显示过滤器非常强大。我常用的几个广播相关过滤器：

  • eth.dst == ff:ff:ff:ff:ff:ff —— 只看广播帧
  • arp —— 只看ARP广播
  • bootp —— 只看DHCP广播
  • udp.port == 67 or udp.port == 68 —— DHCP服务端/客户端端口
  • !(arp or dns or dhcp) —— 排除常见广播，找异常广播
核心技巧： 在Wireshark里，你可以用 Statistics → Protocol Hierarchy 查看广播报文的协议分布。如果某个协议占比异常高，那基本就是问题所在。

2.4 广播报文的结构拆解

抓到了报文，你得能看懂它。一个标准的以太网广播帧长这样：

Ethernet II, Src: 00:1a:2b:3c:4d:5e, Dst: ff:ff:ff:ff:ff:ff
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: 00:1a:2b:3c:4d:5e
    Type: ARP (0x0806)
ARP Request: Who has 192.168.1.1? Tell 192.168.1.100

关键字段：

  • 目标MAC：全F，表示广播
  • 类型字段：0x0806是ARP，0x0800是IP
  • 载荷：具体广播内容

为什么广播报文不能被交换机转发到其他VLAN？因为交换机只看目标MAC。全F的MAC，它就知道这是广播，只在本地VLAN内泛洪。

2.5 知识体系：广播抓包的核心逻辑

下面这张图，是我自己总结的广播抓包决策流程。每次排查广播问题，我都按这个思路走：

广播抓包排查决策流程 发现广播丢包问题 选择抓包点（终端/交换机镜像） 选择工具（Tcpdump / Wireshark） 设置过滤条件（ether broadcast / ARP） 抓取并分析广播报文 关键指标：广播报文速率、协议分布、源MAC是否异常

这张图的核心思想是：先定位，再抓取，后分析。不要一上来就开抓，先想清楚在哪抓、抓什么。

2.6 实战案例：一次ARP广播风暴的抓包过程

我记得有一次，某办公网络突然变慢，丢包率高达30%。

我登录到接入交换机，用Tcpdump抓了30秒广播：

tcpdump -i vlan100 -n -e ether broadcast -c 1000 -w arp_storm.pcap

然后用Wireshark打开pcap文件，看统计信息：

  • 总报文数：1000个
  • ARP广播：987个（占比98.7%）
  • 源MAC集中在 00:1a:2b:xx:xx:xx 段

问题一下就清楚了：某台设备在疯狂发送ARP请求，导致广播泛滥。顺着MAC地址找到对应端口，发现是一台中毒的PC在持续发送伪造ARP包。

小技巧： 在Wireshark里，用 Statistics → Endpoints 可以快速查看每个MAC地址发送的广播数量。谁发的多，谁就是嫌疑犯。

2.7 抓广播时的常见坑

  • 交换机镜像口丢包：镜像口本身可能丢包，尤其是高带宽环境。抓包结果只能作为参考，不能100%代表真实流量。
  • 抓包时间太短：广播问题往往是间歇性的。我建议至少抓5分钟，或者用 -c 参数抓几万个报文，才能看到全貌。
  • 忘记保存pcap：现场分析完，记得保存原始抓包文件。后续复盘或者给同事看，都需要原始数据。
重要提醒： 在生产环境抓包，尤其是核心设备上，一定要控制抓包时长和文件大小。我曾经见过有人用 tcpdump -i any -w /tmp/dump.pcap 不加任何过滤，结果磁盘写满，业务中断。这是血的教训。

好了，广播抓包的基础操作就这些。工具是死的，思路是活的。多抓几次，你自然就能从报文中读出网络的语言。

← 上一章 📖 返回目录 下一章 →