网络排障实战：从双工协商到广播风暴，破解间歇性断网-北京尧图网络

做网络运维的人应该都有过这种体验——用户报障说“间歇性断网”你到现场的时候它偏偏是好的日志干干净净抓包抓了半天全是正常通信结果人一走又出事。这篇《Network Engineer Notes · Junior 03》记录的就是我在初级工程师阶段处理过的一次典型“玄学故障”整层办公网络时不时卡顿、掉线持续时间没有规律短则几十秒长则几分钟。排查过程谈不上多华丽但里面涉及的双工协商、生成树协议、广播风暴、MAC地址表抖动这些问题恰恰是刚入行的年轻人最容易忽视、也最容易翻车的知识点。这篇笔记适合正在起步阶段的网络工程师、运维新人也适合那些已经把交换原理背得滚瓜烂熟但缺少实战机会的人。我会把当天的排查思路、命令依据、配置调整以及事后复盘完整写出来尽量还原现场的真实处理过程而不是堆一堆抽象原理。想直接抄作业的朋友可以直接跳到第5节的速查表想搞明白“为什么这么查”的朋友建议从头往下看。1. 这次笔记在记什么1.1 事件背景办公室网络里的“玄学”当时的情况是这样的某园区一栋办公楼的三层从上午十点左右开始陆续有人报“网络很慢”“过一会儿就掉线”。掉线时间很不规则有人刚好在传文件的时候断有人开视频会议的时候断也有人一上午都没事。最麻烦的是等我接到工单赶过去的时候网络已经恢复“正常”了——ping网关不丢包网页打开也顺畅仿佛刚才的故障从来没发生过。这类故障在初级工程师的日常里太常见了。它不像设备宕机那样有明确的现象和告警而是“时好时坏”严重考验排障思路。如果一上来就凭感觉重启设备、换网线大概率会陷入“好一阵、坏一阵、然后又好一阵”的死循环。我当时做的第一件事不是跑现场而是先把报障工单全部翻出来按用户位置和被影响的业务做了个简单归类。这一步很关键只有把“谁在什么时间遇到了什么问题”汇总起来才能判断故障影响范围到底是一台电脑、一个工位、一个机柜还是整个楼层。1.2 为什么初级阶段的排障最容易翻车新人排障容易翻车通常不是技术原理不会而是排查顺序不对。最常见的有三种情况一是不看现象就怀疑硬件动不动就说“网线坏了”“交换机坏了”二是只盯着网络层往上查忘记二层和物理层这些更底层的东西三是抓到一点异常就无限放大比如看到几个丢包就断定是线路问题结果真正的原因藏在别的端口上。Junior 阶段还有一个特有的毛病太依赖“经验帖”。网上搜到一个症状相似的案例就直接套用结论。问题是网络故障往往是多因素叠加的光看表面症状根本分不清谁是因谁是果。这次三层楼的故障就是个典型一开始表现出来的问题在某个接入交换机上但真正的根源却是一台用户工位底下的杂牌桌面交换机。我把这次过程完整记下来不是为了证明自己排查得多厉害而是想给自己留一份“从现象到根因”的推导样本。以后再遇到类似问题至少知道往哪个方向收敛。2. 从现象到定位排障思路是怎么收敛的2.1 先别急着动手把现象问清楚接到这类间歇性故障我现在的习惯是先问清楚三件事故障影响谁、故障时正在做什么业务、故障持续多久。这三个问题的答案决定了排查方向。影响谁如果只有一个人掉线优先查网线、面板、终端网卡如果一层楼都掉重点看接入交换机、汇聚链路和网关。正在做什么传大文件时掉线多半和带宽跑满、双工异常有关视频会议时掉线往往丢包和抖动是关键指标什么都不做也掉就要怀疑广播风暴、ARP欺骗或者环路。持续多久几秒的闪断和几分钟的持续故障背后原因完全不同。几秒的闪断经常和生成树收敛、链路协商有关持续较长时间则更像DHCP问题或者二层环路。当天的情况综合下来是影响范围集中在三层某个区域的十几个工位掉线时基本都在进行普通办公操作持续时间从几十秒到几分钟不等。这个现象组合让我把首要怀疑目标放在了接入侧的二层交换网络而不是核心或网关设备。2.2 按层次收缩排查范围排障的正确姿态是从底层往上层一层层收缩物理层→数据链路层→网络层→传输层→应用层。不是每层都要花同样的时间而是用最快的方式排除掉明显不可能的层。物理层先看交换机端口、电脑网卡的状态灯是否正常线缆接头有没有松动光模块的光功率是否在正常范围。数据链路层再看端口有没有大量错误计数MAC地址表是否稳定VLAN划分是否合理有没有环路。网络层最后看网关是否可达ARP表是否异常路由是否完整。当时我先确认了物理层没有明显问题——所有相关端口都是up状态网线接头也正常。接着把重点放在数据链路层结果一查接口计数立刻发现了异常。这也是我想重点强调的一点很多新人只看端口up/down状态却完全忽略接口错误计数这是排查二层故障最大的盲区。2.3 接口计数器平时没人看故障时最靠谱接口错误计数这个东西平时没人会盯但只要链路真的有问题它是第一个给出信号的。我当天检查的那台接入交换机上连接三层办公区域的几个端口都有不同程度的CRC错误、输入错误和Late Collision晚期冲突计数在增长而且不是零星几个是持续在涨。看到Late Collision和CRC错误同时出现我心里基本有数了——这不是普通的网线质量问题能解释的。先说结论CRC错误通常意味着线缆质量差、接头接触不良或者电磁干扰而Late Collision几乎是双工不匹配的“身份证”。如果一个接口长期在涨Late Collision大概率是一端工作在全双工、另一端工作在半个双工两端的协商没有达成一致。这时候如果只看端口up/down就会得出“链路正常”的错误结论。所以我在后面写了一个排查习惯只要碰网络变慢、掉线但端口状态正常的故障第一步永远是查接口错误计数而不是去ping网关。3. 交换网络里容易忽视的三个“隐形机制”3.1 双工协商速率对上不代表没问题这就要解释一下双工协商这个坑了。速率和双工是两个完全不同的参数速率是100M还是1000M双工是同时收发还是同一时刻只能单向收发。很多人只确认速率没降就认为链路没问题却忽略了双工模式是否一致。标准的协商过程是通过链路两端互相发送快速链路脉冲来完成的。正常情况下两端都是自动协商会得到一致的结果。麻烦出在两种情况下一种是一端被人为强制设置成100M全双工另一端还是自动协商结果对端错误地降级成100M半双工另一种是老设备强制100M半双工而新终端强制100M全双工。双工不匹配的后果非常隐蔽半双工一侧在收数据的同时如果检测到信道忙就会认为发生冲突执行退避重发全双工一侧根本不做冲突检测直接把帧发出去。于是半双工侧不断重发全双工侧不断收到错误帧表现出来就是“连接没断但速度奇慢、丢包率高、偶尔断流”。当天我在楼层的接入交换机上看到Late Collision快速增长就是在往这个方向逼近。排查结果也印证了这一点有一台接入交换机上连着一根从天花板穿下来的旧网线远端面板刚好被之前的人改成过强制100M全双工。两边协商没对齐导致这个端口下的用户间歇性掉线。把面板侧的配置改回自动协商后Late Collision立刻停止增长问题缓解了一大半。3.2 生成树协议冗余设计怎么变成事故源头问题缓解了但没有彻底解决。下午上班后三层又开始有人反映掉线而且这次连交换机本身的管理地址都出现过短暂的ping不通。这种现象让我把注意力转向了广播和环路。生成树协议STP的作用是让一个存在物理环路的二层网络通过阻塞某些端口来消除环路同时保留冗余路径。它靠的是交换机之间互发BPDU来选举根桥、确定端口角色。理论上只要是支持STP的交换机组成的环都能被协议自动打破。问题恰恰出在“理论上”。办公环境里经常有用户私自加装的小型桌面交换机这种设备往往不支持STP或者默认关闭了STP。如果用户把它的两个口都插到网线墙上一个口接电脑另一个口又通过网线回到同一个接入交换机物理环路就形成了。接入交换机虽然跑着STP但环的另一端是不发BPDU的哑设备STP根本感知不到这个环广播帧就会在这个环里不断复制转发最终演变成广播风暴。当时三层的情况正是如此一台杂牌桌面交换机被塞在某个工位下方两个上行口分别接了两根网线通过墙里面的信息模块形成了环路。广播帧在环里循环放大整台接入交换机的CPU被大量协议报文和广播报文耗尽不仅用户业务受影响管理地址也一度ping不通。3.3 MAC地址表一张会“说谎”的表在定位环路的过程中我还发现了一个辅助证据交换机上的MAC地址表出现了大量“MAC地址漂移”告警。所谓漂移就是同一个MAC地址在极短时间内先后出现在不同的端口上。正常情况下一台设备只会通过一个固定端口接入网络MAC地址表会把这个对应关系稳定地记下来。但环路存在时广播帧、未知单播帧会从环路的多个方向抵达交换机同一MAC地址就可能从不同端口被反复学习到。交换机为了维持表项只能不停地更新表现出来就是MAC地址表抖动、大量未知单播泛洪以及端口之间相互影响。所以MAC地址表也是个很好的诊断工具。如果看到MAC漂移几乎可以断定二层存在环路或者有人私接设备。配合STP状态和广播流量统计一起看就能把“隐形的环”从网络里揪出来。4. 实操记录从现场到根因的完整过程4.1 第一步链路与接口状态确认我先把排查过程按顺序整理一下方便大家直接对照操作。第一步确认受影响区域涉及的交换机端口状态。重点看四样东西端口up/down状态、协商速率、双工模式、错误计数。端口状态正常不代表链路健康速率降级和双工不一致都不会让端口变down只会在错误计数上留下痕迹。当时我是在接入交换机上逐个检查这些端口记录下错误计数一直在增长的几个口并和工单上的用户位置做了对应。这一步得出了两个有效结论一是问题集中在接入侧不是上联链路二是存在双工协商问题需要处理面板配置。我先把强制双工的那根线的两端都改回自动协商然后观察错误计数Late Collision停止了增长但广播流量依然偏高说明问题没完全结束。如果你也遇到类似情况建议养成随手记录基线数据的习惯。比如把正常的错误计数、广播速率、MAC表大小记下来故障时一对比异常项会自己浮出来。4.2 第二步抓包与广播分析第二步在接入交换机上做端口镜像对受影响的端口抓包重点看广播帧比例和ARP报文行为。抓包是我当时犹豫过要不要做的操作因为办公室流量里有大量正常广播新手容易看得一头雾水。我的做法是先连续抓两分钟统计广播帧占总帧数的百分比再看有没有短时间内数量爆发的现象。正常情况下广播帧占比通常很低大概在5%以内。当天抓到的数据非常不正常广播帧比例一度超过30%而且呈周期性暴涨周期大约在几十秒左右。同时ARP报文数量激增很多是重复请求同一地址的广播ARP。这个现象直接指向二层环路——只有环路才会让广播帧被反复放大形成一波一波的洪峰。抓包这一步不建议跳过的原因在于它能帮你区分“广播风暴”和“正常业务导致的高流量”。前者是故障后者可能只是有人在传大文件处理方式完全不同。看到广播周期性暴涨的那一刻我开始怀疑物理环路而不是继续盯着双工问题修。4.3 第三步生成树与环路定位第三步检查交换机的生成树状态和端口角色。在我的预期里如果存在环路且STP正常工作应该能看到某个端口处于Blocking或Discarding状态。但实际检查发现所有接入端口都是Forwarding状态没有一个被阻塞。这是非常关键的信息。说明环路不在受管交换机的端口之间而是存在于“受管交换机——哑设备——受管交换机”这样的间接路径上。哑设备不参与STP不会发出BPDU所以受管交换机根本不知道环路存在。这也是为什么我后来坚持在所有面向终端的接入端口上开启BPDU防护BPDU Guard一旦有设备发出BPDU就立即禁用该端口从物理上切断这种“非法环路”的可能。顺着MAC地址漂移的告警记录我把发生漂移的端口找了出来两个端口都连着墙上的信息面板面板另一头最终都通向接入交换机中间隔着那台用户私接的桌面交换机。环路路径确认后事情就清楚了。4.4 第四步配置整改与验证根因确认后整改动作分成了两层。第一层是立即处理现场拔掉桌面交换机上多余的一根网线消除物理环路同时保留用户上网能力第二层是设备加固防止类似问题再次发生。我在接入侧做了一组常见的安全加固配置面向终端的接入端口统一开启BPDU防护防止私接设备导致STP被绕过开启环路检测Loopback Detection功能检测到端口收到自己发出的报文就直接关闭端口启用端口安全限制每个端口学习的MAC数量同时把所有接入端口统一设置成自动协商杜绝强制双工带来的协商不一致问题。配置下发后我重新观察了两个小时广播流量回落到正常水平MAC地址漂移告警停止接口错误计数不再增长受影响区域的用户也没有再报障。为了确认不是“暂时好转”我又连续观察了一个工作日确认故障没有复发才算收尾。5. 新人排障的常见问题与速查技巧5.1 踩过的坑别重复踩这次故障里我自己也踩了几个坑写出来给大家提个醒。第一个坑是太早下结论。一开始看到Late Collision我就以为只是双工问题修完之后差点直接关闭工单。实际上双工问题只是表象真正的大坑是后面的二层环路。网络故障经常是多重原因叠加一个异常解决后要再确认一下整体指标是否恢复而不是修完一个点就觉得万事大吉。第二个坑是忽略私接设备。办公网里的“隐形设备”远比想象中多员工自带的桌面交换机、无线路由器、各种物联网终端都能成为环路的制造者。这类设备往往不启用STP还会自己发DHCP、甚至改变VLAN转发行为。排查时要习惯性地问一句这些工位下面有没有接小交换机第三个坑是只靠ping判断故障。ping通了就认为网络没问题这是新人最常见的心态。实际上很多故障对ping流量影响很小但对大流量、突发流量极其敏感。判断链路健康接口错误计数、广播比例、丢包统计这些指标远比单纯ping网关有价值。5.2 故障排查速查表我把这次故障中用到的判断依据整理成了一张速查表以后遇到类似问题可以直接对照现象优先检查项大概率原因端口up但网络很慢接口错误计数、双工模式双工不匹配、网线质量差Late Collision持续增长两端协商参数一端强制双工一端自动协商CRC错误增长线缆、接头、信号干扰物理链路质量不合格广播流量周期性暴涨抓包统计广播帧占比二层环路、私接设备MAC地址漂移告警MAC地址表、端口对应关系环路或私接交换机交换机CPU持续偏高广播/组播/未知单播速率广播风暴、环路、异常终端掉线持续几十秒后恢复生成树收敛情况端口反复up/down、私接设备触发STP单台设备间歇性掉线面板、跳线、终端网卡物理接触不良、强制双工这张表的用途不是让你“按症状找答案”而是帮你快速定位检查方向。真正的链路推导还是要结合设备日志、错误计数、抓包数据一起看。5.3 我的笔记方法从“记录”到“复盘”最后聊聊笔记本身。Junior 03这篇能写出来很大程度上得益于我从第一天就开始坚持的记录习惯。我自己记网络工程师笔记的方法很简单每处理完一个故障就按“现象→排查过程→根因→整改→复盘”五个部分写一篇短文不追求文采只要求能让自己三个月后仍然看懂。关键是复盘部分要写清楚两个问题为什么当初的判断方向是错的如果有以及这个故障暴露了哪块知识盲区。比如这次故障我复盘时写的一句话是“速率和双工要分开看端口up不代表链路健康没有STP阻塞口不代表没有环。”这句话后来帮我在多个故障里少走了很多弯路。这种做法坚持下来积累的是真正属于自己的排障直觉而不是网上零散的经验碎片。我建议所有刚入行的朋友都试一下用一个月时间坚持记下自己接触过的每个故障哪怕只是几十字的简要记录积累三个月后回头翻你会惊讶于自己能从中提炼出多少模式。这次三层楼故障给我个人最深的体会是网络的“玄学”故障绝大多数情况下不是真的玄学而是有一些底层机制我们没看全。双工、STP、MAC学习、广播——这些平时安安静静的机制一旦有个环节被破坏就会变成用户口中的“网又坏了”。把基本功的排查路径走扎实玄学自然就消失了。

网络排障实战：从双工协商到广播风暴，破解间歇性断网

相关推荐

GPU利用率不高？从推理瓶颈到动态Batching与TensorRT优化实战

C++ STL反向迭代器的实现

CRISPE框架详解：让大语言模型输出高质量结果的提示词工程指南

更多资讯

ECE R13-H与I线联合建模：纯电动车能量回收策略落地核心

DNS主从复制与分离解析实战：高可用架构配置与排错指南

Docker Desktop 实用指南：从镜像管理到数据卷、网络与清理

AI技能包方法论：把提示词沉淀为可复用的工作流

知识工作插件全解析：从信息捕获到自动化，打造高效知识工作流

卡车域控制器系统框图深度解析：供电、总线与地线设计实战指南

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？