RSTP快速生成树协议详解：从环路故障到毫秒级收敛

1. 先想清楚一个问题RSTP到底在解决什么麻烦干网络这一行谁没经历过几次“全网突然卡死、交换机CPU飙到99%、所有灯像呼吸灯一样同步闪烁”的诡异故障最后翻半天机柜发现就是一根不起眼的跳线把交换机的两个端口插到了一起——形成了物理环路。如果交换机上没有生成树协议这个环会在几毫秒内让广播帧像滚雪球一样膨胀直到把整个广播域的带宽吃干净。这就是RSTP存在的根本理由也是每个网络工程师都必须吃透的第一课。1.1 环路带来的三宗罪远比“网络慢”严重很多刚入行的朋友以为环路就是“网络有点卡”实际完全不是这么回事。二层环路一旦产生会同时引爆三个问题广播风暴广播帧进入环路后交换机会从所有非接收端口转发出去。帧每绕一圈就会被复制一次数量呈指数级增长。哪怕只是一台终端发了一个ARP广播几秒钟后整个广播域里全是它的复制品。你可以想象一下两个人互相给对方寄同一封信每次都复印一份再寄回去几轮之后信箱就爆了。MAC地址表震荡交换机依靠源MAC地址学习来维护转发表。环路中同一个MAC地址的帧会从不同端口反复到达交换机的MAC表就在两个端口之间来回改写硬件转发的效率直接被拖垮。设备CPU过载大量重复帧涌向CPU交换机忙于处理协议报文和中断最终失去响应管理面完全瘫痪。所以说环路不是“拖慢网络”而是“干掉网络”。而生成树协议就是专门为这种场景设计的保险丝——逻辑上把冗余链路中多余的那条断开只留一条活动路径避免环路同时保留备份链路以备故障时切换。1.2 STP时代那套经典机制奠定了RSTP的底子在说RSTP之前得先把经典STP的运作逻辑交代清楚因为RSTP的所有改进都是站在STP肩膀上的。STP的思路很朴素在整个二层网络中选出一台根桥然后每台非根桥交换机选出一个根端口到根桥最近的端口每条链路上选出一个指定端口剩下的端口全部阻塞。这样逻辑上就形成了一棵以根桥为根、无环的树。为了实现这个选举交换机之间要交换一种叫BPDUBridge Protocol Data Unit桥协议数据单元的报文里面携带桥ID、路径开销、端口ID这些参数。桥ID由优先级和MAC地址组成数值越小越优先。选根桥比桥ID选根端口比到根的路径开销开销一样再比对端桥ID、端口ID一级一级地比下去。老实说STP的设计思路在今天看依然成立它已经为整个行业服务了二十多年。但它有一个致命短板——慢。端口从阻塞状态切换到转发状态要经历阻塞、监听、学习三个阶段。直连链路故障时根端口和阻塞端口要等Max Age计时器超时默认20秒再经历监听15秒、学习15秒总共将近50秒才能恢复通信。五十秒断网对今天的云桌面、视频会议、语音系统来说等于汶川大地震级别的灾难。这就是RSTP登场的历史背景。2. 一张表看懂RSTP的端口角色与状态变化RSTP的全称是Rapid Spanning Tree Protocol快速生成树协议标准是IEEE 802.1w后来被并入802.1D-2004。它和STP最大的区别不是换了一套选举规则而是在同为“阻塞”的端口里做了更细的分工同时把状态机精简了配合一套全新的握手机制把收敛时间从秒级压到了毫秒级甚至亚毫秒级。2.1 端口角色从3种变成5种多出来的是“即插即用的备胎”经典STP里端口角色只有三种根端口Root PortRP、指定端口Designated PortDP和阻塞端口Blocking Port。RSTP把阻塞端口一分为二增加为五种端口角色英文缩写在STP中的对应角色核心职责根端口RP根端口交换机去往根桥的最优路径端口正常转发指定端口DP指定端口某条链路上唯一负责转发和发送BPDU的端口正常转发替换端口Alternate PortAP阻塞端口本交换机上另一条能到达根桥的备份路径平时不转发根端口失效时顶替备份端口Backup PortBP阻塞端口同一交换机上同一链路的备份端口平时不转发指定端口失效时顶替禁用端口Disabled禁用端口端口被关闭或链路断开不参与任何转发留意Alternate和Backup的区别Alternate是“换一条路走照样到根桥”Backup则是“同一条路上再拉一根线防的是这条链路这头或那头坏掉”。实话说Backup在实际工程里很少见因为很少有人在同一个交换机之间拉两根线却不做链路聚合。但Alternate端口就太常见了——只要你的核心层有两台交换机做了堆叠或双上行接入交换机必定有至少一个Alternate端口。2.2 端口状态5种精简到3种Discarding才是核心STP的端口状态有5个禁用、阻塞、监听、学习、转发。RSTP把“禁用”“阻塞”“监听”合并为一种状态——Discarding丢弃。这样一来端口状态只剩3个Discarding丢弃不转发数据帧不学习MAC地址但依然接收和处理BPDU。处于这个状态的端口相当于“睁着眼睛的哨兵”随时待命。Learning学习不转发数据帧但开始学习MAC地址为进入转发状态做准备。Forwarding转发正常收发数据帧正常学习MAC地址。为什么能合并成3个因为RSTP认为一个处于禁用或阻塞的端口本质上和Discarding没有区别——反正都不转发数据。而“监听”这一层在RSTP的快速握手机制下变得可有可无所以它把状态机砍掉了。你只需要记住一个口诀RSTP里所有不能转发的状态都叫Discarding能转发的就是Forwarding中间过渡态只有Learning。2.3 为什么多一个角色恢复速度就快这么多理解了端口角色和状态RSTP“快”的底层逻辑就浮现出来了。经典STP在链路故障后阻塞端口要经历Max Age超时、再到监听、学习最后才转发像一个新人入职还要先培训半个月才上岗。而RSTP的Alternate端口一直在Discarding状态下监听BPDU对网络里的情况门儿清。一旦根端口收不到BPDU了Alternate端口不需要等待任何计时器直接从Discarding切到Forwarding整个过程通常只需要几十毫秒到一两秒。用生活里的话说RSTP不是“出事之后才开始重新招人”而是“平时就养着一批精通业务的备胎正主一倒下备胎立刻顶上去”。这就是端口角色细分带来的最大收益。3. 三个关键机制让RSTP把收敛时间从50秒拉到毫秒级端口角色和状态是RSTP的骨架真正让RSTP跑得飞快的肌肉是它的三个核心机制Proposal/Agreement握手、边缘端口、根端口和替换端口的快速切换。下面逐一拆。3.1 Proposal/Agreement握手把“慢慢等”变成“主动确认”这是RSTP最精彩的设计也是理解802.1w的关键。我们回顾一下STP为什么慢。在新的链路或者拓扑发生变化时STP的指定端口要发送BPDU然后等待对端回应再经历监听、学习各15秒稳如老狗但也慢如老狗。RSTP则改成了“提议—同意”Proposal/Agreement握手上行指定端口先发送一个Proposal报文给下游下游收到后立即阻塞自己的所有非边缘端口防止临时环路然后向发送方回应一个Agreement报文。发送方收到Agreement后立刻把这个端口切到Forwarding。这个握手过程通常只需要一次BPDU交换在没有报文丢失的理想情况下端口的转发状态几乎可以做到瞬间建立。实话说我第一次看RSTP的状态机时也愣了一下因为它把STP里以“秒”为单位的等待压缩成了以“毫秒”为单位的一次报文往返。打个不恰当的比方STP是“我发条消息过去你慢慢看看完我们再聊”RSTP是“我发条消息过去你只要回一个OK我这边马上就开工”。这里有个前提必须注意Proposal/Agreement握手成功的前提是对端也要支持RSTP且链路工作在全双工模式。如果对端是老的STP交换机或者链路处于半双工状态握手就会失败端口会老老实实退回STP那套慢速流程。这一点后面章节专门讲因为它是我在项目中踩过最大的坑。3.2 边缘端口连接终端的端口直接进转发不再装模作样一台上联核心的交换机下面挂几十台PC。每台PC开关机交换机端口都要重新生成一次走一遍完整的状态迁移这显然是巨大浪费而且PC开机后在30秒内连不上网体验极差。RSTP针对这种情况提供了边缘端口Edge Port机制。只要端口被设置为边缘端口它就假设下面不会连接其他交换机因此直接从Discarding跳到Forwarding不需要经历任何握手和学习过程。这跟Cisco的PortFast是一个意思但RSTP把它标准化为端口属性。配置命令上华为叫stp edged-port enableCisco叫spanning-tree portfast。注意边缘端口不是让你乱开的。如果你把一个连接了对端交换机的端口误设为边缘端口一旦下面出现物理环路环路就会立刻形成RSTP根本来不及阻断。所以工程上必须搭配BPDU保护端口一旦收到BPDU立刻进入Err-Disabled状态并告警而不是傻乎乎地继续转发。这个组合拳是接入交换机必备配置我后面讲配置时会展开。3.3 根端口和替换端口的切换故障不出圈本地直接顶经典STP在根端口失效时整台交换机要等Max Age超时然后重新计算到根桥的路径。RSTP则不同根端口检测到故障后本机上早就准备好的Alternate端口会立刻顶替不需要通知根桥也不需要全网重新计算。这相当于一线员工发现主管离职直接找备岗顶上而不是等总部空降新领导。那根桥本身出问题了呢比如核心交换机整机断电。RSTP的处理逻辑是下游交换机在超时时间内连续收不到根桥发来的BPDU就会认为根桥失联自己触发根桥重新选举。这个过程同样比STP快得多因为RSTP把BPDU的超时机制从“必须等到20秒Max Age”缩短为“连续3个Hello时间默认2秒一个Hello即6秒没收到就判定为超时”。此外RSTP对拓扑变更通知也做了大改动。STP时代任何拓扑变化都要先发给根桥根桥再通知全网绕一圈回来耗费大量时间。RSTP则是每台交换机自己感知到拓扑变化后直接向所有指定端口发送TC报文让全网交换机立刻刷新MAC地址表。一句话总结STP是层层汇报RSTP是就地决策加及时广播。3.4 BPDU格式的升级同样的报文装更多内容还有一个容易被忽略但非常关键的改进——BPDU格式。STP的BPDU里有一个8位的Flags字段但只用到了其中2位TC和TCA标志。RSTP把剩下6位全部利用起来用来承载提案、同意、端口角色、学习状态、转发状态等信息。这意味着RSTP的一次BPDU交互就能把端口的目的、角色、状态说清楚而STP要靠多轮交互逐步传递。另外RSTP的BPDU发送方式也不同。STP只有在根桥发生变化或者收到触发消息时才发BPDU发完就安静。RSTP的指定端口是每个Hello时间默认2秒主动向外发送BPDU即使拓扑没有任何变化也照发不误。这就像STP是“消防车着火才出动”RSTP是“巡逻车没火也天天在路上跑”。主动推送的好处是下游交换机可以快速感知上游设备是否故障而不需要干等一个超长计时器。4. RSTP与老STP混跑的兼容性问题最容易翻车的现场理论上讲IEEE 802.1w在设计时就考虑了与802.1D的兼容性RSTP交换机遇到STP交换机会自动按STP规则运行。但是在真实项目中协议间互操作恰恰是我遇到问题最多的地方。这一节专门讲兼容性每个场景都是我或身边同事真金白银踩出来的。4.1 协议迁移RSTP端口偶发回到STP状态做过混合组网的人可能遇到过这种情况某个端口明明配置的是RSTP一查状态却显示处于监听或阻塞状态收敛速度打得像STP。原因多半是——这个端口曾经收到过STP格式的BPDU。RSTP协议实现里有一个“迁移”机制如果交换机从某端口收到的是STP BPDU它就会自动把该端口切换成STP模式以便兼容对端设备直到迁移计时器超时且一直没再收到STP BPDU该端口才慢慢回到RSTP模式。问题在于这个迁移计时器长达Hello时间的3倍左右而且期间端口不会主动发送RSTP格式的BPDU。也就是说如果网络里有一台老设备隔几分钟发一次STP BPDU那么连接它的RSTP端口就会反复被拖回STP模式收敛性能时好时坏。排查建议如果你在端口上看不到连续的RSTP BPDU计数增长而只看到零零散散的STP BPDU多半就是混跑场景。这种问题没有银弹最好的解决办法是全网统一协议版本或者把老设备单独划到一个VLAN用协议翻译桥接。千万不要在混跑环境里指望RSTP的所有快速机制都能生效。4.2 Proposal/Agreement握手失败的三种典型场景前面说了P/A握手是RSTP快速收敛的灵魂。但下面三种情况P/A握手一定会失败端口会强制回退到慢速路径对端是STP交换机STP不理解RSTP的Proposal标志自然不会回Agreement。RSTP交换机只能等待Forward Delay计时器走完两轮即等待30秒才能把端口置为转发。这就是为什么混跑环境里RSTP依然慢的根本原因。链路为半双工半双工链路无法保证握手的可靠性RSTP直接选择不用快速机制。实际工程中光纤和网线的协商一般都能到全双工但如果有人手工把速率或双工模式写死为半双工RSTP的快速切换就会静默失效而且日志里还不报错非常坑。端口角色是Backup或Alternate这两种端口本身就不参与转发P/A握手不会让它们进入转发状态除非它们的上级角色失效。我在一次园区网改造中就吃过半双工的亏——运维为了“省事”把接入PC的端口强制成10M半双工结果全网RSTP收敛时间反而比STP还慢查了半天才发现是手工双工设置导致P/A握手全线失效。从那以后我在任何排障中都会先查端口协商状态这已经成了肌肉记忆。4.3 端口角色识别错误RSTP不是万能的别忽视物理拓扑RSTP再快也只能在既有拓扑内快速切换。如果物理拓扑本身设计不合理——比如根桥两端同时连接到一台终端交换机、但终端交换机缺一条去根桥的备份链路——那么RSTP能做的也只是故障后重新收敛依然需要计算、选举的过程只不过这个计算过程比STP快。换句话说RSTP是“加速器”不是“拓扑规划器”。想要充分发挥RSTP的优势拓扑结构必须设计成“每条关键链路都有备份”否则快速切换机制根本没有用武之地。分享一个实战案例某省分行网络改造接入交换机双上行到两台核心但其中一台核心端口下的光纤被老鼠咬断RSTP很快把流量切到了另一条链路业务没受什么影响。但两周后又有一根光纤被咬断这次恰好是另一条上联链路直接断了两台接入交换机的根路径。由于接入交换机到核心只有两条上联全部断开后它只能等6秒超时后重新选举根桥期间本来应该由Alternate端口接管的逻辑因为根本不存在替代路径而失效业务中断了将近10秒。事后复盘如果当初把两台核心做成堆叠或部署ERPS以太环网保护切换就能避免这种“备用路径也是共享风险”的坑。5. 手把手配置RSTP并验证收敛效果理论讲完直接上配置。下面分华为和思科两大主流厂商讲最后给一套完整的验证思路。所有配置都是基于我实际交付过的项目精简而来你可以直接抄作业。5.1 华为交换机开启RSTP华为默认启用的可能是STP或MSTP需要手工切换到RSTP模式。配置流程如下Huawei system-view [Huawei] stp mode rstp [Huawei] stp enable [Huawei] quit如果有多个VLAN需要在每个VLAN下确认生成树实例绑定正确。如果是纯二层场景直接全局配置即可[Huawei] stp bridge priority 0 # 把本机设为根桥优先级范围0-61440步长4096 [Huawei-interface-GigabitEthernet0/0/1] stp edged-port enable [Huawei-interface-GigabitEthernet0/0/1] stp bpdu-protection enable注意华为的根桥优先级默认是32768要设为根桥通常调到0或4096。bpdu-protection配合edged-port是标配如果对端有交换机误接BPDU保护会把端口直接置为Err-Disabled避免环路风险。5.2 思科/锐捷交换机开启RSTP思科虽然有自己的PVST但RSTP模式下通常用Switch(config)# spanning-tree mode rapid-pvst Switch(config)# spanning-tree vlan 1 root primary Switch(config)# interface g1/0/1 Switch(config-if)# spanning-tree portfast edge Switch(config-if)# spanning-tree bpduguard enable锐捷和H3C的命令跟思科非常接近spanning-tree mode rstp或spanning-tree mode rapid-pvst都可以看设备型号支持情况。我自己在锐捷设备上习惯直接开RSTP因为如果只用标准RSTP跨厂商兼容性最稳。5.3 验证命令不看状态等于没配配置完后验证比配置更重要。以下是我在每次割接前必做的五步检查查看全局生成树信息[Huawei] display stp brief [Huawei] display stp重点看根桥ID是否指向预期设备各端口角色是否和设计一致。华为的根桥ID默认格式是0.680b-xxxx-xxxx前面是优先级后面是MAC。查看端口状态机[Huawei] display stp interface g0/0/1确认端口状态是Forwarding角色是Designated还是Root。如果端口一直停在Discarding检查P/A握手是否成功通常要抓包看BPDU里有没有Proposal/Agreement标志位。查看BPDU收发计数[Huawei] display stp interface g0/0/1 verbose看Input/Output BPDU计数是否持续增长。如果收到RST BPDU但没发出多半是配置模式没生效。故意制造一次直连故障测试收敛时间用shutdown关掉根端口的物理接口同时在另一台终端上持续ping网关。记录丢包个数乘以ping间隔就是收敛耗时。我在现场一般用100ms间隔的持续pingRSTP正常在1秒内恢复如果大于2秒说明有协议降级。检查TC计数[Huawei] display stp topology-change拓扑变化次数频繁增加说明网络里有端口反复up/down或链路震荡。一次正常的链路切换会增加一次TC但一分钟内TC增加几十次就一定是物理层有问题。5.4 再补充一个排障小技巧怎么看根桥选错有时候根桥不是你期望的那台设备比如明明想让核心交换机当根桥实际根桥却是某台接入交换机。排查步骤如下先display stp看根桥ID再display stp brief对比本机桥ID如果发现根桥是接入交换机的MAC大概率是核心交换机的优先级没调。直接把核心的stp bridge priority从32768调低到4096再把所有接入交换机调到4096以上或保持默认根桥立刻收敛到核心。优先级相同情况下桥ID里MAC最小的胜出所以靠优先级“压住”才是正道。6. RSTP设计选型与运维习惯的几点经验技术原理和配置命令都聊完了这篇的收尾我想聊几个宏观层面的选型判断和运维习惯。这些内容不属于任何一本配置手册但都是我实际工作里沉淀下来的经验。6.1 能开RSTP就别再守老STP我的态度很明确除了极少数老古董设备不支持RSTP全网都应该启用RSTP。STP的时代留给了电话网络和早期以太网今天随便一台办公交换机都支持802.1w。RSTP默认参数就能工作无需额外调优且和STP兼容不会因为升级就出大问题。如果设备支持MSTP也可以用MSTP但MSTP主要价值在多实例负载分担普通二层园区网用不上徒增配置复杂度。6.2 边缘端口该配哪些不该配哪些边缘端口配置的原则很简单凡是下面只接终端设备的端口都可以配凡是连接交换机的端口一律不配。可以配边缘端口的典型场景接入交换机下连PC、打印机、IP电话接入交换机下连AP仅限Fat AP或桥接模式下的AP如果是Mesh AP下行端口走二层也要视情况定服务器网卡服务器一般只跑业务流量不跑生成树协议绝对不能配的场景接入交换机上联核心的下行口两台交换机之间的互联端口防火墙、路由器等三层设备虚接口对应的物理口如果跑VRRP或OSPF没必要开这个口我见过一个真实翻车案例一位同事把接入交换机上联口误设了Edge端口结果核心侧一根线松了又弹起物理环路持续了十几秒全网广播风暴几十台交换机CPU打满。事后分析就是Edge端口对BPDU无感知环路检测机制被绕过了。所以再次强调边缘端口必须配BPDU保护且别贪多。6.3 RSTP不是唯一选择但一定是最稳的底线方案做网络设计经常会遇到“要不要上堆叠”“要不要上环网协议”的争论。我做了个对比表方便大家权衡方案典型收敛时间配置复杂度成本适用场景RSTP1秒以内直连/Alternate切换低零协议自带标准三层/二层园区网MSTP1秒以内支持多实例负载分担中零大型园区网、需要vlan负载分担堆叠毫秒级业务层面几乎无感知中高中需堆叠线缆数据中心、核心层高可用ERPS/环网50ms以内单环中视设备而定工业环网、城域接入环链路聚合200-800ms成员链路切换低零两台设备间多条链路场景可以看到RSTP的定位是所有横向技术的“底线保障”——你不管上不上堆叠、做不做环网RSTP都应该作为兜底存在。链路聚合本身不能防环堆叠分裂时的防环依然要靠RSTP/MSTP兜底。所以我的设计习惯是核心层堆叠接入层双上联跑RSTP两端同时配置BPDU保护这样无论单点故障、设备重启还是堆叠分裂都能有协议层面的兜底。6.4 上线前做一次环路演练比出问题再救火强十倍讲真网络设备的生成树配置不难难的是没人愿意在业务在线时测试。我的建议是每次网络割接或上线新交换机前做一次有预案的环路演练。方法很简单准备一根短跳线找一台业务量小的接入交换机在维护窗口内将其下连的两个端口直接互通观察交换机和核心侧日志确认RSTP能在1秒内阻塞端口、业务不受影响然后拔线恢复。整场演练10分钟搞定但能让你对整个网络的生成树健康状况了如指掌。我习惯每隔半年在核心网络评估时做一次至今救回过两次因乱接线引发的潜在事故。另外运维监控上别忘了加一条每天检查核心交换机日志里的TC报文次数。如果某台设备频繁上报TC说明它下面的链路在反复震荡大概率是物理层问题或端口协商问题。及时处理这种“隐性问题”比等到故障爆发再排查要省心得多。RSTP这个协议说实话不难它在网络里就像是电梯的刹车系统——平时你永远不会注意它但一旦关键时刻掉了链子整栋楼的秩序都会乱掉。把它吃透至少能在项目交付时少熬夜在故障排场时少被喷。