一个把全公司搞断网的故障，我复盘了三天

先说一句。这个号从七月底之后文章更新比较少，中间发了些科普贴图。原因不体面也不复杂：公司项目压过来，我顾不上写。停更这段时间攒了不少东西，慢慢复盘整理。

好，进正题。

先问一句：你管的网络，断过几次？

我知道答案。断过，而且不止一次。

今天讲一个我自己经手的故障。我不写"讲原理、给结论"那种复盘，我把当时的每一步误判都写出来，包括我一开始想错的方向、以及我怎么被自己的经验骗了一个半小时。

因为排障这件事，真正难的从来不是知识。是你在电话那头催、老板在旁边站着、你手心出汗的时候，还能不能按顺序来。

那天下午三点多，客户的信息科打电话进来，说三楼整层上不了网。

我做的第一件事，是让现场的人验证两个 ping：ping 网关，通；ping 外网，不通。

报障的口径是"三楼"，因为是三楼的人先炸的。但后来才知道，那会儿其他楼层也已经开始卡了，只是没人打电话——大家都以为是自己电脑的问题，在那儿重启路由器、拔网线、重连 WiFi。

这是排障里第一个特别常见的陷阱：报障的范围，不等于故障的范围。 用户报的是他感知到的，而感知有滞后、有归因偏差。后来查清楚，受影响的是整个办公 VLAN，跨了四层楼。

如果我一开始就问一句"其他楼层有没有人反馈慢"，我能早四十分钟锁定方向。我没问。

看到"ping 网关通、ping 外网不通"，我的第一反应是出口或者路由的问题。

逻辑听着很顺：网关都能 ping 通，说明二层没事、ARP 正常、终端到网关这段是好的；那问题就在网关往上——三层路由、NAT、出口链路、ACL。

我让人挨个查出口路由器：默认路由在、NAT 表项正常、ACL 没人动过、出口带宽图看着也不算满。一个半小时，什么都没查出来。

这个判断是错的。错在我把"ping 得通"理解成了"链路是好的"。

ping 通只能说明这一刻、这一个包、来回都没丢。它不能说明丢包率是 0。而当丢包率高到八成九成的时候，ping 依然会偶尔通——尤其是现场的人只 ping 了四五个包，看到有回包就回你"通的"。

更关键的是，这两件事根本不在一条路径上。ping 网关是一跳；ping 外网要过接入、汇聚、核心、出口，还得先做 DNS 解析。多跳路径上任何一段有丢包，端到端就会崩，而 ping 网关只经过一跳，它根本测不到后面任何一段。

所以"网关能通、外网不通"在丢包环境里完全是正常现象。我拿它当成"二层没问题"的证据，这是这次最大的错误。

这里我得说句公道话：看到"网关通、外网不通"先查三层，在绝大多数时候确实是正确的标准动作，我那一个半小时不算白花，换十次里有九次我就查对了。问题不在于我先查了三层，而在于三层全部查完、什么都没发现之后，我还在那儿反复查三层——没有在"假设被证伪"的那一刻回头换假设。 这才是真正的失误。

真正让我回头的，是现场那个人补的一句话：

"刚才那一下又能上了，现在又不行了。"

时通时断。

这四个字一出来，整个方向必须推倒重来。因为"完全不通"和"时通时断"是两条完全不同的排查路径——前者往配置和链路上查，后者往拥塞、环路、震荡、主备切换上查。

我让现场的人去机房，然后说了一句他大概觉得很奇怪的话：先别登设备，先看灯。

他看了几秒，说：所有口的灯都在闪，闪得特别快，而且——看着像是一起闪的，节奏一样。

到这儿我心里基本有数了。

正常的交换机，各端口流量不一样，灯的闪烁应该是杂乱无章的。所有端口同频率快闪，意味着有同一份流量正在从所有端口涌出去。 什么流量会走遍所有端口？广播、组播、和未知单播。

这就是广播风暴最经典的体征。而它只花了三秒钟、不需要登录任何设备就能看出来。

我一直跟学员强调：物理层永远先看。 灯、线、端口计数、机房温度、电源。这一步成本最低、信息量最大，却最常被跳过——因为我们坐在屏幕前，本能是先敲命令。

登上去之后，第一条命令也不是看配置，是看端口。

这条命令是华为设备上性价比最高的一条，一屏给你所有端口的 UP/DOWN、进出方向利用率（InUti/OutUti）和错包统计。

但这里有个坑，很多人不知道：这个利用率不是瞬时值。华为设备的接口流量统计默认是 300 秒的滑动窗口（可以用 set flow-stat interval 调整），你看到的是过去五分钟的平均。所以如果风暴是刚刚起来的，你敲这条命令，InUti 可能还没爬上去，你会得到一个"看起来没事"的假象。

稳妥的做法是配合着看，而且反复敲几次看趋势：

风暴打上来的时候，CPU 的反应比流量统计快。

这次的结果是：三楼那台接入交换机上，上行到汇聚的那个口，以及两个下联口，进出利用率全在 80% 以上。而那两个下联口，接的是同一台资产记录里没有的设备。

CPU 飙到七八十。管理面已经开始卡，敲命令都有延迟。

到这一步，环路的嫌疑基本成立，但我还不知道环在哪。

接下来看日志和 MAC 表。

日志里刷了一屏的 MAC 漂移记录。同一个 MAC 地址，在两个端口之间反复被学习、反复覆盖，一秒钟好几次，而且不是一个 MAC，是一大片。

这里必须插一句，因为我见过太多人在这儿理解错：

MAC 漂移不是故障，它是症状。

交换机维护一张 MAC 地址表，记录"哪个 MAC 是从哪个端口学来的"。如果同一个 MAC 在短时间内被两个不同端口反复学到、表项反复覆盖，说明同一份数据帧正在从两条不同的路径到达这台交换机。

而同一份帧能走两条路到同一个地方，只有一个含义：有一条路不该存在。

顺便说，漂移的频率能帮你区分它是不是真问题。几分钟、几十秒漂一次，涉及的 MAC 很少，多半是无线终端在 AP 之间漫游，或者服务器双网卡主备切换——这种无害，别去折腾它。一秒钟漂好几次、而且涉及大批 MAC，基本只有二层环路。

MAC 表反复震荡还会带来第二层伤害：交换机根本记不住一个 MAC 到底在哪个口，于是单播开始被泛洪，或者被送到错误的端口丢掉。这就是"时通时断"的直接来源。

顺着那个"资产记录里没有的设备"查下去，答案有点让人无语。

三楼有个部门自己在网上买了一台几十块的五口小交换机，用来给新来的同事多分几个口。装的人觉得"插一根网线万一不够用"，于是把这台小交换机插进了墙上的两个网口。

一个完美的环。

环路径是这样的：小交换机 → 墙口 A → 接入交换机 → 墙口 B → 小交换机。一个广播帧进来，从 A 口上去，接入交换机在 VLAN 内泛洪，又从 B 口下来回到小交换机，再上去一遍。无限循环。

这也解释了 MAC 表为什么在两个口之间疯狂震荡——同一批终端的帧确实在从两条路径抵达接入交换机。

但真正让我后背发凉的是下一步。我查接入交换机的 STP：

那两个口的 STP 被关掉了。

什么时候关的、谁关的，客户那边没人记得。大概是某次割接有台设备起不来，有人临时关了图省事，然后忘了开。这条配置在设备里躺了不知道多久，没人体检过。

这一步是整个故障的分水岭。

如果 STP 是开着的，接入交换机从 A 口发出的 BPDU，会被小交换机泛洪后从 B 口送回它自己——它立刻就知道"这两个口通着同一个二层域"，然后把其中一个阻塞掉。整件事在毫秒级就结束了，没有人会感知到。

STP 一关，这个自愈机制就没了。一根多插的网线，放倒了整个办公 VLAN。

而"ping 网关偶尔能通"——现在你知道为什么了：在风暴的间隙里，偶尔有几个包挤了出去。

处理本身很简单：先把 B 口 shutdown，风暴立刻停；然后让现场把那根多余的线拔掉；最后把 STP 开回来。

关于另外两条常被一起贴出来的命令，我得说清楚它们各自防什么，别当万金油。

`stp bpdu-protection` 该配，但它不是这次的解药。它防的是有人接一台会发 BPDU 的交换机进来抢根桥，而这次那台傻瓜交换机一个 BPDU 都不发，bpdu-protection 根本不会被触发。

`loopback-detect enable` 是另一套机制，它补的是 STP 覆盖不到的盲区。如果这次是小交换机自己两个口对插形成自环，那么接入交换机的下联口收不到任何回流的 BPDU，STP 也救不了你——这时候只有环路检测能发现：它往端口外发探测帧，帧从同一个口回来了，就把口关掉。

换句话说，STP 管的是"两条路通到同一个地方"，环路检测管的是"路绕回了自己"。 接入层建议两个都配，但你得知道哪条命令在挡哪一发子弹。

MAC 漂移也可以配成自动动作，具体命令和支持情况看你的平台和版本，配之前先在测试环境验一遍：

思科侧对应的大致是 spanning-tree portfast、bpduguard、storm-control broadcast level 10；自环那一类靠接口 keepalive 检测。注意 Loop Guard 防的是另一回事（阻塞口因单向链路误转发），别混用。

这个故障本身不难，难的是我走的路线。所以这一节才是我想让你记住的部分。

第一步，先问清"完全不通"还是"时通时断"。 这一句话决定了后面所有的方向。完全不通往往是配置、链路、端口 DOWN；时通时断往往是拥塞、环路、震荡、主备异常。我这次就是没问这一句。

第二步，确认真实影响范围。 别信报障范围。问：是一台机器、一个网段、一层楼，还是一个 VLAN？有线和无线是不是都受影响？这个范围会直接告诉你故障在哪一层——影响一个 VLAN 内所有人，那八成是二层的事。

第三步，物理层。 灯、线、光模块、端口错包和 CRC 计数。三秒钟的成本。

第四步，二层，看三样：端口流量利用率、MAC 漂移日志、STP 端口状态。 尤其是 STP——在有冗余链路的二层网络里，必须有端口处于阻塞或替代状态。 如果你所有互联口都显示转发，只有两种可能：要么你这张网真的是纯树形、一点冗余都没有（那你该担心的是单点故障）；要么 STP 没在干活，你是在等着出事。

第五步，才是三层。 路由表、ARP、NAT、ACL。

这个顺序不是我发明的，它就是 OSI 分层从下往上的顺序。可人在压力下的本能，是从自己最熟的那一层开始查——我最熟三层和出口，所以我一头扎进了出口。

排障的体系感，就体现在你慌的时候还能不能按顺序来。

还有一条，跟技术无关但更值钱：这个故障的真正根因不是那根网线，是"资产表里有一台没人知道的交换机"和"一条没人记得为什么关掉的命令"。 技术故障的根，很多时候扎在管理里。你把线拔了叫处理，你把私接设备和配置变更管起来，才叫解决。

讲完故障，说个我觉得挺重要的变化。

据华为官方的调整公告，HCIE 的实验考试从 2026 年 1 月 1 日起新增了"故障排查"考核模块。

我看到这消息的第一反应是：终于。

过去很长一段时间，高阶认证被人诟病"能刷"，就是因为它考的是"给你一份需求，你把它配出来"——这种题型可以背。但排障背不了。考官给你一个坏掉的网络，故障点可以是 MTU 不匹配、可以是认证密钥写错、可以是一条多余的静态路由、可以是我今天讲的这种 STP 被关掉。组合是无穷的，你只能靠一套稳定的排查顺序去逼近它。

同时，我们最近扒了三百份网络岗的招聘 JD，一个明显的趋势是：岗位描述正在从"熟悉网络故障处理"变成"具备跨域故障定位能力""能独立完成根因分析"。

厂商和企业在同时往一个方向走。这对在职的你意味着什么，我说得直白点：

会配置的人在变便宜，会修的人在变贵。

而"会修"这件事最残酷的地方在于，它没法靠看书获得。你必须见过足够多的故障。可现网不给你机会——没有哪个客户愿意让你在他的生产网络上练手，你只能等故障自己找上门，一年碰上三次，五年也就见过十几个场景。

我今天写这篇，就是想把我踩过的坑，折算成你没踩过的那几次。

你要是也有一个查了很久才找到根的故障，评论区说一句，我挑几个写成下一篇。