做网工这行谁还没被广播风暴折腾过几回半夜机房值班一个环路能把整栋楼业务全部打断交换机CPU顶到99%所有的灯狂闪人还没走到机柜跟前就已经猜到大概了——又是二层环路。我之前在好多个维护项目里都碰到过类似场面。上联口插错、堆叠线当成了业务线、某台傻瓜交换机被直接搭成了三角环最后都是同一个收场广播包在交换机之间无限循环一台交换机给另外一台疯狂转包交换机CPU过载业务全挂。真正解决问题的方法往往就落在STP这几个字母上。STP全称Spanning Tree Protocol生成树协议它做的事情简单说就是在保留冗余链路的同时用逻辑算法把环变成树防止广播风暴和MAC地址表抖动保障二层网络稳定运行。这篇就认真聊聊STP的原理与配置。我尽量用大白话把生成树从底层机制讲到实际操作从BPDU报文到根桥选举从端口状态机到配置命令最后再列几个我踩过的坑。不管你是刚入行的网络小白还是已经在做维护的运维工程师看完这篇都应该能自己判断怎么设计冗余链路、怎么配置生成树、怎么在故障现场快速止血。1. STP到底在解决什么问题二层环路与广播风暴1.1 冗余设计为什么要故意制造物理环路正经的网络设计里链路冗余是必须有的。一个办公楼的核心交换机宕机了如果下面所有接入交换机都只靠一根线连着它那核心一挂全网直接瘫痪。所以实际拓扑里经常出现“三角形”甚至“网状”结构交换机的上联口接两个核心接入层交换机之间还有互联线。物理上这种环路是故意留出来的。目的是当某条主链路down掉流量能自动切到备份链路上让业务继续跑。但物理环路一旦存在二层广播帧的问题就来了。二层数据帧和三层IP报文不一样IP报文有TTL字段每经过一台路由器减1减到0就丢弃。但二层帧没有TTL这个概念交换机收到广播帧之后按照转发逻辑会把它从除接收端口以外的所有端口复制出去。如果拓扑里存在环路这个广播帧就会被每台交换机反复复制、转发沿着环无限循环下去。一个广播包可以瞬间变成几百个、几百万个最终占满所有链路带宽。这种被称为“广播风暴”的现象是二层网络中破坏力最大的故障之一。所以纯粹从可靠性角度我们想要环路纯粹从数据转发角度环路必须禁止。STP的想法就是在所有交换机之间运行一套算法识别出哪些端口是冗余的然后把冗余端口在逻辑上阻塞掉使全网变成一个没有环路的树形拓扑。同时当主链路发生故障它又能自动把原来阻塞的端口打开快速恢复通信。通俗讲就是“平时堵死备用口关键时刻再放行”。1.2 环路真正可怕的地方广播风暴、MAC漂移和交换机CPU过载环路带来的问题远不止广播风暴一种。我把实际故障时常见的三种“并发症”列一下第一种广播风暴。广播帧在环路中无限复制链路带宽被占满正常业务报文完全发不出去这个开头已经说了。第二种MAC地址表抖动。交换机是依据目的MAC查MAC地址表来决定把数据帧从哪个端口发出去的。MAC地址表记录了某个MAC地址应该从哪个端口到达。在环路上同一个源MAC的帧会从多个端口先后到达交换机。交换机搞不清楚这个设备到底接在哪个口MAC表就开始左右横跳一会儿把MAC记录写到端口1一会儿改写到端口2转发效率急速下降CPU也被大量消耗在刷MAC表和报文处理上。第三种交换机CPU和转发引擎过载。局域网交换机以硬件转发为主但控制层面的CPU还是要处理很多控制报文、ARP、协议报文。广播风暴场景下所有报文都在泛洪CPU被按在地上摩擦控制协议都跑不动了。我见过最严重的一次某接入交换机CPU直接超过90%远程登录都发卡连配置都敲不进去。这种时候唯一的办法就是物理断线。在STP正常工作的网络里这些问题是不会发生的。因为冗余链路被逻辑阻塞转发路径是唯一的广播帧转发一次之后不会再回到源交换机。1.3 一次深夜排障案例最后一查根因是没开STP讲一个我处理过的真实事故。某单位的一栋办公楼半夜有人加班时网络突然全断值班电话被打爆。我赶到机房看到那台汇聚交换机所有端口指示灯都在狂闪用串口线连上去CPU利用率95%以上。当时第一反应就是有环路。我port shutdown掉一个方向疑似环路的端口网络立刻恢复再port up几秒后又堵死。最后排查发现是楼里一个办公室私自接了一台小型交换机把两根网线同时插在了两台接入交换机上形成了一个物理环路。而那台接入交换机是某低端型号出厂默认没有开启STP环路产生了交换机之间完全不自知广播风暴直接在二层炸开。这个案例看起来简单但很能说明问题STP默认开启与否不同设备、不同版本之间并不一致。有的默认开有的默认关还有的虽然默认开但模式选的是旧版STP收敛特别慢。所以拿到一台交换机的第一件事就是确认生成树状态而不是想当然。2. STP怎么做到“堵路不堵车”BPDU、根桥选举与端口角色2.1 BPDU交换机之间互发的“选举信件”STP要工作交换机之间必须互相打招呼互通信息。这个“打招呼”的报文叫BPDUBridge Protocol Data Unit桥协议数据单元。BPDU是STP的“原料”所有选举和判断都依赖它。BPDU里携带的核心字段包括根桥ID由桥优先级和桥MAC地址组成标识谁是当前的根桥。根路径开销发送者到达根桥的路径总开销。发送者桥ID发出这份BPDU的交换机自己的身份。发送者端口ID发送BPDU的端口编号。一系列计时器值Hello Time、Max Age、Forward Delay。默认情况下交换机每个Hello Time发送一次BPDUHello Time一般是2秒。也就是说每台交换机每隔2秒就会向自己的所有端口发送一份BPDU同时不断接收邻居发来的BPDU。可以想象成大家都在广播自己的“家底”然后根据这些信息决定谁是老大、谁走哪条路。我刚接触STP时有个误区以为BPDU只在根桥上发送。实际上所有参与生成树的交换机都会发BPDU因为信息需要互相传递和比较而不是只有根桥发声。2.2 根桥选举机制详解STP算法做决策先要选出一个“精神支柱”就是根桥也叫Root Bridge。全网只有一个根桥其他设备都是非根桥。根桥的工作是维持全网生成树拓扑的稳定所有路径计算都以到达根桥的最短路径为目标。根桥怎么选比的是桥ID桥ID 桥优先级 桥MAC地址。桥优先级默认都是32768可以配置修改范围是0到61440而且必须是以4096为倍数递增。比较规则很简单先比较优先级。数值越小优先级越高越有可能成为根桥。优先级相同的比较MAC地址。MAC地址越小越有可能成为根桥。选举过程大致是这样的每台交换机启动时都认为自己是根桥通过BPDU把自己的桥ID告诉邻居。邻居收到这份BPDU后拿对方的根桥ID和自己记录里的根桥ID比较。如果对方的ID更优就放弃自己的“候选资格”转而把对方当成根桥再把这套信息继续转发给其他邻居。这个过程持续迭代直到全网所有交换机记录到的根桥ID一致根桥选举就完成了。实际配置时我们要主动控制根桥的位置。把核心交换机或汇聚交换机设为根桥是一种标准做法比如在核心交换机上把优先级改成4096让它的桥ID在整个网络里最小。这样生成树的计算结果就会围绕核心设备展开转发路径更合理。如果你不手动调整优先级那根桥可能落在某台低端接入交换机上整网路径乱七八糟网络性能也受影响。2.3 根端口、指定端口与阻塞端口各司其职选完根桥接下来要做的事情就是给每个端口分配角色。STP里有三种基本端口角色根端口Root PortRP。对于每一台非根桥交换机需要选出一个到达根桥路径开销最小的端口作为根端口。根端口负责这台交换机与根桥之间的数据转发是跟“老大”通信的唯一关口。一台非根桥上且仅有一个根端口。指定端口Designated PortDP。每一条链路上都要选出到达根桥路径更优的那个端口作为指定端口。简单理解指定端口就是这条链路的“主人”它负责把数据从这一侧发向另一侧。通常根桥上的端口都是指定端口。非根桥上也可以有指定端口取决于它和邻居交换机比较时谁更优。阻塞端口Blocked Port。既不是根端口也不是指定端口的端口逻辑上被阻塞不转发业务数据帧。但这个端口并没有完全“死掉”它仍然持续接收BPDU用来感知网络拓扑变化。一旦当前活跃路径失效阻塞端口可以快速切换到转发状态。这三种角色合在一起保证了全网任意两台主机之间只有一条活动转发路径没有环路但所有冗余端口都“枕戈待旦”随时准备顶上。2.4 路径开销如何影响转发路径端口角色和路径选择都离不开路径开销这个概念。STP为每条链路定义一个开销值带宽越大开销越小路径越优。一个端口对应的根路径开销等于从该端口出发到达根桥经过的所有链路开销之和。我罗列一个常见的默认开销对照表链路带宽802.1D标准开销扩展标准开销10 Mbps1002000000100 Mbps192000001 Gbps42000010 Gbps22000不同的设备厂商和标准版本开销值的具体算法会有一点差异。老的802.1D标准以10Mbps链路开销为100作为基准推算后来为了支持更大带宽又出来了扩展开销算法。不同标准算出来的开销值可能差很多但我们选路时看的是“相对大小”而不是绝对值。手动调整链路开销也是一个常用的排障手段。比如某条千兆链路的默认开销是4另一条千兆链路过载太厉害了想让它别优先走可以把它的端口开销调大一些比如调成20STP计算路径时自然会偏向别的链路。这招在调整业务流量路径时很管用。3. STP收敛过程与时间开销从链路故障到业务恢复3.1 端口状态机的完整切换过程STP里的端口不是生下来就直接转发数据的。它要经历一个状态机从禁用、阻塞、监听、学习最后才进入转发。我把这几个状态分别解释一下禁用状态Disabled端口被手工关闭或者因为管理原因不参与生成树计算既不转发数据也不处理BPDU。阻塞状态Blocking端口在逻辑上被阻塞不转发数据帧只接收BPDU被动等待拓扑信息。刚启动的交换机端口或因为成环被选为冗余的端口通常都停在这个状态。监听状态Listening端口准备参与转发但还在接收和发送BPDU学习网络拓扑这时候不会学习MAC地址也不会转发数据帧。学习状态Learning端口已经开始学习MAC地址建立MAC地址表但仍然不转发数据帧。这一步主要是为了让交换机先“认识”网络里的设备避免转发开始后出现大量未知单播泛洪。转发状态Forwarding端口正常工作既转发数据帧也学习MAC地址继续处理BPDU。状态机变化的顺序是固定的阻塞 - 监听 - 学习 - 转发。从阻塞到转发通常需要经历两个转发延迟周期也就是2倍的Forward Delay每个转发延迟默认15秒。所以正常情况下一个端口从启动到开始转发数据差不多要30秒。这是旧版STP设计上最被人诟病的地方。3.2 30秒还是50秒收敛时间到底怎么算的“STP收敛要50秒”这个说法在网络圈里流传很广但它其实描述的是链路故障发生后STP重新计算出新路径所需要的最坏情况时间。我来拆一下这个50秒是怎么来的。设想一个双链路冗余场景主链路突然断了流量要切到备份链路上。但备份链路本来处于阻塞状态。阻塞端口的BPDU是持续接收的。主链路故障后根桥的BPDU无法从这个端口到达阻塞端口要等待一段时间确定根桥彻底“失联”这段时间就是Max Age默认20秒。Max Age时间里如果没有任何BPDU进来端口判断根桥不可达于是进入监听状态监听15秒然后进入学习状态再花15秒最后才进入转发状态。20 15 15 50秒。这就是STP默认收敛时长的由来。50秒对于普通网页浏览来说可能还能忍一忍但对业务系统、语音、视频监控这些对连续性要求高的场景来说已经是灾难级别的中断了。很多人在机房做链路切换测试业务系统直接挂了查了半天才发现问题不在于业务软件而是STP收敛太慢。所以在实际生产环境中我们一般不会老老实实让旧版STP跑50秒收敛而是直接启用RSTP或MSTP。这两个扩展协议我下面详细说。3.3 RSTP和MSTP为什么能大幅缩短收敛时间RSTP全称Rapid Spanning Tree Protocol快速生成树协议是对STP的重大改进。它把端口状态精简为三种丢弃、学习、转发并且增加了几种灵活机制来加速收敛。RSTP最关键的一个改进是引入了Proposal/Agreement协商机制。链路建立后交换机之间可以快速握手确认彼此的端口角色指定端口在很短的时间内就能直接进入转发状态不需要经过漫长的监听和学习阶段。在大多数点到点链路上RSTP的收敛时间可以控制在1秒以内链路故障恢复基本做到业务无感。RSTP还引入了边缘端口的概念。连接PC、打印机、服务器这些终端设备的端口可以设置成边缘端口。边缘端口只要UP就立刻进入转发状态压根不参与生成树计算因为终端后面一般不会再有交换机和环路。MSTP全称Multiple Spanning Tree Protocol多实例生成树协议是在RSTP基础上配合VLAN做多实例计算的协议。它允许管理员把不同的VLAN划分到不同实例每个实例独立计算生成树。举例来说VLAN 10、20走实例1VLAN 30、40走实例2。实例1阻塞掉了链路B实例2可以阻塞掉链路A两条冗余链路同时利用起来既保证无环又实现了负载均衡。这在数据中心核心汇聚场景中特别有用。现在新设备基本都支持RSTP、MSTP。我个人的建议是普通局域网环境优先用RSTP场景简单、收敛快多VLAN需要负载均衡的用MSTP除非有老设备兼容性要求否则尽量别再用旧版STP了。4. STP配置实操基本命令、参数调优与典型拓扑实例4.1 基础配置开启生成树与选择运行模式先做一件事确认交换机的生成树模式。不同厂商的设备默认行为差异很大有的默认启用STP有的默认只启用RSTP还有的低端设备出厂默认关闭生成树。拿到设备后先用查看命令检查一下当前状态。我常用的查看命令大概是这样show spanning-tree show spanning-tree summary show stp如果发现生成树没开首先全局开启。以下是通用的开启命令示例放在全局配置模式下执行spanning-tree enable接下来选择运行模式。如果你的设备支持RSTP直接切过去spanning-tree mode rstp如果网络里有多个VLAN希望做多实例负载均衡用MSTPspanning-tree mode mstp spanning-tree mst configuration instance 1 vlan 10-20 instance 2 vlan 30-40配置MSTP时注意同一套实例配置必须在这个VLAN域的所有交换机上保持一致否则实例不匹配生成树计算会出问题。我这里把命令写得比较概括各家设备可能会有细微差异但思路完全一样。4.2 调整STP核心参数的正确姿势配置根桥最直接的方式是修改桥优先级。下面这个配置让本机成为VLAN 1的根桥spanning-tree vlan 1 priority 4096或者通过root关键字让系统自动把优先级调整到最优值spanning-tree vlan 1 root primary非根桥设备如果不想抢根桥角色优先级就保持默认32768或者设置得更高一些比如49152明确告诉全网我不参与根桥选举。这一点在大型网络里尤其重要不然新加一台交换机上来可能因为MAC地址比较小就把根桥抢走了。针对端口调整链路开销和端口优先级也能影响路径选择。如果希望某条链路不被优先选用调大端口开销interface gigabitethernet 0/1 spanning-tree cost 10000连接终端的下行口推荐开启边缘端口和BPDU保护。边缘端口让端口立马上线BPDU保护防止有人在下联口接入交换机影响整网生成树。配置类似这样interface gigabitethernet 0/1 spanning-tree portfast spanning-tree bpduguard enable注意PortFast和BPDU保护只适合配置在连接终端设备的端口上。连接其他交换机的端口千万不能用PortFast否则交换机之间互连时如果出现环路STP起不到防护作用照样广播风暴。调整计时器需要谨慎。全局的Hello Time、Max Age、Forward Delay不建议轻易改动改小了可能导致网络由于BPDU延迟不稳改大了收敛更慢。非特殊情况优先通过改工作模式来缩短收敛时间别跟计时器较劲。4.3 实战配置三台交换机的冗余收敛拓扑来一个完整的例子。假设有两台接入交换机B和C同时上联汇聚交换机AB和C之间还有一条互联链路拓扑上构成了三角形环。如果不跑STP这个网络肯定炸。我们现在做一套标准配置。第一步把汇聚A设置成根桥spanning-tree mode rstp spanning-tree vlan 1 root primary汇聚A的优先级不手动改用root primary让系统自动调整到最低值。它的两个下联口保持默认Trunk或Access配置但不要加PortFast。第二步接入B和C的配置spanning-tree mode rstp spanning-tree vlan 1 priority 32768B和C保持默认优先级。B-C互联口只能做普通交换机互联口也别开PortFast。B和C下联终端的端口开启PortFast和BPDU保护interface gigabitethernet 0/10 spanning-tree portfast spanning-tree bpduguard enable配置完成后用show spanning-tree命令验证。正常情况应该是这样在A上与B和C相连的端口都是指定端口DP。在B上与A相连的端口是根端口RP。与C相连的端口如果被阻塞就进入阻塞状态。在C上与A相连的端口是根端口RP。与B相连的端口被阻塞。此时B和C之间那条互联链路是阻塞状态的但它随时待命。一旦B到A的链路断了阻塞端口会在RSTP快速收敛机制下几乎瞬间完成角色切换业务不受影响。这就是一个标准的“冗余但不环路”的二层网络。配置完之后我还习惯做一次验证手动把B的上联口shutdown过几秒再看业务是否自动恢复。实测RSTP模式下大部分场景恢复时间都能控制在几秒内。5. 常见问题与排查技巧实录5.1 交换机CPU飙升先怀疑广播风暴我在前面说过广播风暴是二层环路最典型的故障表现。如果你在现场发现交换机所有端口狂闪CPU使用率高到异常第一件事是确认是不是环路。排查顺序我建议这样用管理口连上去看CPU使用率同时看端口流量统计。执行show interface检查端口的广播/组播包计数是不是异常高。执行show mac address-table看看MAC地址是不是在各端口之间反复漂移。查看系统日志有没有持续的拓扑变化告警。一旦确认是环路最快的恢复动作是物理隔离拔线或者把嫌疑端口shutdown。不要在环路抖动状态下慢慢敲命令那只会浪费时间。拔掉线后网络恢复了再坐下来慢慢找环路源头。事后一定要检查STP是否正常开启。如果交换机支持RSTP优先改成RSTP模式。同时把所有下联口配上BPDU保护避免终端附近私接设备再次引发环路。5.2 端口角色乱跳、根桥频繁切换根桥频繁变化通常是因为网络里出现了两个优先级很相近的设备加上MAC地址比较接近导致选举结果不断翻转。根桥一旦变来变去整个网络的路径也会跟着变就会出现间歇性丢包。处理办法是手动固定根桥spanning-tree vlan 1 root primary同时在核心设备上的互联口配置根保护防止某个新接入的交换机抢占根桥角色interface gigabitethernet 0/1 spanning-tree guard root根保护开启后如果这个端口收到更优的BPDU交换机不会轻易改变根桥而是把该端口置为阻塞状态避免异常设备破坏拓扑。这个配置在存在多级接入、可能有人乱接设备的网络里非常实用。5.3 切换慢到业务超时问题出在计时器有时候你确认STP模式、优先级都配好了端口该阻塞的也阻塞了但链路切换还是慢业务仍然会中断几十秒。这种时候要往这几个方向查第一交换机的工作模式是不是还停在旧版STP。很多设备默认协议是STP不是RSTP如果没显式切换收敛时间就是最长的50秒业务当然受不了。第二有没有在应该用RSTP的交换机互联口上误开了PortFast。PortFast用在交换机互联口会让端口在环路存在时也直接进入转发态等于绕过了生成树防护隐患非常大。第三链路故障检测依赖物理层信号。如果链路断了但网线的电气信号没有立即变化比如某些光模块故障端口可能不会马上感知到链路down恢复时间会更长。这时候可以调整端口的光电检测参数或者用链路聚合做更快的故障切换。每一次拓扑变更交换机都会发出TCN BPDU。链路切换慢还有一个常见原因是MAC地址表刷新延迟。RSTP下拓扑变化会触发交换机快速清空自己的MAC地址表重新学习。如果发现切换后大量数据包泛洪可以检查是不是有设备对拓扑变更报文处理异常。5.4 一张速查表快速定位STP故障这里整理一个我用起来很顺手的排查速查表症状可能原因快速处理建议CPU飙升、端口狂闪二层环路、未开启STP先拔线或shutdown隔离再开启RSTP广播包计数持续上涨环路或下联设备私接开启生成树端口配置BPDU保护链路切换需要几十秒工作模式为旧STP切换为RSTP或启用MSTP多实例根桥不稳定优先级冲突、设备私接手工指定根桥配合root guardMAC地址表抖动环路、MAC欺骗查环路配置BPDU保护观察端口端口明明该转发却不通端口被STP阻塞show spanning-tree确认端口角色下联设备端口不起来端口被BPDU保护关闭恢复端口检查是否误配BPDU保护这张表不能覆盖所有情况但每一条都是我在实战中真真切切遇到过的。6. 最后聊几点实战心得做网络维护做久了STP这块反而越用越保守。我个人的习惯是能不用默认值的地方尽量不用默认值能用RSTP的地方绝不跑旧版STP。上架新交换机时我做的第一件事就是看生成树模式而不是等网络出问题再去查。因为默认值这东西在不同厂商、不同版本之间差别真的很大赌它没问题风险太高。还有一点是“边界防护”的意识。网络的边缘设备是最失控的办公室里的任何人都有可能接一个几十块钱的小交换机进来随手一根线插到墙上两个端口环路瞬间形成。所以在接入层交换机上把PortFast和BPDU保护全面铺开是我的标准配置不是可选配置。一旦有设备尝试非法接入生成树端口会被自动shutdown而不是让整网一起去死。最后提一个隐藏技巧在改造网络前先把所有设备配置做备份再在模拟工具里把拓扑搭出来跑一遍STP收敛。我吃过不少亏都是在演示环境里没验证就直接割接结果现场根桥选举乱成一锅粥。现在不管多简单的变更我都要先看一遍show spanning-tree的输出确认根桥、角色、阻塞端口全都符合预期才敢动业务链路。STP这套东西原理听着不难但真正让你长记性的一定是故障现场那几分钟的心跳加速。把这些配置和排查思路提前打扎实机房夜里的麻烦事就会少很多。