上午十点，内网运维老张的丢包钉钉突然炸了。财务部连发三条语音，严重说ERP系统卡得像幻灯片，故障点一下保存要转十秒。排查紧接着，内网研发那边也来凑热闹，丢包git push代码直接超时。严重我登录核心交换机一看，故障eth1/0/12接口的排查入方向错误包计数器，正以每秒几百个的内网速度往上跳。

这就是丢包典型的二层环路症状，但问题没这么简单。严重我抓了五分钟的故障流量包，发现广播帧占比高达47%，排查正常网络这个数字不该超过5%。顺着MAC地址表一查，发现同一个MAC在三个不同接口上反复横跳——这可不是环路能解释的，更像是有设备在疯狂发送源MAC地址变化的伪造帧。

排查到这一步，我反而冷静下来了。先别急着拔线，用shutdown命令把财务部那台接入交换机的上联口先禁掉，广播风暴立刻降了九成。但剩下的10%还在跳，说明源头不止一处。我又禁掉研发部的上联口，这回广播彻底归零。

两个口都禁了，业务倒是恢复了，可问题没解决。我跑到财务部机房，发现角落里多了一台没标签的小交换机，四个口全插满了网线，其中一根直接连到了墙壁信息点上。这玩意儿八成是行政上周装监控时顺手接的，形成了一个物理环路。拔掉那根线，再看研发部那边，原来是有位同事自己带了个家用路由器，把DHCP服务给打开了，跟公司核心的DHCP服务器抢地址，导致大量设备拿到错误网关后疯狂重传。

处理完这两处，接口错误包计数器总算稳定在个位数。但我要说的是，这类故障百分之八十不是设备老化，而是人为的、无意的拓扑变更。内网丢包最怕的就是这种“幽灵设备”，你查配置查路由查半天，结果在某个没人注意的角落躺着个几十块钱的Hub。

所以我现在养成了个习惯，每季度用LLDP协议扫一遍全网，把非标准设备全部揪出来拍照留档。另外，所有接入交换机的BPDU Guard必须开启，一旦检测到环路就自动断口，别等业务报障才被动响应。这次故障从爆发到定位花了四十分钟，其中半小时浪费在翻查物理链路图上——图纸和现实严重脱节，这比丢包本身更可怕。

最后说句实在话，网络排查七分靠工具，三分靠经验，剩下九十分全靠平时把基础台账做扎实。你要是连哪个口接了什么设备都心里没数，那丢包的时候只能靠玄学猜了。