1. 二层环路不是多一条路那么简单——先说清它为什么致命先说个我早年在一家单位亲历的场景。某天上班没多久办公区开始有人喊上不了网而且不是一两台电脑是整个楼层几乎同时瘫痪。设备指示灯狂闪CPU跑满风扇声音明显不对。当时第一反应是是不是有人中了病毒在发包但抓包一看满屏都是同一个广播帧在反复转发瞬间就明白——二层环路。后来定位发现是有人临时加了一根跳线把两台交换机用两根网线连上了形成了一个物理环路。整个过程不到几分钟整个二层网络就被广播风暴活活打死了。很多没系统学过网络的人会有一个直觉网络嘛多连一条线就是多一条路不是更稳吗实际上在二层网络里交换机的转发机制决定了多余的路不是备胎而是灾难。交换机转发帧的规则很简单收到一个目的MAC不在MAC地址表里的单播帧、或者目的MAC是广播地址的帧就会从除接收端口以外的所有端口转发出去。这个机制本身没有问题它让二层网络不需要配置就能互相通信。可一旦网络里出现物理环路这个从其他所有口转发的行为就会变成无限循环。我们来推演一下一个最简单的环路交换机A和交换机B之间接了两根线。A收到一个广播帧从两个口都发出去B从两根线分别收到同一个广播帧然后又各自从另一个口转发回去A再次收到再次转发……广播帧就在这两台交换机的两条链路之间来回弹跳并且每经过一次就被复制一份。这一份变两份两份变四份以指数级增速灌满整个广播域。除了广播风暴还有一个同样隐蔽的问题叫MAC地址表震荡。还是这个环路场景如果一台主机H通过交换机A在网段里发数据A的MAC地址表会记录H在某个端口。但因为帧会从环路的两条链路同时到达交换机一会儿在端口1上看到H的来源MAC一会儿又在端口2上看到于是MAC地址表的条目被反复改写导致交换机不知道该把发往H的帧从哪个口送出去产生大量错误转发进一步加剧故障。很多人会用十字路口没红绿灯来类比这个问题。我觉得更准确的说法是环路就像一张永远无法结束的反射游戏数据帧在里面被无限复制、循环、震荡直到把网络资源耗尽。要解决这个问题不能靠人工盯着线缆必须让交换机自己学会堵住其中一条路而这就是STP存在的价值。STPSpanning Tree Protocol生成树协议做的最核心的一件事就是通过逻辑上阻塞冗余链路把一个物理上有环的网络修剪成一棵逻辑上的树。也就是说底层的线不用剪但交换机通过协议协商主动让某个端口处于能收不能发的阻塞状态广播帧就不会在环里打转了。在展开配置实操之前必须先把这个协议是怎么运作的、它凭什么决定哪条路堵、哪条路通讲明白。因为如果你不理解选举逻辑配置命令永远只能靠背出问题的时候根本不知道从哪里查起。2. STP的决策过程拆解从BPDU到端口角色每一步都在干什么STP说到底是一个选举协议。整个网络里的交换机要通过互相交换一种叫做**BPDUBridge Protocol Data Unit桥协议数据单元**的报文共同协商出一棵没有环路的逻辑拓扑。BPDU里带着优先级、MAC地址、路径开销这些关键信息交换机之间就是靠比对这些信息来确定身份的。2.1 根桥选举整个网络的绝对权威STP网络里最高地位的设备叫根桥Root Bridge。它相当于整棵树的根是所有路径开销计算的起点。根桥不是管理员手动指定的也可以指定后面配置部分会讲而是交换机们自己选出来的。选举依据是桥IDBridge IDBID由两部分组成桥优先级默认32768 桥MAC地址。其中优先级数值越小的越厉害如果优先级一样就看MAC地址MAC地址越小越厉害。也就是说桥ID最小的交换机当选根桥。这就有个非常反直觉的地方根桥不一定是性能最强的设备很可能只是一台可怜的旧交换机。因为默认情况下大家都用同一优先级纯粹比MAC地址大小旧设备MAC地址小一点就被选为根桥了。这样就会导致大量跨交换机流量都要经过这台低端设备网络性能被严重拖累。这也是很多还没环路的网络却慢得不行的隐性原因之一——根桥选的不好。2.2 开销计算带宽越大的路代价越小根桥选出来之后非根桥的每台交换机都要计算自己到达根桥的路径开销也就是根路径开销Root Path Cost。一条链路的开销值和它的带宽成反比——带宽越高开销越小意味着这条路更便宜更优先被使用。这里贴一张常见的链路开销对照表不同标准下数值有些差异但逻辑完全一致链路带宽STP802.1D开销值RSTP802.1w开销值10 Mbps1002,000,000100 Mbps19200,0001 Gbps420,00010 Gbps22,000注意同一带宽在RSTP下的开销值被放大了这是为了支持更高的链路速率比如40G、100G口保证高带宽链路在计算中有明确的区分度。在老标准里10G和100G如果都映射成2就无法比较了。2.3 根端口、指定端口与阻塞端口三种角色怎么定选举完根桥和路径开销之后接下来就是端口的角色划分。STP里一个端口最终只会是以下三种角色之一根端口Root Port非根桥交换机上到达根桥路径开销最小的那个端口。每台非根桥交换机上有且仅有一个根端口。它是这台交换机通往根桥的官方通道负责把本交换机和其他交换机之间的BPDU、数据帧向上转发。指定端口Designated Port每段链路上到达根桥路径开销最小的那个端口。它的逻辑是一条链路两端都连接着交换机那么总得有一个端口负责转发数据这个端口就是指定端口。通常根桥上的所有端口都是指定端口因为根桥到达根桥自己开销是0不可能有比它更小的。阻塞端口Blocked Port既不是根端口也不是指定端口的端口。它被STP逻辑上阻塞不转发数据帧只监听BPDU用来兜底——一旦主链路的端口挂了它就能切换成转发状态。我在教别人的时候经常用一个比方把根桥比作公司的董事长每台交换机比作部门经理。根端口是经理从自己座位走到董事长办公室最近的那扇门指定端口是两个部门之间工作交接时指定走的那道门阻塞端口是平时锁着以防走串、紧急情况下才开的逃生门。角色一旦定好数据就只走该走的门环路自然就消掉了。2.4 端口状态机阻塞到转发要经历什么端口角色定下来之后端口状态还要经历几个阶段才能开始干活。经典的STP端口状态有五个Disable关闭端口被管理员down掉或者物理链路断开。Blocking阻塞端口不转发数据帧也不学习MAC地址但能接收和发送BPDU。这是STP的安全态。Listening监听端口开始参与根桥和角色选举但依然不学习MAC地址。顾不得转发数据。Learning学习端口开始学习MAC地址、构建转发表但仍然不转发数据帧。这个阶段是为转发做准备。Forwarding转发端口完全正常地收发数据和BPDU。这个状态机的代价非常明显——一个端口从Blocking走到Forwarding默认要经过一个Listening15秒 一个Learning15秒也就是30秒。如果链路里还有拓扑变化通知的等待时间最长可能需要45~50秒全网才能恢复可用。想想看一台终端接入一个交换机端口至少要等30秒才能正常上网。对终端用户来说这意味着插上网线要等半分钟网才通。如果是核心链路失效需要切换备份线路这半分钟的断网时间可能就是生产事故。3. 设备上的STP配置实操以常见交换机为例说清每条命令的用意讲了这么多原理是时候落地到设备上了。我以目前企业里最广泛使用的VRP平台交换机为例做演示如果你用的是其他平台的设备只要理解了STP逻辑命令本质是一样的无非是映射关系不同。配置之前先假设一个最简单的拓扑方便说明也方便你复现SwitchA 和 SwitchB 之间接两条物理链路GE0/0/1 和 GE0/0/2构成环路。SwitchA 上挂一台PC接入PC的端口我们不参与环路计算后面会讲边缘端口的处理。要求逻辑上只使用一条上行链路另一条用于冗余备份。3.1 在每台交换机上启用STPVRP平台默认就开启STP通常是MSTP模式但如果我们想把配置主动权握在自己手里建议还是手动确认一遍模式。[SwitchA] stp mode stp [SwitchB] stp mode stpstp mode stp是把生成树模式强制切换为传统的802.1D STP模式。为什么要单独强调这个命令因为很多交换机默认跑的是MSTP多实例生成树它兼容STP但行为细节上有些差异。如果你要做实验、考证或者想严格复现STP的特性先统一模式是最省心的做法。如果你不清楚当前设备跑的是什么模式可以敲display stp查看输出里会显示当前生成树模式和桥的各项参数。接下来验证根桥选举结果。使用命令display stp brief能看到每台交换机上的端口角色和状态[SwitchA] display stp brief MSTID Port Role STP State Protection 0 GigabitEthernet0/0/1 Root FORWARDING None 0 GigabitEthernet0/0/2 Altn DISCARDING None在SwitchA上我们看到GE0/0/1是根端口Root处于FORWARDINGGE0/0/2是Alternate端口这条命令输出里Altn就是阻塞端口的另一种叫法处于DISCARDING阻塞不发数据但不等于物理down。如果两条链路都是同一个交换机到同一个交换机STP会把物理编号靠前的那个端口选为转发端口另一个阻塞。这里GE0/0/1被选为转发GE0/0/2被阻塞。3.2 把运气选举改成规划选举——手动调整根桥优先级默认情况下根桥完全靠MAC地址大小选出来这是不合理的。我们应该主动在核心设备上把优先级调到更低让核心设备稳定充当根桥[SwitchA] stp priority 4096优先级数值必须是4096的整数倍这是协议的规定取值范围从0到61440默认32768。我把SwitchA的优先级调成4096它就成了全网最小的桥ID稳定当选根桥。这样做的意义是什么任何配置不能只做一步得让备份设备也做好准备。假如我把核心交换机SwitchA的优先级设为4096同时把备份核心SwitchB的优先级设为8192那么正常情况下SwitchA是根桥一旦SwitchA宕机SwitchB自动接替成为根桥而且因为还有更低的优先级设备存在假设未来把第三台设备调成0网络不会因为根桥选举而出现剧烈震荡。有人在配置根桥时会追求绝对稳定干脆把根桥优先级设为0。但我建议保留一点冗余余地因为如果你之后想把一台更重要的核心设备纳入网络、且希望它成为根桥还需要改优先级而优先级已经是0之后就没法再往下压了只能临时把另一台调大操作起来反而麻烦。3.3 修改端口开销让STP按照你的意愿选路有时候我们不希望STP采用默认的按带宽选路结果。比如两条链路带宽相同比如都是1G但其中一条经过的是高负载的中转交换机我们希望流量尽量不走这条路那么可以通过修改端口开销来诱导STP选路。[SwitchA] interface GigabitEthernet0/0/2 [SwitchA-GigabitEthernet0/0/2] stp cost 20000注意在经典STP里1G链路的默认开销是4RSTP下是20000。我把GE0/0/2的开销改成20000这条路径到达根桥的总开销就会比GE0/0/1更大STP就会更倾向阻塞GE0/0/2而转发GE0/0/1。这个技巧在实际网络设计里很实用。比如两楼之间的两条光纤一条是直连核心的专线另一条是绕经接入汇聚的慢链路哪怕都是万兆你也不希望STP把慢链路选为活动路径。调整cost比物理拔线要优雅得多而且故障时还能自动回切。3.4 把连接终端的端口设为边缘端口干掉30秒等待这可能是STP配置里收益最大、操作最少的改动。前面说过一个端口从阻塞到转发要30秒连接PC、打印机、服务器的接入端口完全没必要经历这个等待因为它们下面不可能再出现环路除非有人恶意把两台PC串起来但概率极低。[SwitchA] interface GigabitEthernet0/0/24 [SwitchA-GigabitEthernet0/0/24] stp edged-port enable配置边缘端口之后这个口只要物理Up立刻进入Forwarding状态插上就能通不用等30秒。几乎所有做接入层的工程师都会配这一条但很多刚入门的朋友不知道导致电脑插上网线老是转圈半分钟才能上网还以为是DNS问题。不过注意边缘端口只是逻辑上认为下面没有交换机。如果有人手贱把一个边缘端口用网线接到了另一台交换机上就会在下游形成未被STP覆盖的环路。所以更稳妥的做法是同时开启BPDU保护[SwitchA] interface GigabitEthernet0/0/24 [SwitchA-GigabitEthernet0/0/24] stp edged-port enable [SwitchA-GigabitEthernet0/0/24] stp bpdu-protection开启BPDU保护后一旦这个边缘端口收到了BPDU报文端口会被直接Error-Down自动关闭并上报告警。这相当于防了一道插到交换机上也能先保护住的保险。我在实际运维里见过不只一次边缘端口收到的BPDU来自一台没有正确启用生成树的小交换机结果整个接入区域广播拥堵。开了BPDU保护后这些伪装边缘端口会第一时间被关掉故障边界就能立刻隔离。3.5 验证配置的完整命令集配置完别急着走用三条命令把根桥信息、端口角色、状态都过一遍[SwitchA] display stp [SwitchA] display stp brief [SwitchA] display stp topology-change第一条看全局参数确认自己是根桥Bridge Identifier和Root Identifier一致就是自己第二条看每个端口的角色、状态第三条看拓扑变化计数这个特别有用——如果这个数值在不断增长说明网络里频繁有人插拔网线、或者某条链路在抖动需要留意。另外抓包查看BPDU也是一个好办法。在交换机的任一端口上抓包你都能看到周期性的BPDU报文默认每2秒发送一次里面带着Root Identifier、Cost、Port等信息可以直接用来判断交换机眼中的根桥是谁。如果你的抓包结果里根桥和你的规划不一致那多半是哪台设备的优先级没调过来回头检查就是了。4. STP收敛太慢怎么办RSTP的改进与配置迁移经典STP最大的槽点就是慢。前面说过一个端口要经历Blocking、Listening、Learning到Forwarding四个阶段默认监听15秒学习15秒一共30秒。假如这台交换机不是根桥还有额外的问题当它检测到根桥失联时要先等待一段最大老化时间Max Age默认20秒确认根桥真的挂了才开始重新选举然后又是30秒的听力学习最坏情况50秒网络才恢复。我对这个问题的记忆特别深因为实习期就遇到过核心设备重启整个办公区断网将近一分钟所有打印机、POS机、门禁系统全部掉线监控室电话被打爆。那时候我才真正理解30秒对业务是什么概念——它不是等一下,而是故障长时间无法恢复的生产事故。所以后来的网络设备默认都会启用RSTPRapid Spanning Tree Protocol快速生成树协议802.1w它把STP的收敛时间从30秒级压缩到了亚秒级甚至秒级。4.1 RSTP做了什么收敛才能这么快RSTP最大的改进是引入了一种提议-同意Proposal/Agreement的握手机制让指定端口可以直接向下游交换机发出我确认自己是这条链路上的指定端口的提议下游交换机如果同意就立即进入转发状态而不用等待计时器慢慢走。这个握手在整棵树上逐级快速传递所以拓扑变化时整个网络几乎是瞬间完成角色协商的。另外RSTP把端口状态从5种精简为3种Discarding、Learning、Forwarding把端口角色从3种扩展到4种Root、Designated、Alternate、Backup。Alternate端口和Backup端口平时都处于Discarding但前者是根端口所在链路的备份后者是指定端口所在链路的备份角色定义更清晰在下游链路失效时可以更快接替。还有一个大家非常容易忽略的点RSTP对边缘端口的处理不同。在经典STP里即使某端口被配了PortFast思科叫法/边缘端口华为叫法理论上它仍然能接收BPDU但在RSTP里边缘端口根本不参与生成树计算完全绕过握手流程物理Up就直接Forwarding收敛时间等于零。4.2 从STP平滑迁移到RSTP好消息是RSTP向后兼容经典STP。同一个二层网络里只要有一台设备支持RSTP而其他设备还在跑老STPRSTP设备会自动通过BPDU版本协商降级成老STP模式保证能互通。但你得明白这种降级兼容意味着整个网络依然按老STP的慢收敛方式工作RSTP的快速握手在只有一端支持的情况下是不会生效的。所以真正的迁移方案是让全网所有交换机都改成RSTP模式。这一步在现代企业网络里几乎已经是标配了VRP平台上默认模式就是MSTP内部兼容RSTP行为你只需要确认每台设备都跑RSTP/MSTP即可。如果确实还在跑老STP想切换可以逐台执行先边缘再核心。为什么先边缘因为边缘设备切换影响范围小即使出问题也只是一个接入区域核心设备放最后切换等其他设备都就绪了再动核心这样就算协商出问题影响面也可控。配置命令很简单[SwitchA] stp mode rstp改完之后用display stp确认运行模式已经是RSTP再用display stp brief观察端口状态。理论上你会在链路故障切换测试时看到备份端口几乎瞬间进入转发状态。4.3 实测一个切换场景我自己做过这样一个测试两台交换机做双链路互联跑经典STP。从主端口物理拔线开始计时到备份端口进入Forwarding用时约30秒。然后把模式切成RSTP同样拔线备份端口在1.5秒内就转发了。这个对比非常直观——不需要什么复杂工具就是物理拔线按秒表新手也能复现。这里补充一个细节RSTP下端口从Discarding进入Forwarding也可能不是严格意义上的0秒取决于它是否真的收到了下游的同意消息。如果链路另一端是不可感知的哑设备比如只连接PC的边缘端口RSTP完全可以做到实时转发但如果另一端是另一台交换机并且没有及时回应可能会经历短暂等待。所以如果你发现一台设备上有些端口没有秒进转发先确认对端设备的STP模式是不是也统一了。5. VLAN多实例的复杂度MSTP如何避免一棵树管一个园区双活前面讲STP、RSTP时默认场景都是整个二层网络只有一颗生成树——也就是说不管网络里有几个VLAN所有VLAN共用同一个根桥、同一棵逻辑拓扑。这在规模小的时候没问题但一旦VLAN数量多起来会出现一个尴尬的情况。假设一个园区网划分了几十个VLAN核心交换机和汇聚交换机之间做了双链路你希望这双链路能分担负载——一半VLAN走链路1一半VLAN走链路2这样两条线都能用起来而不是一条转发一条闲置。但经典STP/RSTP只有一个拓扑实例只能用一条链路另一条永远沉睡带宽利用率打五折。这就是**MSTPMultiple Spanning Tree Protocol多生成树协议**存在的价值。它允许多个VLAN映射到同一个实例Instance上每个实例可以独立选举根桥、独立计算生成树。比如实例1里链路A是转发、链路B是阻塞实例2里反过来链路B是转发、链路A是阻塞。这样同一个物理双链路两组VLAN的流量就分开了链路利用率接近翻倍。一句话总结RSTP解决了慢的问题MSTP解决的是一棵树不够用的问题。5.1 MSTP的基本概念区域、实例、VLAN映射MSTP里引入了一个概念叫MST区域MST Region。一个区域由一组交换机组成它们必须满足三个条件具有相同的域名。具有相同的修订级别Revision Level。实例与VLAN的映射关系完全一致。注意第四条很关键——如果两台交换机的VLAN映射表不一致它们会被判定为不属于同一个MST区域跨设备的生成树计算会退化为多棵独立树容易出问题。配置MSTP时最常踩的坑就是有的交换机没配区域的VLAN映射导致实例划分对不上。5.2 MSTP配置实操双核心双链路负载分担我以最常见的双核心下挂接入交换机的拓扑举例。假设有VLAN 10和VLAN 20两根上行链路。我们希望VLAN 10走链路1VLAN 20走链路2。配置步骤如下步骤一在每台交换机上创建MSTP配置核心交换机A[SwitchA] stp region-config [SwitchA-mst-region] region-name HX-SPINE [SwitchA-mst-region] revision-level 1 [SwitchA-mst-region] instance 1 vlan 10 [SwitchA-mst-region] instance 2 vlan 20 [SwitchA-mst-region] active region-configuration核心交换机B[SwitchB] stp region-config [SwitchB-mst-region] region-name HX-SPINE [SwitchB-mst-region] revision-level 1 [SwitchB-mst-region] instance 1 vlan 10 [SwitchB-mst-region] instance 2 vlan 20 [SwitchB-mst-region] active region-configurationinstance 1 vlan 10的意思是VLAN 10被划分到实例1VLAN 20被划分到实例2。active region-configuration这条命令一定要敲很多初学者配完忘记激活结果区域配置根本没生效。步骤二为不同实例设置不同根桥既然要让两个实例走不同链路最直接的办法是让两台核心交换机分别充当不同实例的根桥。核心交换机A上配置[SwitchA] stp instance 1 root primary [SwitchA] stp instance 2 root secondary核心交换机B上配置[SwitchB] stp instance 1 root secondary [SwitchB] stp instance 2 root primary这样实例1的根桥是A所以A的链路1转发实例2的根桥是B同样地B的链路2转发。两台核心交换机形成双活角色分摊不同VLAN的流量。步骤三验证实例视角的端口角色验证命令要带上实例编号否则默认只显示实例0也就是传统STP视角下的结果[SwitchA] display stp instance 1 brief [SwitchA] display stp instance 2 brief如果配置正确你会看到实例1和实例2里同一物理端口可能扮演不同角色在实例1中是转发Forwarding在实例2中是阻塞Discarding。这正是我们想要的负载分担效果。我见过很多人配MSTP时把VLAN映射配反了——两边交换机实例1映射的VLAN不一致然后跑到接入交换机上一看端口状态一脸懵为什么有的转发有的阻塞跟设想的完全不一样。排查方法就是回到两台核心交换机上逐个核对区域配置看区域名、修订级别、实例映射是否完全一致。5.3 关于MSTP的设计建议在实际网络设计里MSTP不可能做到每个VLAN一个实例——那样实例数量爆炸配置复杂度和维护成本都会飙升。一般建议实例数量控制在几个到十几个以内够业务需求即可。把对路径有相同需求的VLAN合并到一个实例比如普通办公VLAN一个实例、视频监控VLAN一个实例、服务器区VLAN一个实例。保证每一个实例的根桥和设备、链路都事先画好拓扑图再映射VLAN。先在图纸上推演一遍再上设备改配置能省掉大量现场排查时间。MSTP的另一个好处是它天然兼容RSTP和STP设备能组成不同级别的生成树网络。但请牢记兼容不等于高效如果整网只有几台设备跑MSTP的收益不大直接用RSTP反而更简单可靠。技术选型永远要跟着规模走不要为了追新而上复杂的方案。6. 排查生成树故障的完整思路我在项目里踩过的几个坑生成树的坑通常不会天天出但一旦出往往就是全网瘫痪级别的大故障。故障现象往往是网络一会通一会断、广播风暴、部分终端无法获取IP甚至整个VLAN所有终端掉线。以下是我在项目里总结出的排查思路按照这个顺序走能少走很多弯路。6.1 根桥漂移为什么我指定的核心不是根桥根桥漂移是最常见、也最容易蒙蔽人的问题。现象是网络时通时断或者所有VLAN的流量都被引导到一台非核心的旧交换机上。根因往往指向某台设备的优先级没设置成功或者BPDU报文被篡改/隔离。排查步骤先看全局STP信息display stp查看每台交换机眼中的根桥ID。比较各台设备的根桥ID是否一致。如果出现不同说明网络被隔离成了多个生成树域二层链路在某个位置断开了。检查每台设备的优先级配置display stp brief确认端口角色和转发状态是否符合预期。确认是否有交换机的BPDU被某种安全策略拦截比如端口安全、BPDU Filter等导致核心桥信息传不过去。我遇到过最隐蔽的一次是某台接入交换机上有人配了全局的bpdu-filterBPDU过滤把所有BPDU都丢掉了。这台交换机永远无法感知根桥的存在于是它自己当起了根桥下面的终端获取IP自然出问题。排查时翻到这台设备的隐藏配置才找到根源。所以凡是涉及STP异常第一件事就是全局梳理一遍有没有人误配了过滤或保护策略。6.2 端口角色反复变动链路不稳和速率协商有一种故障现象是display stp brief里看到端口角色从Root/Designated在两种角色之间跳来跳去伴随这网络抖动。这种情况多数不是生成树协议本身的问题而是底层的物理链路或速率协商有问题——比如光模块松动、双工模式不匹配导致BPDU丢失生成树反复重新选举。我的做法是先看物理层状态display interface看端口流量是否有大量CRC错误、双工是否正常。再查STP拓扑变化计数display stp topology-change如果数值在快速增加基本可以断定物理层有间歇性抖动。遇到这种情况不要急着调STP参数先把物理链路处理干净。换线、换光模块、统一速率双工模式很多生成树问题其实是物理层问题。6.3 端口一直Learning不过去握手失败怎么办RSTP下某个端口卡在Learning状态不前进最常见的原因是下游对端没有运行RSTP或者对端是一个不支持快速握手的设备比如老式集线器、以及某些不支持STP的小交换机。于是RSTP设备发送提议帧后等不到同意帧只能退回等待超时。排查时可以抓包看BPDU观察有没有收到对端的同意帧。如果一直收不到可以直接将对端的STP模式确认一遍或者把该端口强制设为边缘端口在确认它下面确实没有其他交换机的前提下来绕过握手等待。这里要强调一个安全边界边缘端口只对终端设备用。如果这个口下面接的是另一台交换机哪怕它没有启用STP把它设置为边缘端口是个隐患。真正稳妥的做法是能开启对端STP就开启不能开启就把这条链路放在设计里画出来让BPDU保护兜底。6.4 全网多生成树的误区为何不同VLAN走不同路却收到广播风暴有一次用户告诉我不同VLAN走不同路之后还是有广播风暴。过去一查发现有人把两台交换机之间的两根链路分别划到了两个不同VLAN里但只配置了RSTP单实例。RSTP没法按VLAN区分拓扑于是它仍然让其中一条链路阻塞另一条转发而VLAN 2里的流量被转发VLAN 1的流量却被阻塞VLAN 1的用户就上不了网。其实这个场景真正需要的是MSTP而不是RSTP。很多刚分清楚VLAN和STP关系的人会混淆这两者的层觉得VLAN隔离了广播域所以环路也隔离了这是一个很危险的误解——VLAN能隔离广播域但不能隔离物理环路对生成树的影响因为不同VLAN共享同一条物理链路时RSTP选择阻塞的端口会同时阻塞所有VLAN。要让不同VLAN利用不同链路必须用MSTP按实例来做VLAN映射。所以下次看到多VLAN链路利用率上不去的情况先别急着怀疑配置先确认生成树模式是不是支持多实例。6.5 故障排查的通用顺序清单把思路整理成清单方便你站在现场对着操作步骤检查内容常用命令1确认生成树模式是否统一display stp mode2确认根桥是否符合规划display stp3确认每台交换机的端口角色和状态display stp brief4确认是否有BPDU过滤或保护display stp bpdu-filter/display stp protection5确认物理层不存在错误display interface6确认拓扑变化计数是否稳定display stp topology-change7在关键链路抓包确认BPDU抓包工具这套顺序基本能把大部分生成树故障定位到3个层面协议层角色漂移、安全层过滤策略、物理层链路抖动。我每次排障都是这个顺序省时间也避免对着错误方向瞎猜。7. 写在最后STP不会消失配置之前先画一张树经常有人问我现在大家都在讲SDN、云网络、自动化运维STP是不是已经过时了、不用学了我的看法是只要二层交换网络还存在环路问题就一定存在生成树的思想就不可能过时。哪怕在数据中心VXLAN架构里Underlay网络依然要跑生成树来防止意外的二层环路。你可以不亲手敲stp mode rstp但你必须理解它为什么能防环、怎么防环永远用得上。最后分享一点个人体会配置STP从来不是最难的部分难的是知道自己配置完之后这棵逻辑树长什么样。我建议所有人在敲配置之前哪怕不画图也要在心里过一遍谁是根桥哪个端口是根端口哪条链路被阻塞几个VLAN分别走哪条路把这三个问题回答出来再动设备STP的配置就基本不会出大错。如果在排查生成树问题时遇到说不清的现象不妨先从最基础的事实开始拔掉一根建立环路的物理线看网络是否恢复。这个动作简单粗暴但往往能最快确认问题是否确实由环路引起。确认了根因再回头用协议逻辑逐步定位比在设备上反复重启、乱改参数有效得多。