新手网络工程师第九课什么是环路以及我如何用半小时定位一处广播风暴做网络运维的人十有八九都被“环路”坑过。我刚入行那年一次下午三点半整个办公区突然卡死打印机吐纸像机关枪一样停不下来交换机所有端口指示灯疯狂闪烁连核心设备的CPU都飙到了90%以上。师父看了一眼说“环路。”我当时心里想的是啥是环路电路哪里短路了吗后来才明白这里的环路跟电路短路完全是两码事但破坏力一点不比短路小。这篇内容就是给刚入门或者准备入行的网络工程师准备的核心只讲清楚一件事什么是环路。我会从二层交换机的底层转发逻辑讲起用实际工作里最常遇到的广播风暴场景拆解环路的形成原理再分享我在生产环境里排查环路时用过的方法、踩过的坑以及STP生成树协议为什么能救你一命。看完之后你再遇到网络突然卡死、交换机CPU爆表的状况至少知道应该先往哪个方向怀疑。1. 环路的本质数据帧在交换机之间“跑圈”1.1 交换机最基础的工作逻辑要理解环路先得明白交换机在局域网里是怎么干活的。很多教材上来就讲MAC地址表、泛洪、ARP但实际工作的时候你只需要抓住交换机最核心的两条转发规则就行已知单播帧查MAC地址表有匹配条目就从对应端口转发出去没有匹配条目就往所有端口“广播式”转发。广播帧和组播帧除了接收端口本身交换机把帧复制到所有其他端口谁需要谁自己拿去。这里最关键的一句话是交换机不会主动丢弃它不认识的数据帧。它跟路由器不一样交换机天生就是“尽力转发”的只要帧进来了不管认不认识源MAC地址它都会做出处理。正常情况下这没什么问题一个办公室几十台设备交换机偶尔泛洪一下带宽绰绰有余。但问题在于如果你的网络拓扑是一个“环”——交换机A的1口连着交换机B的1口B的2口又连着A的2口物理上形成了一个闭合回路——那广播帧就会在这个环里无限循环。1.2 环路是怎么形成的一个逐步演进的例子我给你搭一个最经典的场景。两台接入交换机SW1和SW2中间用两根网线分别连接了两个端口形成一个物理环路。这时有台电脑PC1发了一个ARP广播帧想找网关的MAC地址。第一步SW1从1口收到这个广播帧按照泛洪规则除了1口之外的所有端口都会把这个帧发出去。SW2从1口收到了一份同时也从2口收到了另一份因为SW1的两个端口都把帧发出了SW2相当于在1口和2口同时收到了同一个广播帧。第二步SW2把从1口收到的帧从2口转发出去因为它是广播帧而且2口不是接收端口嘛。于是这份帧又从SW2的2口回到了SW1的2口。SW1收到之后好家伙这MAC地址我还是不认识继续泛洪。第三步从SW1的1口发出去又到了SW2的1口……如此反复永不停止。每一秒钟这个广播帧都被两台交换机各复制几十万次端口带宽被刷满正常业务数据根本插不进去。这就是“广播风暴”。你不用想着它是慢速的还是渐进的环路形成的风暴是瞬间的几秒钟之内就能让整个二层网络瘫痪。注意很多人觉得环路只有在“人为用两根线接两台交换机”时才可能出现但实际生产环境里更常见的是误接——比如桌面下面有两根网线一根是接电脑的一根是墙上的信息点本来各走各的结果有人想省事直接把他们插到同一个小交换机上环路就出来了。所以排查环路的时候物理链路异常永远要排在第一位。2. 环路带来的连锁灾难不只是“卡”而已2.1 广播风暴对设备性能的冲击环路最直观的后果是广播帧疯狂循环但它的破坏不止是网络卡顿那么简单。我用实际监控数据给你看正常的办公网环境核心交换机每秒处理的广播包可能在几百到几千个CPU占用率低于10%。当环路形成之后广播帧数量会暴涨到每秒几十万甚至上百万个。交换机的CPU要处理这些帧的转发决定即使ASIC芯片大部分转发是硬件完成的上送CPU的协议帧和控制帧也会成倍增加。表现就是设备CPU占用持续100%、管理响应超时、远程登录都进不去。这时候你想在交换机上敲命令排查问题会发现设备慢得像一台十几年前的旧电脑敲一个命令要等半分钟才回显。这是环路场景最典型的一种体验很多新手当场就懵了我网络都登不进去了还排查个什么2.2 MAC地址表漂移比广播风暴更隐蔽的陷阱广播风暴是环路的大动作但环路还有一个更隐蔽的伴生问题MAC地址表漂移。因为同一个帧会从多个端口同时到达交换机交换机对于同一个源MAC地址一会儿在1口学到一会儿又在2口学到于是MAC地址表就不断被刷新。MAC地址表漂移的后果是即使广播风暴没有那么严重业务依然会断断续续。因为交换机的转发表总在变原本应该从A口出去的帧可能因为刚刚学到的表项被错误地从B口转发出去对端根本收不到。表现出来就是网络时好时坏ping一下通一下不通业务隔几分钟就掉一次线。我当时遇到过最诡异的情况整个办公区有一台打印机一会儿能打一会儿不能打查看交换机端口流量并不高CPU也还好。排查了很久最后发现是会议室角落里一个小交换机被误接成了环路广播流量还没大到把核心打瘫但MAC漂移已经把打印机的流量搞得乱七八糟了。2.3 环路对业务的影响范围环路影响的不是一台设备而是整个广播域。在同一个VLAN内所有设备都会受到波及。大型网络里如果没做VLAN隔离一个楼层的小环路可能波及整栋楼的网络。这也是为什么我一直建议接入层设备一定要划分VLAN即便不为了安全也要为了限制故障域。环路救不救得回来是一回事先把爆炸范围控制住运维的命才能保住。3. 环路的“克星”STP生成树是怎么解决闭环的3.1 STP的核心思路逻辑上破环既然物理环路会产生风暴那是不是把所有环路都拔掉就完事了呢日常工作里网络工程师确实经常设计冗余链路来保证可靠性——一台交换机挂了另一条链路还能顶上。但冗余链路物理上就是环路怎么在保留冗余能力的同时避免广播风暴答案就是STPSpanning Tree Protocol生成树协议。STP的思路非常朴素物理上你可以有环逻辑上我只允许你是一棵树。交换机之间通过交换BPDUBridge Protocol Data Unit协议报文选出一个根桥然后计算出一条到根桥的最短无环路径把其他冗余端口阻塞掉。一旦活动链路失效阻塞端口自动转变为转发状态网络迅速恢复。我把STP的工作流程整理成一张表方便你直观理解阶段关键动作作用根桥选举交换机之间比较桥ID最小者成为根桥确立拓扑权威根端口选择每台非根桥交换机选出到根桥开销最小的端口确定上游方向指定端口选择每条链路上选出一个指定端口负责转发消除传输歧义阻塞冗余端口其他非指定、非根端口进入阻塞状态逻辑上切断环路端口状态变化是STP里最需要掌握的部分阻塞Blocking→ 监听Listening→ 学习Learning→ 转发Forwarding。整个过程默认需要30秒左右这也就是为什么交换机刚启动时网络要等几十秒才能通。3.2 生产环境不要用STP默认配置入门阶段你只要理解STP的原理就够了但实际生产网络里如果还按最老的传统STP来用会被同行笑掉大牙。原因很简单传统STP收敛太慢30秒的收敛时间在现代业务面前是致命的。所以现在企业网里普遍用的是RSTP快速生成树协议或MSTP多生成树协议。RSTP把收敛时间从30秒压缩到1秒左右靠的是端口角色、链路类型和对齐机制的优化。适用于大多数中小型网络。MSTP把多个VLAN映射到不同的生成树实例可以实现不同VLAN流量的负载均衡适合大规模园区网和需要链路利用率的环境。我自己的习惯是不管网络多小只要交换机支持一律启用RSTP或MSTP跟踪模式全部打开。代价仅仅是多几行配置换来的却是环路自动阻断能力。# 华为交换机开启MSTP并启用快速生成树模式的参考配置 [Huawei] stp mode mstp [Huawei] stp enable [Huawei] stp pathcost-standard doted1t [Huawei] interface GigabitEthernet0/0/1 [Huawei-GigabitEthernet0/0/1] stp edged-port enable [Huawei-GigabitEthernet0/0/1] stp bpdu-filter enable# 思科交换机开启RSTPPVST场景的参考配置 Switch(config)# spanning-tree mode rapid-pvst Switch(config)# interface GigabitEthernet0/1 Switch(config-if)# spanning-tree portfast Switch(config-if)# spanning-tree bpduguard enable这段配置里有一个很关键的参数端口开启edge-port华为或者portfast思科意思是告诉交换机“这个端口下面接的是终端设备不是交换机不会产生环路”。这样端口可以跳过STP的监听和学习阶段直接进入转发状态电脑插上去秒通网。但这么做有个前提这个端口绝对不可能再去接交换机否则一旦误接成环路STP不会帮忙拦截风暴照样发生。所以edge-port要配合BPDU保护一起用一旦端口收到BPDU就直接进入err-disable状态相当于物理切断了这条链路防止环路扩大。3.3 关掉STP的人有多勇我一直觉得把STP关了是对网络安全性最没有敬畏心的操作之一。有些人觉得我的网络拓扑很清晰不可能有环路开着STP反而增加启动时间干脆关掉。这个想法我见过太多回了。但真实情况是网络拓扑是活的今天加了一个工位明天拉了一条临时链路后天某个同事把两台交换机串在了一起你永远不知道意外什么时候到。我在前一家公司就遇到过某业务网络的管理员为了省事把核心交换机上的STP全局关掉了。结果两个月之后有个外包施工队误把两个弱电井的跳线接成了环路整个业务中心断网半小时。等我们到达现场设备已经死到无法远程操作只能拔线重启。那半小时的损失远超当初省下的那一点配置工作量。4. 生产环境里我通常怎么快速定位环路4.1 先看现象环路故障的三个特征环路故障虽然可怕但它有非常典型的现象。你在现场待久了光看现象就能猜个八九不离十网络大面积卡顿或完全瘫痪ping网关大量丢包内网延迟从1ms飙到几千ms。交换机端口指示灯狂闪尤其是有环路的两个端口速率接近接口协商的最大值。核心交换机CPU占用率异常升高远程管理缓慢或超时。这里有个陷阱带宽被流量占满未必就是环路。比如你在局域网里大规模拷贝文件、服务器做数据备份、视频监控流量异常拥塞端口也可能跑到接近100%但CPU未必高。环路风暴最明显的特征是广播帧占比异常高而且CPU会一起飙升。我一般用三步做初步判断第一步看端口流量哪个端口收发都接近满速率 第二步看报文统计广播帧是否占到了端口流量的绝大部分 第三步看CPU是不是已经高到影响设备管理了。三者同时满足基本上就可以确认是环路。4.2 用命令行和日志进一步确认确定方向之后你要在设备上做进一步确认。如果交换机还能操作我通常按这个顺序敲命令# 查看CPU占用率确认是否存在控制面压力以华为设备为例 SW display cpu-usage # 查看端口流量与广播报文统计 SW display interface GigabitEthernet0/0/1 # 查看MAC地址表漂移记录 SW display mac-address flapping # 查看设备日志中是否有MAC漂移或环路告警 SW display logbuffer | include LOOP|FLAPPING|MAC-MOVE这几条命令里我认为最实用的其实是display mac-address flapping它直接告诉你哪台设备的MAC在哪个端口之间反复漂移基本等于把环路点指给你看了。不过这个命令在中低端交换机上可能不支持那就只能靠流量和端口状态来交叉判断。如果你用的是思科设备登录上去之后直接show processes cpu sorted看CPUshow interfaces | include Ethernet|Is protocol|5 minute大屏扫一遍流量再show spanning-tree inconsistentports看看有没有处于异常状态的端口也比较高效。到这一步如果设备已经完全卡死远程操作不进去了那就只能用最原始的办法物理拔线。按楼层或者接入交换机的范围一层一层拔每拔掉一根线观察一下网络是否好转。这个方法非常“土”但在设备已经无法管理的时候是唯一的选择。我建议你在平时就规划好线路标识否则现场拔线时谁能分清哪根线接哪边。4.3 一台一台接入交换机地“二分”排查拔线也是有技巧的不能一根一根瞎拔否则大网络可能拔到下班。我的做法是“二分法”先观察核心交换机下挂了多少台接入交换机。拔掉一半接入交换机的上联链路。观察网络是否恢复如果恢复说明环路在被拔掉的这一半里如果没有恢复说明在另一半里。循环执行把故障范围缩小到一个接入交换机。然后断开这台接入交换机的所有下行端口再一个一个恢复直到恢复之后故障重现就找到了肇事端口。这个方法听起来笨但在生产事故中非常高效。我处理的环路故障里绝大多数在三次四步之内就能定位耗时基本在半小时以内。5. 除了STP这些手段能帮你提前防“环”5.1 环路检测协议小设备也能自动防环不是所有交换机都开了STP的尤其是一些低端的傻瓜交换机、家用交换机它们根本不支持STP。这个时候如果要保护整个网络你就得靠网络边缘设备的环路检测功能。像华为的loopback-detection就是专门用来检测这种场景的。它会在开启了特性且处于access模式的端口上周期性地发送环路检测报文如果收到自己发出去的报文就说明下游成环了交换机根据配置自动将端口关闭或告警。# 华为交换机全局和接口启用环路检测并设置检测到环路后的动作为关闭端口 SW system-view [SW] loopback-detect enable [SW] loopback-detect detection-interval 10 [SW] interface GigabitEthernet0/0/1 [SW-GigabitEthernet0/0/1] loopback-detect enable [SW-GigabitEthernet0/0/1] loopback-detect action shutdown思科这边也有一些私有机制比如errdisable recovery配合bpduguard当端口收到异常BPDU时直接把它禁用然后设定时间自动恢复。这些功能的核心思路是一致的让端口对环路有“免疫力”而不是等人发现之后再去救。我强烈建议你在所有接入端口上都开这种保护别想着依靠人的反应速度人的反应速度在环路面前不值一提。提示端口loopback-detect只对access端口生效trunk端口往往要依赖STP来防环。所以在设计VLAN和端口类型的时候就要提前考虑好防环策略别等出事才来翻配置。5.2 VLAN隔离把灾难限制在小范围内前面提到环路的影响范围是整个广播域VLAN就是切割广播域的手段。如果你把一个楼层划分成两三个VLAN即使某个VLAN里出现环路影响也仅限于该VLAN内的设备其他VLAN的业务照常。我见过很多中小企业全公司就一个VLAN所有电脑都在同一个大的广播域里。这种网络结构对环路几乎没有任何抵抗力一个小型环路的覆盖范围就是全公司。每次想到这种结构我都替他们捏把汗因为环路不一定天天出现可一旦出现就是重大事故而VLAN分割是最不需要花钱的防御手段。你要是管着这种网络第一步就应该规划VLAN。接口放通VLAN也有讲究原则是能不放通的就不放通能配access的别配trunk。要知道trunk口天然可以承载多个VLAN一旦这个口误接了其他交换机或终端环路和穿越问题都可能出现端口配置上多做一点限制后面会省很多事。5.3 日常巡检主动发现比被动救火更靠谱最后分享一个我自己的习惯每周抽十分钟看一眼核心设备的告警日志和端口状态。环路不是每次都直接让网络全瘫的有些微弱环路可能只是端口流量偏高、偶尔丢几个包不仔细看根本发现不了。如果能在日志里抓到MAC漂移的早期记录趁它还只有轻微影响时处理掉比等广播风暴全面爆发再救火要舒服得多。可以用脚本定时抓display mac-address flapping的记录输出到日志服务器有问题早发现早处理。6. 路由环路三层世界的“无限循环”6.1 数据包为什么也会迷路二层环路讲完了顺带提一句路由环路。很多人学CCNA或HCIA的时候都会碰到“路由环路”这个考点。它与二层环路本质类似都是一种数据“跑圈”的状态但机制完全不同。路由环路发生在三层网络里一般是因为路由表条目互相指向对方数据包在网络设备之间反复转发永远出不去。比如路由器R1有一条默认路由指给R2R2有一条默认路由指给R1两个路由器的出接口在各自去往目的地的路径上形成一个来回的环路数据包就会在这两台路由器之间循环转发直到TTL字段被减为0才被丢弃。6.2 TTL防止数据包无限循环的最后一道防线数据包在IP报文头部有个TTLTime To Live字段每经过一台路由器就减1减到0就被丢弃同时路由器会返回一个ICMP超时消息。这个机制本身就是专门防三层环路的它保证了一个数据包最多经过255台路由器。所以你ping外网的时候如果显示“TTL expired in transit”往往就意味着路径上出现了路由环路或者某些设备在故意丢弃数据包。不过TTL只是止损机制它阻止的是数据包无限占用带宽但环路上的流量无论到不到达目的地已经被转发了无数次浪费出来的带宽依然不少。所以路由环路还是要靠正确的路由协议和合理的路由汇总策略来规避比如OSPF区域设计、BGP的环路防护机制等等。7. 一次真实的环路故障排查记录文章写到这儿光谈原理可能不够解渴我分享一个前阵子实际处理的案例。某客户的一个分支机构反映整个办公室网速变慢视频会议频繁卡顿。我远程登录核心交换机先看了CPU和端口流量情况。CPU占用40%左右不算太高但一个网段的广播流量明显异常。我让客户帮忙看了一下机房发现弱电机柜里环境比较乱里面堆了好几台小交换机网线横七竖八地插着。我判断大概率是某台小交换机下面被接出了环。在核心交换机上我查看了MAC地址表漂移记录很快就发现一台打印机的MAC地址频繁在G0/0/12和G0/0/20之间跳变。顺着这两个端口去查物理链路最终确认是办公区有一个工位下方的小交换机有一根墙上的网线和一根电脑的原网线被一根跳线“帮忙”连到了一起形成了环路。处理过程就很简单我去到现场拔掉那根跳线整个办公室的网络马上恢复了。前后大约四十分钟其中二十分钟花在了路上。事后我在那台小交换机旁边贴了一个醒目的标签“本设备禁止接入多余线路”又在核心交换机上把那两个端口的环路检测和STP edge端口保护都打开。之后再没有出现过类似问题。这个案例让我最深的感触是环路故障往往不是你网络的物理拓扑设计有问题而是日常运维中的人为疏忽。你没办法保证每个员工、每个施工队都能理解环路和白名单所以自动化防护机制必须前置。8. 写在最后的个人体会做了这么多年网络运维我最大的感触是环路是网络工程师最容易遇到、也最容易忽略的基础故障。它的原理并不复杂无非是交换机不知道如何去重导致帧在网络里无限循环。但它的破坏力极强可以让你几秒钟之内失去整个网络的掌控权。理解环路、预防环路、快速定位环路是网络工程师必须练好的基本功。我建议每一个刚入行的朋友都找两台支持STP的交换机自己动手搭一个小环路环境把STP的各个状态变化看一遍再把STP关掉体验一把广播风暴比任何书本知识都管用。手上有了这种“肌肉记忆”真到了生产环境里遇到问题你心里才不会慌。另外再分享一个我在实际使用中发现的细节环路的产生很多时候是“瞬时事件”线上环境在拔线之后交换机的端口统计和日志就已经被刷新了所以事后追查往往得不到关键证据。这时候也别着急直接到现场按物理链路一段一段排查反而是最可靠的途径。网络排障这件事经验的价值往往不在于知道多么高深的理论而在于知道在什么情况下用什么最朴素的办法解决问题。