最近被朋友拉去处理一个挺典型的网络故障：公司里“随机终端断网”，断一下又自己恢复，客户自己查了好几天没头绪。我过去看了不到半天就定位到了根因，说穿了其实特别简单——不是硬件坏了，也不是被攻击，就是一个常用配置没配好，把整个地址池体系给搞出了冲突。
这类案例在中小企业里太常见了，处理过一次以后，你会对很多“默认配置”多一层警惕。这篇就把完整的排查过程、定位思路、修复手法和预防方案写出来，给同样被“随机断网”折磨的运维一个参考。
1. 先还原现场：随机断网到底怎么个“随机”法
1.1 故障表象与业务影响
先交代一下现场环境。这家公司办公区大概三百来个有线终端，加上几十台无线设备，网络架构不算复杂：核心交换机一台，下面挂了若干台接入交换机，网关做在核心上，DHCP由一台Windows服务器承担，无线网络走的是企业级AP加无线控制器。
故障现象用一句话概括就是：没有固定规律地，今天这个工位的电脑上不了网，明天那个工位打印机掉线，后天又变成会议室投屏设备断连。断网时间短则几十秒，长则两三分钟，然后自己恢复。掉线期间，终端ping网关会丢包，访问内网服务器和互联网都不通，但交换机端口状态、网线连接指示灯都正常。
最让人头疼的是这个“随机性”。如果只是某一个工位、某一台电脑固定断网，那大概率是网线、端口、电脑网卡的问题，逐个更换就行了。但现在是“打地鼠”式分布，没有固定时间、没有固定设备、没有固定区域，网络团队第一反应是怀疑有环路或者广播风暴，但检查了一圈也没发现明显异常。
更麻烦的是，故障会间歇性影响业务。办公时段开会开到一半投屏断了，财务导出报表时断网导致文件没保存成功，研发同事SSH到服务器敲命令敲到一半连接被重置。这些影响单独看都不致命，但组合在一起就非常影响办公效率，也会让管理层对网络团队的专业能力产生质疑。
1.2 第一轮排查：物理层与二层的常规检查
遇到这种问题，我一般不会一上来就抓包，而是先把“地基”扫一遍，排除掉低层问题，避免后面拿着错误方向去猜。
第一项检查的是物理链路。登录核心交换机和接入交换机，查看所有相关端口的错误计数，包括CRC错误、碰撞、超时错误等。同时用测线仪抽测了几个出问题比较频繁的工位网线，又查看了光模块的光功率和温度数据。结果都正常，说明物理层被排除了。
第二项检查的是二层环路和广播风暴。生成树协议的状态、端口角色、阻塞端口逐个确认，没有异常。再看交换机CPU负载和流量统计，也没发现广播包异常飙高。如果真有环路，广播流量会把交换机CPU打满，这个现象在核心交换机上会非常明显，当时完全没看到。
第三项检查的是网关和DHCP服务器状态。核心交换机CPU利用率整体不高，内存正常。Windows DHCP服务器上事件日志里没有明显的报错，地址池总量和租约数量在合理范围内，看起来也没被耗尽。
到这里，常规三板斧用完了，问题还没浮出水面。网线、端口、二层环路、设备负载这些最常见的嫌疑对象都被排除。我判断这个问题的层级大概率在三层以上，而且很可能是“间歇性地址冲突”或“ARP层面的异常交互”。这时候就要上抓包了，只有把真实的数据包拿到手里，才能把“随机”变成“可解释”。
