4. ARP协议与广播：ARP请求/响应机制，ARP泛洪问题
说到广播丢包，ARP协议绝对是绕不开的一个坎。我排查过不少网络故障，十次里有三四次，根因都跟ARP有关。说白了，ARP就是让设备知道“这个IP地址对应哪个MAC地址”的协议。它本身设计得很简单，但简单的东西一旦出问题，往往最让人头疼。
4.1 ARP请求与响应：广播的典型场景
先回顾一下ARP的基本工作方式。当一台主机要跟另一台主机通信时，它只知道对方的IP地址，不知道MAC地址。这时候，它就会发一个ARP请求——这个请求是广播帧，目的MAC是全F（FF:FF:FF:FF:FF:FF）。
举个例子，主机A（IP: 192.168.1.10）想找主机B（IP: 192.168.1.20）。A会问：“谁的IP是192.168.1.20？请告诉我你的MAC地址。”这个请求会广播到整个广播域。B收到后，发现问的是自己，就回复一个单播的ARP响应，告诉A自己的MAC地址。
关键点：ARP请求是广播，ARP响应是单播。这个机制本身没问题，但广播的范围决定了影响面。
我遇到过一种情况：一个办公室的网络突然变慢，丢包率飙升。查了半天，发现是一台新接入的打印机配置了错误的IP地址，导致它不停地发ARP请求，把整个广播域都淹没了。嗯，这就是典型的ARP泛洪。
4.2 ARP缓存与老化
设备收到ARP响应后，会把IP和MAC的对应关系缓存起来，避免每次通信都发广播。这个缓存有老化时间，不同厂商、不同操作系统默认值不一样。
| 操作系统/设备 | 默认ARP老化时间 | 备注 |
|---|---|---|
| Windows | 15-45秒（动态） | 根据网络活动自动调整 |
| Linux | 60秒 | 可通过/proc调整 |
| Cisco交换机 | 14400秒（4小时） | 静态条目不老化 |
| 华为交换机 | 1200秒（20分钟） | 可配置 |
老化时间太短，设备会频繁发ARP请求，增加广播流量。老化时间太长，如果网络拓扑变了（比如换了网卡），设备还拿着旧的MAC地址通信，就会丢包。我曾经处理过一个案例：一台服务器换了网卡，但交换机上的ARP缓存没更新，结果业务中断了半小时。排查时发现，交换机还在用旧MAC地址转发数据包。
我的建议：在稳定的网络环境中，适当延长ARP老化时间可以减少广播。但如果网络经常变动，老化时间设短一点反而更安全。
4.3 ARP泛洪：广播风暴的隐形杀手
ARP泛洪，说白了就是短时间内有大量ARP请求或响应在网络上传播。这会导致什么问题？
- CPU过载：交换机、路由器收到大量ARP包，CPU忙于处理，正常转发性能下降。
- 带宽耗尽：广播帧会占用链路带宽，尤其是低速链路，直接塞满。
- 缓存溢出：设备ARP表项被撑爆，旧的合法条目被踢出，导致通信中断。
- 丢包加剧：正常数据包被ARP包挤掉，或者因为CPU忙不过来被丢弃。
为什么会发生ARP泛洪？常见原因有几种：
- IP地址冲突：两台设备配置了相同IP，它们会互相发ARP请求“抢地盘”。
- 环路导致广播风暴：二层环路没处理好，ARP广播帧在环路里无限转发。
- 恶意攻击：有人故意发大量伪造ARP包，搞ARP欺骗或DoS攻击。
- 设备故障：网卡坏了或者驱动异常，疯狂发ARP请求。
注意：ARP泛洪不一定是攻击。很多时候是配置错误或设备故障引起的。别一上来就想着抓坏人，先看看是不是自己人搞的。
4.4 排查ARP泛洪的实战方法
排查ARP泛洪，我一般按这个步骤来：
4.4.1 确认症状
先看现象。用户反馈网络慢、丢包、部分设备连不上。登录交换机，用命令看CPU利用率：
# Cisco交换机
show processes cpu | include ARP
# 华为交换机
display cpu-usage | include ARP如果ARP进程CPU占用率超过30%，基本可以确认有问题。
4.4.2 定位源头
用抓包工具或者交换机的端口镜像功能，抓取ARP包。分析源MAC地址，看哪个设备发的ARP请求最多。
# 在交换机上查看ARP统计
show arp traffic
# 查看哪个端口收到的ARP包最多
show interface | include ARP我记得有一次，抓包发现一个端口每秒发出5000多个ARP请求。顺着端口找到那台设备，发现是一台打印机的网卡坏了，一直在发垃圾包。
4.4.3 临时隔离
找到问题端口后，先把它shutdown掉，恢复网络。然后通知用户去处理那台设备。
interface GigabitEthernet0/1
shutdown别急着删配置，等确认问题解决了再恢复。
4.4.4 长期防护
为了防止以后再出现类似问题，我建议在交换机上配置ARP限速和DAI（Dynamic ARP Inspection）。
# Cisco交换机配置ARP限速
interface GigabitEthernet0/1
arp rate-limit 100
# 启用DAI（需要先启用DHCP Snooping）
ip arp inspection vlan 10
interface GigabitEthernet0/1
ip arp inspection trustDAI会检查ARP包是否合法，不匹配DHCP绑定关系的ARP包直接丢弃。这招对付ARP欺骗和泛洪很有效。
4.5 ARP与广播丢包的关系总结
ARP协议本身是广播的，这是它的设计特性。但广播是一把双刃剑——用好了是网络发现的基础，用不好就是丢包的根源。ARP泛洪导致广播域内所有设备都得处理这些包，CPU和带宽被消耗，正常数据包就被挤掉了。
你想想看，一个广播域里如果有几百台设备，一台设备发ARP泛洪，其他设备都得跟着遭殃。这就是为什么我一直在强调：广播域不能太大，ARP防护不能少。
核心结论：ARP泛洪是广播丢包的常见原因之一。排查时先看ARP进程CPU占用，再定位源头，最后用限速和DAI做防护。
4.6 ARP请求/响应与泛洪流程图
下面这张图展示了正常的ARP请求/响应过程，以及ARP泛洪时网络发生了什么变化。
4.7 避坑指南
最后分享几个我踩过的坑：
- 别忽略静态ARP：我曾经在核心设备上配了静态ARP，结果设备换了网卡忘了更新，排查了整整一天。静态ARP要慎用，用了就得做好文档管理。
- ARP限速别设太死：设得太低，正常ARP请求也会被丢。我一般先观察正常流量，再设一个安全阈值。
- DAI依赖DHCP Snooping：如果网络里没用DHCP，都是静态IP，DAI就不好使了。这时候得用其他手段，比如端口安全。
- 抓包要抓对位置：ARP泛洪时，在问题设备的上联端口抓包最有效。别在核心交换机上抓，可能什么都看不到。
ARP协议看起来简单，但出问题的时候真能让人抓狂。掌握了这些排查思路和防护手段，下次遇到ARP泛洪，你就能从容应对了。