如果你在小企业做过网络运维大概率遇到过这种让人血压飙升的瞬间明明只是把一台新路由器往核心交换机上一插刚接上去测试一切正常网页能开、网关也Ping得通你正准备收工几分钟后整个办公室的网络突然全断交换机端口指示灯疯狂闪烁领导电话紧接着就打了进来所有人都在问同一个问题——刚才还好好的怎么突然就不行了这个场景我经历过不止一次每次复盘完都会发现根因并不复杂。今天就把这种路由器接入核心交换机后延迟性断网的故障完整拆一遍先说清楚那几分钟里到底发生了什么再给出我从物理层到协议层的完整排查链路以及恢复网络、避免复发的具体操作。1. 故障现场还原从刚接上正常到全网断开只隔了几分钟1.1 当天下午发生了什么当时是普通工作日的中午机房同事把一台新路由器搬到机柜旁打算把它接到核心交换机上做一个新业务的出口。接线方式很简单路由器的WAN口接核心交换机的空闲端口LAN口也接到了核心交换机的另一个空闲端口理由是方便远程管理这台路由器。接完后从电脑上测试打开网页正常、Ping网关也通管理页面登录流畅一切看起来都符合预期。大约三分钟后报障电话来了所有终端无法上网内网也开始有人反映访问不了共享文件夹。我到机柜前一看核心交换机上好几个端口指示灯以极高频率闪烁那不是正常的数据流量节奏更像是一个端口在疯狂收发包。整个网络已经处于半瘫痪状态。1.2 几分钟这个时间点是最有价值的诊断线索很多搞运维的朋友一遇到全网断网就习惯性重启核心交换机、重启路由器或者直接进入拔线试错模式。但真正应该做的第一步是先解读几分钟这个时间特征。如果故障是物理接线错误导致的二层环路广播帧会指数级复制但网络不会在插入网线的瞬间就瘫痪。从环路形成到广播洪流把交换机的CPU、端口缓存全部耗尽需要一个量变到质变的过程这个窗口通常就是几十秒到几分钟。如果是网关IP冲突也会有类似的延迟。新路由器接入后不会立刻清掉全网终端本地的ARP缓存终端只有在缓存老化、重新发起ARP请求之后才会拿到错误的新映射关系断网才会集中爆发。如果是DHCP冲突更加是慢性发作在租约到期续租之前存量终端手中的IP和网关参数依然有效只有陆续续租的终端拿到错误配置后才会掉线。所以刚接上正常过了几分钟突然全断恰恰说明这不是简单的物理连接损坏而是协议层面的冲突在按各自规律发酵。这个时间窗口是整个排障里最值得盯住的线索。1.3 断网前的症状清单把常见症状整理成一份清单方便对照参考全网终端原本Ping通的网关突然不通核心交换机上某个或某几个端口指示灯闪烁频率异常高核心交换机日志里能看到CPU负载明显飙升终端拔插网线或重启后能短暂恢复但几十秒后再次断开如果在接入端口抓包能看到大量重复的广播帧和ARP请求在同一个VLAN里反复出现部分设备能够获取到IP地址但无法访问外部网络。出现以上任意几个特征都值得按后面这套排查链路走一遍。2. 延迟几分钟才断网背后的三种故障机制2.1 广播风暴的雪崩效应需要时间酝酿交换机的基本行为是把未知单播、广播和组播帧从所有端口泛洪出去。一旦网络里出现二层环路这些帧就会从一个端口进入再从另一个端口绕出来绕一圈又被同一台交换机收到然后再次泛洪每一次循环都会产生新的副本。为什么刚接上还能上网因为在最开始几十秒广播流量虽然已经在环路里循环但交换机还有余力处理正常数据帧。随着网络上任何一台设备发出一个ARP广播风暴就会迅速升级循环复制的广播帧越来越多端口利用率逼近100%交换机CPU被广播处理占满正常数据帧被彻底挤掉。这个从有噪声到全堵死的过程刚好就是几分钟量级。用一个生活化的类比一个会议室的回声起初有一个人说话大家还能听清当回声被重复放大几轮之后整个屋子只剩下噪音谁也听不见谁。2.2 STP端口状态机环路不是一接入就立刻生效二层环路能不能被快速阻断取决于STP生成树协议是否真的在运行。默认情况下STP把端口从阻塞状态切换到转发状态需要经过阻塞、监听、学习、转发四个状态最坏情况约50秒收敛。但如果新接入的端口被配置成边缘端口或者设备本身关闭了STP端口就会直接进入转发状态环路从一开始就存在没有任何阻断机制。这里有个容易被忽略的场景不少中小型网络的核心交换机为了保证即插即用默认端口就是转发模式遇到设备重启或者新设备接入不会重新计算生成树。如果不主动开启STP并正确配置边缘端口BPDU根本不会参与交换环路就一直存在。这一点在GNS3、eNSP这类模拟器里也很常见——很多人做实验时根本不配STP拓扑一出现环网络就风暴。2.3 ARP缓存老化网关冲突的潜伏期终端访问网关时会先查本地ARP缓存缓存里记录的是网关IP所对应的MAC地址。新接入的路由器如果LAN口地址和核心交换机的网关接口地址相同它会在接通后发出免费ARP向全网宣告这个IP现在归我。收到免费ARP的设备会按逻辑把网关MAC更新为新路由器的MAC。但是已经建立的会话在ARP缓存没有到期之前不会立即中断。一旦缓存老化终端再发ARP请求时新路由器会抢先应答数据就会被送到错误设备上网络在几分钟内集中崩溃。不同设备的ARP老化时间不太一样Windows的ARP缓存通常在几十秒到几分钟之间波动这正好和标题里过了几分钟的现象吻合。懂了这一点再看很多相关实验里的IP数据转发、ARP报文交换就明白底层链路是怎样的了。2.4 DHCP租约与续租慢性发作的另一个解释再来看DHCP冲突。新接入的路由器如果自带DHCP服务且没有关闭它的地址池很可能和原有网络的地址段重叠甚至完全一样。网络里出现两台DHCP服务器之后新建连接或续租的终端会随机收到不同服务器给出的OFFER。如果新路由器给出的网关、DNS和原有网络不同拿到错误配置的终端自然无法上网。为什么也是几分钟后因为存量终端的租约还没到期它们在续租之前依然使用旧参数。真正的新入网设备却不受保护只要有人在这几分钟内重启了电脑或者新终端接入故障就会快速扩散。部分路由器的DHCP模块还做冲突检测发现地址冲突会主动跳过这会让整个故障表现得更随机——时好时坏最容易误导排查方向。3. 按层排查我从核心交换机入手的完整诊断链路3.1 第一步先看端口状态和错误计数确认物理层是否有异常接到断网报障之后不要急着重启任何设备。先登录核心交换机看新接入路由器的那个端口当前的状态。华为设备在系统视图下执行如下命令可以检查端口速率、双工模式以及input/output方向的错误计数system-view display interface GigabitEthernet0/0/1重点检查几个字段Input errors或Output errors是否在快速增长CRC错误、runts、giants是否异常端口收发的字节数和包数是否在几秒内出现数十倍的暴涨。如果是环路引起的风暴端口的错误计数不一定会涨但收发字节数会呈指数级上升。我习惯的做法是间隔五秒执行两次display interface对比两次的包计数变化增长幅度异常就高度怀疑二层环路。物理端口的快速判断还有一招直接看交换机端口指示灯。风暴时端口LED会以极高频率连续闪烁而不是正常流量那种有节奏的呼吸感。这个经验在机房现场非常实用。3.2 第二步查MAC地址表和CPU负载锁定二层环路物理层排除之后下一个重点就是二层。正常情况下一台设备的MAC地址只会出现在交换机的某一个端口上。存在环路时同一个帧会沿环路反复到达交换机的不同端口MAC地址表就会在多个端口之间反复横跳。在华为设备上我通常这样查display mac-address display mac-address flap record display cpu-usage先看是否存在大量MAC地址在端口间翻动再看CPU使用率。环路导致的广播风暴会让CPU在短时间内飙升到60%甚至90%以上这个指标非常直观。锐捷和思科设备上对应的命令是show mac address-table和show cpu utilization原理完全一样。如果看到同一个MAC在多个端口上出现且不断更替基本可以确认网络中有环。3.3 第三步核对网关与路由表排除三层转发问题二层没问题之后马上切到三层视角。在核心交换机上查看路由表和ARP表display ip routing-table display arp | include 192.168.1.1执行这两条的目的有三个确认VLANIF接口的IP地址是否和新接入路由器的LAN口地址重复看路由表里是否出现了指向新路由器的异常路由或等价默认路由查网关IP对应的MAC地址再反查这个MAC落在哪个物理端口。如果网关IP对应的MAC落在了新路由器接入的那几个端口上而不是核心交换机自身的VLANIF接口那就说明ARP层面已经发生了真假网关劫持。这是非常典型的症状。3.4 第四步查DHCP租约定位地址分配冲突最后看DHCP服务状态。华为设备上可以执行display dhcp server statistics display dhcp server binding第一条能看出交换机本机DHCP服务的收发统计如果出现大量DECLINE或者异常REQUEST说明地址分配过程中存在冲突第二条能查看已经分配的租约抽查几个终端的IP、网关、DNS参数是否正常。同时找一台掉线的终端在Windows上运行ipconfig /all重点看三项IP地址所在网段、默认网关地址、DNS服务器地址。如果终端获取到的网关是192.168.1.1这种新路由器默认地址而原有网络实际网关是10.0.0.1那就是两台DHCP服务器在打架。平时带着抓包习惯的人在核心交换机的镜像口抓一段DHCP报文会看得更明白同一份DHCP DISCOVER对应的OFFER来自两个不同的服务器IP冲突一目了然。为方便对照我把三种高频原因的关键特征整理成一个表格故障类型关键特征确认命令时间特征二层环路/广播风暴端口计数暴涨、CPU飙升、MAC翻动display mac-address flap record、display cpu-usage几十秒到几分钟网关ARP冲突网关MAC出现在错误端口display arp、display mac-addressARP缓存老化后数分钟集中断网DHCP冲突客户端网关/网段错误、存在多DHCP服务器display dhcp server statistics租约续租后渐进扩散4. 头号元凶一根多余的网线构成二层环路4.1 环路是怎么在看似正常的接法里悄悄形成的我这次排障的最终结论就是环路路由器WAN口接到了核心交换机端口1LAN口又接到了核心交换机的端口2。从交换机视角看从端口1进来的帧可以从端口2转出去再从路由器的LAN口被路由器的内部芯片转回WAN口又回到交换机端口1完美的三角形循环。现实中还有另一种常见变体核心交换机上联着一台汇聚交换机新路由器既连着核心交换机又连着汇聚交换机拓扑层面形成了更大的三角形环。这类接线在拓扑图上根本看不出来因为你不会把路由器上多余的管理口当成数据通道。经历过这次事件后我给自己定的规矩是凡是新接入一台三层设备先把它的所有网口WAN、LAN、管理口画在一张拓扑草图上看有没有形成闭环。4.2 交换机为什么没能在第一时间切断环路理论上只要网络里存在环路STP应该在几秒内把其中一个端口置为阻塞状态。实际没有阻断通常原因是以下三者之一核心交换机全局没有开启STP或者配置成了其他模式接入端口被设置成边缘端口/直通转发模式收到BPDU也不参与生成树计算端口之间划分在不同的VLANBPDU无法跨VLAN协商。华为设备上可以用display stp brief查看端口状态确认相关端口是否都处于FORWARDING状态。如果本该构成环的两个端口同时是FORWARDING说明STP根本没有把环断掉。同样的检查思路也适用于锐捷、思科设备。只看拓扑不看STP状态是排障中最容易踩的坑。4.3 用拔线验证法一锤定音在完成所有理论分析之前现场抢修有一条时效性最高的验证路径把疑似构成环路的冗余线路直接拔掉。如果拔掉路由器LAN口到核心交换机的那根线后全网立即恢复正常那根因就直接锁定为二层环路。这个方法不需要任何命令风险极低适合紧急恢复。我当时拔线后核心交换机CPU从85%瞬间回落到5%全网终端恢复上网过程快得让人想拍桌子——原来罪魁祸首就是旁边那根看起来人畜无害的网线。要注意拔线前务必记住线序和端口位置确认根因后还需要把它重新规划进拓扑否则恢复完就忘了原接线后续反而麻烦。5. 容易被忽略的第二类原因网关冲突与DHCP打架5.1 真假网关路由器LAN口和交换机VLANIF用了同一个IP虽然这次事故根因是环路但网关地址冲突是另一种非常符合几分钟后全断网特征的高频故障。很多家用级路由器和入门级企业路由器的默认LAN地址都是192.168.1.1而不少小企业的核心交换机VLANIF网关地址也是192.168.1.1。路由器接入后发出的免费ARP会让全网设备以为192.168.1.1这个IP的新主人是这台路由器。终端访问网关时ARP请求会得到多个回答最后更新的那一个占优数据流被引导到路由器上。路由器没有到外网的正确路由于是所有跨网段流量全部被丢弃。刚开始为什么正常因为终端ARP缓存里还保留着核心交换机VLANIF接口的MAC。等到缓存老化又收到路由器发来的免费ARP流量就全部走向错误路径。Windows的ARP缓存寿命通常就是几分钟这就把故障变成了延迟爆发。5.2 多DHCP服务器设备拿到错误参数后的连锁反应如果新路由器本身只是用来做测试或者旁路管理它的DHCP服务默认开启就会祸害全网。典型情况是路由器LAN口连着核心交换机默认DHCP池是192.168.1.2到192.168.1.254而核心交换机原有的DHCP池可能也是同样的网段。新终端发送DHCP DISCOVER之后两台DHCP服务器都会应答谁快谁先到终端就采纳谁。如果终端拿到的是新路由器分配的网关地址出网数据就会被导向路由器而路由器又没有建立正确的NAT和路由包全部被丢弃。这种故障最麻烦的地方在于它有随机性部分终端拿到正确参数部分终端拿到错误参数表现为有人能上网有人不能上网重启一下又变了。这也是DHCP冲突和环路最明显的区别——环路一断就是全断DHCP冲突往往还有幸存者。5.3 用几条命令快速区分这两类问题一台掉线终端上按这个顺序排查就能快速定性执行ipconfig /all看默认网关地址是否还是原来的网关。如果网关变成了新路由器的LAN口IP那就是DHCP冲突如果网关IP没变再执行arp -a查看网关IP对应的MAC地址。接着登录核心交换机用display mac-address反查该MAC落在哪个端口。MAC不是核心交换机的VLANIF口而是落在了新路由器接入的端口上那就是网关ARP冲突如果网关IP正常、MAC也正常再tracert外网地址看从第几跳开始丢包。第一跳能到核心交换机网关说明二层三层转发正常问题在更上层的NAT或路由策略。这套组合拳基本可以在五分钟内区分出故障源头。6. 恢复与加固从救急到治本的完整操作6.1 五分钟内恢复全网通信的应急操作任何理论分析都替代不了现场止血。遇到全网断网时最高优先级是恢复业务而不是追求优雅的排障过程。通用操作顺序把新接入路由器的所有连接从核心交换机上断开让网络回到本次变更前的状态观察核心交换机CPU是否回落、端口指示灯是否恢复正常频率抽查几台终端确认恢复上网确认恢复后再回到配置台分析根因并做加固。在这个阶段不要重启核心交换机。重启意味着把所有设备、所有MAC地址表、所有ARP缓存全部清空等于把整个网络推倒重来。如果根因没找出来重启之后故障照样会复发而且影响范围会更大。6.2 正确接入新路由器WAN口、LAN口与管理路径的规划恢复之后要解决的是未来怎么接才对。如果新路由器是作为新的出口网关使用接线原则很简单WAN口接上游出口LAN口只接内网需要使用的设备或独立接入交换机不要把LAN口和核心交换机的端口同时连成一个环。如果必须让路由器LAN口和核心交换机相连用于管理就要保证核心交换机侧已经开启STP且该端口配置为边缘端口加BPDU保护。如果新路由器只是作为旁路设备测试或者管理跳板更稳妥的接入方式如下先把路由器单独接一台电脑登录管理页面把LAN口地址修改为与现有内网不冲突的网段比如现有网络是192.168.1.0/24就把路由器的LAN改成192.168.88.1/24关闭路由器自带的DHCP服务或者把DHCP池设置成独立网段只把LAN口接到核心交换机WAN口不接任何与核心交换机存在回路的线路在核心交换机侧为该端口配置正确的access VLAN、边缘端口和BPDU保护。6.3 开启RSTP与BPDU保护让网络自己防环只拔掉一根线修复故障不加固STP配置等于埋雷。下次再有任何人误接一条线全网照样瘫痪。正常的加固方案如下。华为设备上全局开启快速生成树并给接入端口配置边缘端口和BPDU保护system-view stp mode rstp stp bpdu-protection interface GigabitEthernet0/0/1 port link-type access port default vlan 10 stp edged-port enable思科/锐捷体系对应的配置逻辑是spanning-tree mode rapid-pvst interface GigabitEthernet0/1 spanning-tree portfast spanning-tree bpduguard enable有条件的话还可以开启交换机的环路检测功能。华为设备上使用loopback-detection检测到环路后会按策略自动关闭对应端口避免风暴扩散。配置完成后用display stp brief确认关键端口状态再把之前拔掉的线接回去观察端口是否被正确阻断。这一轮做完才算真正把故障关闭。7. 这次事故沉淀下来的排查习惯7.1 接入新设备前的三项例行检查跑过一次全网断网之后我给自己列了一个接入新设备前的检查清单后面基本没有再踩过同样的大坑拓扑核对把新设备所有网口画进现有拓扑图一旦发现任何闭环可能先想好阻断方式协议冲突检查新设备的默认IP、DHCP池、网关地址是否和现有网络重叠配置隔离新设备在配置完成前先用独立管理网段接入确认无误后再并入生产路径。这三项检查加起来不会超过五分钟却能把80%的延迟性断网扼杀在接入之前。7.2 网络变更后的观察期与回滚预案网络变更之后一定要留出至少10到15分钟的观察期再离开现场。这个故障里前几分钟一切正常极具迷惑性——如果接到网线后马上走人十分钟后就会在全楼听到断网了的喊声。同时每次变更前记录原来的接线方式和核心交换机的配置状态。变更出现异常时回滚动作应该早就想好拔掉哪根线、改回哪个IP、关掉哪个DHCP服务这些操作要做到不需要现场思考。手里的故障应急文档越短越好让一个刚值班的同事照着做也能恢复网络。7.3 一个值得记住的判断口诀把这次经验压缩成一句话新接入设备后网络延迟性瘫痪首要怀疑三件事——环路、ARP网关冲突、DHCP冲突排查优先级按这个顺序来。环路看端口计数和CPU网关冲突看ARP表DHCP冲突看租约参数。顺序对了恢复时间能压缩一半以上。我自己经历这种事故次数不算少最近再遇到类似报障已经能在五分钟内把范围缩小到具体端口。说句实在话网络故障并不可怕可怕的是在错误方向上反复重启设备、反复拔线把一次本可以五分钟解决的问题拖成一个小时的抢修战。希望这篇实操复盘能帮你少走几条弯路。
路由器接入核心交换机后延迟断网：环路、ARP与DHCP冲突排查指南
如果你在小企业做过网络运维大概率遇到过这种让人血压飙升的瞬间明明只是把一台新路由器往核心交换机上一插刚接上去测试一切正常网页能开、网关也Ping得通你正准备收工几分钟后整个办公室的网络突然全断交换机端口指示灯疯狂闪烁领导电话紧接着就打了进来所有人都在问同一个问题——刚才还好好的怎么突然就不行了这个场景我经历过不止一次每次复盘完都会发现根因并不复杂。今天就把这种路由器接入核心交换机后延迟性断网的故障完整拆一遍先说清楚那几分钟里到底发生了什么再给出我从物理层到协议层的完整排查链路以及恢复网络、避免复发的具体操作。1. 故障现场还原从刚接上正常到全网断开只隔了几分钟1.1 当天下午发生了什么当时是普通工作日的中午机房同事把一台新路由器搬到机柜旁打算把它接到核心交换机上做一个新业务的出口。接线方式很简单路由器的WAN口接核心交换机的空闲端口LAN口也接到了核心交换机的另一个空闲端口理由是方便远程管理这台路由器。接完后从电脑上测试打开网页正常、Ping网关也通管理页面登录流畅一切看起来都符合预期。大约三分钟后报障电话来了所有终端无法上网内网也开始有人反映访问不了共享文件夹。我到机柜前一看核心交换机上好几个端口指示灯以极高频率闪烁那不是正常的数据流量节奏更像是一个端口在疯狂收发包。整个网络已经处于半瘫痪状态。1.2 几分钟这个时间点是最有价值的诊断线索很多搞运维的朋友一遇到全网断网就习惯性重启核心交换机、重启路由器或者直接进入拔线试错模式。但真正应该做的第一步是先解读几分钟这个时间特征。如果故障是物理接线错误导致的二层环路广播帧会指数级复制但网络不会在插入网线的瞬间就瘫痪。从环路形成到广播洪流把交换机的CPU、端口缓存全部耗尽需要一个量变到质变的过程这个窗口通常就是几十秒到几分钟。如果是网关IP冲突也会有类似的延迟。新路由器接入后不会立刻清掉全网终端本地的ARP缓存终端只有在缓存老化、重新发起ARP请求之后才会拿到错误的新映射关系断网才会集中爆发。如果是DHCP冲突更加是慢性发作在租约到期续租之前存量终端手中的IP和网关参数依然有效只有陆续续租的终端拿到错误配置后才会掉线。所以刚接上正常过了几分钟突然全断恰恰说明这不是简单的物理连接损坏而是协议层面的冲突在按各自规律发酵。这个时间窗口是整个排障里最值得盯住的线索。1.3 断网前的症状清单把常见症状整理成一份清单方便对照参考全网终端原本Ping通的网关突然不通核心交换机上某个或某几个端口指示灯闪烁频率异常高核心交换机日志里能看到CPU负载明显飙升终端拔插网线或重启后能短暂恢复但几十秒后再次断开如果在接入端口抓包能看到大量重复的广播帧和ARP请求在同一个VLAN里反复出现部分设备能够获取到IP地址但无法访问外部网络。出现以上任意几个特征都值得按后面这套排查链路走一遍。2. 延迟几分钟才断网背后的三种故障机制2.1 广播风暴的雪崩效应需要时间酝酿交换机的基本行为是把未知单播、广播和组播帧从所有端口泛洪出去。一旦网络里出现二层环路这些帧就会从一个端口进入再从另一个端口绕出来绕一圈又被同一台交换机收到然后再次泛洪每一次循环都会产生新的副本。为什么刚接上还能上网因为在最开始几十秒广播流量虽然已经在环路里循环但交换机还有余力处理正常数据帧。随着网络上任何一台设备发出一个ARP广播风暴就会迅速升级循环复制的广播帧越来越多端口利用率逼近100%交换机CPU被广播处理占满正常数据帧被彻底挤掉。这个从有噪声到全堵死的过程刚好就是几分钟量级。用一个生活化的类比一个会议室的回声起初有一个人说话大家还能听清当回声被重复放大几轮之后整个屋子只剩下噪音谁也听不见谁。2.2 STP端口状态机环路不是一接入就立刻生效二层环路能不能被快速阻断取决于STP生成树协议是否真的在运行。默认情况下STP把端口从阻塞状态切换到转发状态需要经过阻塞、监听、学习、转发四个状态最坏情况约50秒收敛。但如果新接入的端口被配置成边缘端口或者设备本身关闭了STP端口就会直接进入转发状态环路从一开始就存在没有任何阻断机制。这里有个容易被忽略的场景不少中小型网络的核心交换机为了保证即插即用默认端口就是转发模式遇到设备重启或者新设备接入不会重新计算生成树。如果不主动开启STP并正确配置边缘端口BPDU根本不会参与交换环路就一直存在。这一点在GNS3、eNSP这类模拟器里也很常见——很多人做实验时根本不配STP拓扑一出现环网络就风暴。2.3 ARP缓存老化网关冲突的潜伏期终端访问网关时会先查本地ARP缓存缓存里记录的是网关IP所对应的MAC地址。新接入的路由器如果LAN口地址和核心交换机的网关接口地址相同它会在接通后发出免费ARP向全网宣告这个IP现在归我。收到免费ARP的设备会按逻辑把网关MAC更新为新路由器的MAC。但是已经建立的会话在ARP缓存没有到期之前不会立即中断。一旦缓存老化终端再发ARP请求时新路由器会抢先应答数据就会被送到错误设备上网络在几分钟内集中崩溃。不同设备的ARP老化时间不太一样Windows的ARP缓存通常在几十秒到几分钟之间波动这正好和标题里过了几分钟的现象吻合。懂了这一点再看很多相关实验里的IP数据转发、ARP报文交换就明白底层链路是怎样的了。2.4 DHCP租约与续租慢性发作的另一个解释再来看DHCP冲突。新接入的路由器如果自带DHCP服务且没有关闭它的地址池很可能和原有网络的地址段重叠甚至完全一样。网络里出现两台DHCP服务器之后新建连接或续租的终端会随机收到不同服务器给出的OFFER。如果新路由器给出的网关、DNS和原有网络不同拿到错误配置的终端自然无法上网。为什么也是几分钟后因为存量终端的租约还没到期它们在续租之前依然使用旧参数。真正的新入网设备却不受保护只要有人在这几分钟内重启了电脑或者新终端接入故障就会快速扩散。部分路由器的DHCP模块还做冲突检测发现地址冲突会主动跳过这会让整个故障表现得更随机——时好时坏最容易误导排查方向。3. 按层排查我从核心交换机入手的完整诊断链路3.1 第一步先看端口状态和错误计数确认物理层是否有异常接到断网报障之后不要急着重启任何设备。先登录核心交换机看新接入路由器的那个端口当前的状态。华为设备在系统视图下执行如下命令可以检查端口速率、双工模式以及input/output方向的错误计数system-view display interface GigabitEthernet0/0/1重点检查几个字段Input errors或Output errors是否在快速增长CRC错误、runts、giants是否异常端口收发的字节数和包数是否在几秒内出现数十倍的暴涨。如果是环路引起的风暴端口的错误计数不一定会涨但收发字节数会呈指数级上升。我习惯的做法是间隔五秒执行两次display interface对比两次的包计数变化增长幅度异常就高度怀疑二层环路。物理端口的快速判断还有一招直接看交换机端口指示灯。风暴时端口LED会以极高频率连续闪烁而不是正常流量那种有节奏的呼吸感。这个经验在机房现场非常实用。3.2 第二步查MAC地址表和CPU负载锁定二层环路物理层排除之后下一个重点就是二层。正常情况下一台设备的MAC地址只会出现在交换机的某一个端口上。存在环路时同一个帧会沿环路反复到达交换机的不同端口MAC地址表就会在多个端口之间反复横跳。在华为设备上我通常这样查display mac-address display mac-address flap record display cpu-usage先看是否存在大量MAC地址在端口间翻动再看CPU使用率。环路导致的广播风暴会让CPU在短时间内飙升到60%甚至90%以上这个指标非常直观。锐捷和思科设备上对应的命令是show mac address-table和show cpu utilization原理完全一样。如果看到同一个MAC在多个端口上出现且不断更替基本可以确认网络中有环。3.3 第三步核对网关与路由表排除三层转发问题二层没问题之后马上切到三层视角。在核心交换机上查看路由表和ARP表display ip routing-table display arp | include 192.168.1.1执行这两条的目的有三个确认VLANIF接口的IP地址是否和新接入路由器的LAN口地址重复看路由表里是否出现了指向新路由器的异常路由或等价默认路由查网关IP对应的MAC地址再反查这个MAC落在哪个物理端口。如果网关IP对应的MAC落在了新路由器接入的那几个端口上而不是核心交换机自身的VLANIF接口那就说明ARP层面已经发生了真假网关劫持。这是非常典型的症状。3.4 第四步查DHCP租约定位地址分配冲突最后看DHCP服务状态。华为设备上可以执行display dhcp server statistics display dhcp server binding第一条能看出交换机本机DHCP服务的收发统计如果出现大量DECLINE或者异常REQUEST说明地址分配过程中存在冲突第二条能查看已经分配的租约抽查几个终端的IP、网关、DNS参数是否正常。同时找一台掉线的终端在Windows上运行ipconfig /all重点看三项IP地址所在网段、默认网关地址、DNS服务器地址。如果终端获取到的网关是192.168.1.1这种新路由器默认地址而原有网络实际网关是10.0.0.1那就是两台DHCP服务器在打架。平时带着抓包习惯的人在核心交换机的镜像口抓一段DHCP报文会看得更明白同一份DHCP DISCOVER对应的OFFER来自两个不同的服务器IP冲突一目了然。为方便对照我把三种高频原因的关键特征整理成一个表格故障类型关键特征确认命令时间特征二层环路/广播风暴端口计数暴涨、CPU飙升、MAC翻动display mac-address flap record、display cpu-usage几十秒到几分钟网关ARP冲突网关MAC出现在错误端口display arp、display mac-addressARP缓存老化后数分钟集中断网DHCP冲突客户端网关/网段错误、存在多DHCP服务器display dhcp server statistics租约续租后渐进扩散4. 头号元凶一根多余的网线构成二层环路4.1 环路是怎么在看似正常的接法里悄悄形成的我这次排障的最终结论就是环路路由器WAN口接到了核心交换机端口1LAN口又接到了核心交换机的端口2。从交换机视角看从端口1进来的帧可以从端口2转出去再从路由器的LAN口被路由器的内部芯片转回WAN口又回到交换机端口1完美的三角形循环。现实中还有另一种常见变体核心交换机上联着一台汇聚交换机新路由器既连着核心交换机又连着汇聚交换机拓扑层面形成了更大的三角形环。这类接线在拓扑图上根本看不出来因为你不会把路由器上多余的管理口当成数据通道。经历过这次事件后我给自己定的规矩是凡是新接入一台三层设备先把它的所有网口WAN、LAN、管理口画在一张拓扑草图上看有没有形成闭环。4.2 交换机为什么没能在第一时间切断环路理论上只要网络里存在环路STP应该在几秒内把其中一个端口置为阻塞状态。实际没有阻断通常原因是以下三者之一核心交换机全局没有开启STP或者配置成了其他模式接入端口被设置成边缘端口/直通转发模式收到BPDU也不参与生成树计算端口之间划分在不同的VLANBPDU无法跨VLAN协商。华为设备上可以用display stp brief查看端口状态确认相关端口是否都处于FORWARDING状态。如果本该构成环的两个端口同时是FORWARDING说明STP根本没有把环断掉。同样的检查思路也适用于锐捷、思科设备。只看拓扑不看STP状态是排障中最容易踩的坑。4.3 用拔线验证法一锤定音在完成所有理论分析之前现场抢修有一条时效性最高的验证路径把疑似构成环路的冗余线路直接拔掉。如果拔掉路由器LAN口到核心交换机的那根线后全网立即恢复正常那根因就直接锁定为二层环路。这个方法不需要任何命令风险极低适合紧急恢复。我当时拔线后核心交换机CPU从85%瞬间回落到5%全网终端恢复上网过程快得让人想拍桌子——原来罪魁祸首就是旁边那根看起来人畜无害的网线。要注意拔线前务必记住线序和端口位置确认根因后还需要把它重新规划进拓扑否则恢复完就忘了原接线后续反而麻烦。5. 容易被忽略的第二类原因网关冲突与DHCP打架5.1 真假网关路由器LAN口和交换机VLANIF用了同一个IP虽然这次事故根因是环路但网关地址冲突是另一种非常符合几分钟后全断网特征的高频故障。很多家用级路由器和入门级企业路由器的默认LAN地址都是192.168.1.1而不少小企业的核心交换机VLANIF网关地址也是192.168.1.1。路由器接入后发出的免费ARP会让全网设备以为192.168.1.1这个IP的新主人是这台路由器。终端访问网关时ARP请求会得到多个回答最后更新的那一个占优数据流被引导到路由器上。路由器没有到外网的正确路由于是所有跨网段流量全部被丢弃。刚开始为什么正常因为终端ARP缓存里还保留着核心交换机VLANIF接口的MAC。等到缓存老化又收到路由器发来的免费ARP流量就全部走向错误路径。Windows的ARP缓存寿命通常就是几分钟这就把故障变成了延迟爆发。5.2 多DHCP服务器设备拿到错误参数后的连锁反应如果新路由器本身只是用来做测试或者旁路管理它的DHCP服务默认开启就会祸害全网。典型情况是路由器LAN口连着核心交换机默认DHCP池是192.168.1.2到192.168.1.254而核心交换机原有的DHCP池可能也是同样的网段。新终端发送DHCP DISCOVER之后两台DHCP服务器都会应答谁快谁先到终端就采纳谁。如果终端拿到的是新路由器分配的网关地址出网数据就会被导向路由器而路由器又没有建立正确的NAT和路由包全部被丢弃。这种故障最麻烦的地方在于它有随机性部分终端拿到正确参数部分终端拿到错误参数表现为有人能上网有人不能上网重启一下又变了。这也是DHCP冲突和环路最明显的区别——环路一断就是全断DHCP冲突往往还有幸存者。5.3 用几条命令快速区分这两类问题一台掉线终端上按这个顺序排查就能快速定性执行ipconfig /all看默认网关地址是否还是原来的网关。如果网关变成了新路由器的LAN口IP那就是DHCP冲突如果网关IP没变再执行arp -a查看网关IP对应的MAC地址。接着登录核心交换机用display mac-address反查该MAC落在哪个端口。MAC不是核心交换机的VLANIF口而是落在了新路由器接入的端口上那就是网关ARP冲突如果网关IP正常、MAC也正常再tracert外网地址看从第几跳开始丢包。第一跳能到核心交换机网关说明二层三层转发正常问题在更上层的NAT或路由策略。这套组合拳基本可以在五分钟内区分出故障源头。6. 恢复与加固从救急到治本的完整操作6.1 五分钟内恢复全网通信的应急操作任何理论分析都替代不了现场止血。遇到全网断网时最高优先级是恢复业务而不是追求优雅的排障过程。通用操作顺序把新接入路由器的所有连接从核心交换机上断开让网络回到本次变更前的状态观察核心交换机CPU是否回落、端口指示灯是否恢复正常频率抽查几台终端确认恢复上网确认恢复后再回到配置台分析根因并做加固。在这个阶段不要重启核心交换机。重启意味着把所有设备、所有MAC地址表、所有ARP缓存全部清空等于把整个网络推倒重来。如果根因没找出来重启之后故障照样会复发而且影响范围会更大。6.2 正确接入新路由器WAN口、LAN口与管理路径的规划恢复之后要解决的是未来怎么接才对。如果新路由器是作为新的出口网关使用接线原则很简单WAN口接上游出口LAN口只接内网需要使用的设备或独立接入交换机不要把LAN口和核心交换机的端口同时连成一个环。如果必须让路由器LAN口和核心交换机相连用于管理就要保证核心交换机侧已经开启STP且该端口配置为边缘端口加BPDU保护。如果新路由器只是作为旁路设备测试或者管理跳板更稳妥的接入方式如下先把路由器单独接一台电脑登录管理页面把LAN口地址修改为与现有内网不冲突的网段比如现有网络是192.168.1.0/24就把路由器的LAN改成192.168.88.1/24关闭路由器自带的DHCP服务或者把DHCP池设置成独立网段只把LAN口接到核心交换机WAN口不接任何与核心交换机存在回路的线路在核心交换机侧为该端口配置正确的access VLAN、边缘端口和BPDU保护。6.3 开启RSTP与BPDU保护让网络自己防环只拔掉一根线修复故障不加固STP配置等于埋雷。下次再有任何人误接一条线全网照样瘫痪。正常的加固方案如下。华为设备上全局开启快速生成树并给接入端口配置边缘端口和BPDU保护system-view stp mode rstp stp bpdu-protection interface GigabitEthernet0/0/1 port link-type access port default vlan 10 stp edged-port enable思科/锐捷体系对应的配置逻辑是spanning-tree mode rapid-pvst interface GigabitEthernet0/1 spanning-tree portfast spanning-tree bpduguard enable有条件的话还可以开启交换机的环路检测功能。华为设备上使用loopback-detection检测到环路后会按策略自动关闭对应端口避免风暴扩散。配置完成后用display stp brief确认关键端口状态再把之前拔掉的线接回去观察端口是否被正确阻断。这一轮做完才算真正把故障关闭。7. 这次事故沉淀下来的排查习惯7.1 接入新设备前的三项例行检查跑过一次全网断网之后我给自己列了一个接入新设备前的检查清单后面基本没有再踩过同样的大坑拓扑核对把新设备所有网口画进现有拓扑图一旦发现任何闭环可能先想好阻断方式协议冲突检查新设备的默认IP、DHCP池、网关地址是否和现有网络重叠配置隔离新设备在配置完成前先用独立管理网段接入确认无误后再并入生产路径。这三项检查加起来不会超过五分钟却能把80%的延迟性断网扼杀在接入之前。7.2 网络变更后的观察期与回滚预案网络变更之后一定要留出至少10到15分钟的观察期再离开现场。这个故障里前几分钟一切正常极具迷惑性——如果接到网线后马上走人十分钟后就会在全楼听到断网了的喊声。同时每次变更前记录原来的接线方式和核心交换机的配置状态。变更出现异常时回滚动作应该早就想好拔掉哪根线、改回哪个IP、关掉哪个DHCP服务这些操作要做到不需要现场思考。手里的故障应急文档越短越好让一个刚值班的同事照着做也能恢复网络。7.3 一个值得记住的判断口诀把这次经验压缩成一句话新接入设备后网络延迟性瘫痪首要怀疑三件事——环路、ARP网关冲突、DHCP冲突排查优先级按这个顺序来。环路看端口计数和CPU网关冲突看ARP表DHCP冲突看租约参数。顺序对了恢复时间能压缩一半以上。我自己经历这种事故次数不算少最近再遇到类似报障已经能在五分钟内把范围缩小到具体端口。说句实在话网络故障并不可怕可怕的是在错误方向上反复重启设备、反复拔线把一次本可以五分钟解决的问题拖成一个小时的抢修战。希望这篇实操复盘能帮你少走几条弯路。