一、故障背景：看似正常的网络，突然出现"单向断连"
在白虎科技参与项目调试时，遇到一个非常典型但极具迷惑性的故障：
A 能 ping B，但 B 无法 ping A。
这种"单向可达"场景是网络排障里难度极高的一类问题，因为：
• IP 正常
• VLAN 正常
• MAC 正常
• 端口正常
• 光链路正常
但通信就是不通。
更奇怪的是：
display arp
显示设备的 ARP 项 不是缺失，而是处于 incomplete 状态。
二、第一阶段：所有配置都对，但仍旧单向不通
我们按常规排查流程走了一遍：
✔ VLAN 分配正确
✔ 端口模式正确（Access/Trunk）
✔ 上下行链路正常
✔ MAC 表正常学习
✔ 光模块正常
✔ 线路无断纤
✔ 交换机 CPU 正常
一切都说明：
设备之间应该能够正常互通。
但现实是：
A → B：ping OK
B → A：ping 100% 丢包
这种行为意味着：
数据平面出现单向阻塞，而控制平面是正常的。
三、第二阶段：ARP 表出现关键线索
为了进一步分析，我查看 ARP 表：
display arp
发现：
❗ 主干三层交换机 ARP 表出现大量 incomplete 项
❗ 但汇聚交换机 ARP 完全正常
❗ 访问层摄像头全部正常
这说明：
问题集中在主干交换机 ARP 缓存机制上。
四、第三阶段：ARP Incomplete 的隐藏含义
ARP incomplete 是一种非常容易被误解的状态，它代表：
• ARP 请求已发出
• 对端没有回应
• 或对端回应未被正确接收
• 或 ARP 表被污染
• 或某些报文被丢弃
尤其是在视频监控场景下，这种情况非常常见。
关键意义是：
ARP incomplete 表示链路上某段可以"发出去"，但"收不回来"。
这正好符合"单向可达"的所有特征。
五、第四阶段：捕获报文发现"回程报文被丢弃"
我们在主干交换机上开启调试：
debugging arp packet
然后使用抓包工具发现两个现象：
✔ ARP 请求已经被发送
✔ ARP 回复到达汇聚交换机后，被丢弃
这种行为十分反常。
继续检查 ACL、防火墙、广播风暴抑制等：
• 没有限制
• 没有异常
• 也没有环路
最终发现关键点：
主干交换机中存在陈旧的 ARP 缓存，导致 ARP 响应不能正确关联端口。
这常出现在：
• 老旧交换机
• 频繁上下线的设备
• 监控网络中大量广播
• VLAN 迁移后未清理缓存
六、最终解决方法：清理缓存 + 强制刷新
我们进行了三步修复：
✔ 1. 清空 ARP 缓存
reset arp dynamic
✔ 2. 清空 MAC 缓存
reset mac-address
✔ 3. 刷新 FDB 表，使端口重新学习
undo mac-address static ...
执行完毕后，立即恢复：
B → A：ping OK
直到那一刻，我们才确认根因：
主干交换机缓存异常导致单向通信受阻。
七、为什么这种故障如此难排查？
因为它具备"疑难杂症"的四个特征：
① 所有配置都"看起来正常"
VLAN、MAC、IP、Trunk，全部正常。
② 控制平面正常，但数据平面阻塞
ARP incomplete 是唯一的线索。
③ 故障随机出现
尤其是监控设备频繁上下线。
④ 初次排查很难怀疑"缓存污染"
缓存问题是设备层级，而不是配置层级。
很多新人会怀疑：
• VLAN 配错
• IP 冲突
• 光纤问题
• 端口坏了
但事实上：
ARP 缓存污染是最容易被忽略、但也是最致命的。
八、这次排障让我获得的能力提升
① 真正理解了 ARP Incomplete 的意义
它不是"小问题"，常常是隐藏的大问题。
② 第一次经历数据平面单向阻塞
这种问题比配置错误更需要经验。
③ 理解了缓存机制对网络稳定性的关键影响
同 VLAN 下某一段缓存错误，都可能导致大面积故障。
④ 故障中学习了逐跳验证的重要性
逐跳 Ping 是真正的排障核心。
九、总结：ARP 故障最容易被忽视，但可能致命
ARP 表异常是网络中最容易被忽视的根因之一。
它会导致：
• 单向不通
• 偶发断连
• 抖动与丢包
• 无法获取网关
• 大规模广播影响业务
但往往只需要：
一次缓存清理，就能恢复整个网络。