先聊个很多网络工程师都纠结过的问题为了可靠性给交换机之间加了两条链路结果网络不仅没有更“稳”反而隔三差五瘫痪。广播帧在物理环路里无限复制交换机MAC地址表疯狂抖动CPU被BPDU和广播包打满。平时看似人畜无害的接入层小环路关键时刻能让整片业务网停摆。解决这一切的就是STP这棵“逻辑树”。这篇内容我从原理讲到配置再到中兴交换机上MSTP的完整落地过程适合刚接触交换技术的初学者也适合需要在生产网里做冗余改造、负载均衡的运维同学。看完你能明白为什么MSTP比STP聪明得多也能直接抄一套能用的配置。1. 环路并不是“多条路更稳”而是灾难的起点1.1 先看环路是怎么被“好心”制造出来的做过网络的都知道生产网里交换机之间几乎不可能只连一根线。常见的场景是核心交换机A和B之间做堆叠或级联接入交换机SW1为了冗余分别上联到A和B或者两台接入交换机之间再互联一根线。物理拓扑就变成了一个“回”字或“口”字。从设计者的角度看任何一台交换机的上行链路断开业务还能从另一条链路绕过去这确实是高可用。但物理冗余有个容易被忽略的代价以太网帧本身没有TTL交换机对广播帧、组播帧、未知单播帧的处理原则是“收到就泛洪”。一旦二层拓扑存在环路这些帧会在环路里像陀螺一样永不停歇地转发每一台交换机都在重复复制和转发最终耗尽所有链路带宽和交换芯片的转发能力。这就是广播风暴。不夸张地说我在模拟环境里只搭了两台交换机、一条网线形成的环路几秒钟内就能让思科、华为、中兴这些设备的CPU占用率达到百分百Console口敲命令都卡。1.2 MAC地址表漂移才是最先暴露的问题环路初期不一定先表现为“完全瘫痪”更多时候是网络时通时断、丢包严重。原因在于交换机需要做二层转发它维护着一张MAC地址表记录每个MAC地址从哪个端口学来。环路里同一个帧既可以从A口进来也可以从B口进来交换机会认为这个MAC地址在A口和B口之间来回“横跳”于是一直刷新地址表导致原本该走最优路径的帧被随机发往某个方向实际效果就是丢包、延迟增大、业务间歇性不可用。这个问题在做故障排查时非常典型登录设备后执行MAC地址表查询看到同一个VLAN下同一个MAC地址对应多个端口并且这个对应关系实时变化就可以基本判定二层存在环路。而STP/MSTP的存在就是在物理上允许你保留冗余链路逻辑上却把交换网络剪成一棵没有环的树——多余的那条链路被阻塞只在主链路故障时才打开。1.3 为什么不能靠手工断开一条线解决有人问既然环路这么恐怖手工把冗余链路shutdown掉不就行了当然可以但这就等于放弃了冗余。真正的需求是平时让一条路径工作、其他路径备份工作路径挂了备份路径自动顶上。这个“自动”就是生成树协议要干的活。所以STP真正解决的是两个问题一是消除广播风暴和MAC漂移二是提供链路故障时的自动切换能力。理解了这一点你再去看STP每个参数和状态设计会觉得一切都合理起来了。2. STP、RSTP、MSTP三代协议解决了什么问题2.1 传统STP802.1D的看家本领生成树协议的核心思想是交换机之间通过交换网桥协议数据单元来协商选出一台交换机作为根桥然后计算出一棵以根桥为根的树状拓扑。不在树上的冗余端口被置为阻塞状态既不转发数据帧也不学习MAC地址只监听BPDU。在这个体系里有两个关键概念第一根桥的选举。每个交换机启动时都认为自己是根桥向外发送携带自身桥ID的BPDU桥ID由优先级和MAC地址组成优先级数值越小越优先。通过比较最终全网只有一个根桥。第二端口角色的确定。根端口是向根桥方向最优的端口指定端口是每条网段上离根桥最近的端口其余端口就是阻塞端口。为了收敛拓扑STP端口状态要经历禁用、阻塞、监听、学习、转发五个阶段默认Forward Delay为15秒从阻塞到转发通常要经过两个Forward Delay也就是约30秒。这个30秒在现在的业务网络里是不可忍受的。我见过一台S9300老设备因上游链路切换导致全网OSPF邻居全震荡的案例根本原因就是STP收敛太慢VLAN接口状态一直起不来。所以后来就有了快速生成树。2.2 RSTP802.1w到底快在哪里RSTP对STP做的最重要改进是把端口角色细化为根端口、指定端口、备份端口、替换端口并且引入了提议—同意机制。上游端口发出提议BPDU下游端口直接回应同意新链路可以在一个握手周期内进入转发状态不再依赖漫长的Forward Delay倒计时。此外RSTP还允许配置边缘端口接PC和服务器这类不会产生环路的端口可以立即进入转发状态省去30秒等待。在RSTP下链路切换的收敛时间通常能压到1秒以内取决于设备转发能力和拓扑复杂度。相对STPRSTP已经是质变。但它依然是单实例生成树也就是说整个交换网络不管有多少个VLAN都共用一棵树。这带来两个问题第一流量必须走根桥所在的那条路径另一条冗余链路始终闲置没法负载分担第二某个端口为了破环被阻塞那这个端口对应的所有VLAN都被阻塞哪怕这个VLAN其实不需要从这里走。2.3 MSTP802.1s是多棵树的“平行宇宙”MSTP的出现就是为了解决RSTP不能负载均衡的问题。它的思路是把交换网络划分成多个生成树实例每个实例拥有独立的生成树计算过程然后让不同VLAN映射到不同实例。实例1生成的树可以走链路A实例2生成的树可以走链路B两者互不干扰。对用户而言不同VLAN的流量各走各的路径冗余链路全部被利用起来。形象一点说RSTP像整座城市只有一条主干道堵车就只能等MSTP像是给不同方向的车流分别规划了高架桥各走各的路互相不添堵。当然这也意味着配置复杂度上了一个台阶。你要设计实例要划分VLAN映射还要保证同一MST区域里的交换机配置一致这也就引出了下一章要讲的三个核心概念。表三代生成树协议核心能力对比协议标准收敛速度支持多实例多VLAN负载均衡配置复杂度STP 802.1D秒级30s否否低RSTP 802.1w秒级以内否否低MSTP 802.1s秒级以内是是中高3. MSTP最核心的三个概念实例、VLAN映射和生成树区域3.1 实例逻辑上的一棵独立生成树MSTP中的“实例”就是一个生成树计算单元它的编号从0开始。实例0是IST必须存在所有没有显式映射到其他实例的VLAN都归属实例0。剩下的实例编号可以自定义比如在中兴交换机上你可以把实例1、实例2、实例3创建出来每个实例都独立运行生成树算法各自选举根桥、计算最优路径。要特别提醒的是每个实例的根桥是可以独立指定的。这是做负载均衡的关键操作。传统RSTP只有一个根桥所有VLAN的数据平面都向根桥汇聚。MSTP里你完全可以让实例1的根桥是核心交换机A实例2的根桥是核心交换机B这样VLAN 10的流量以A为根VLAN 20的流量以B为根两根上行链路都被用上没有一条是闲置的。3.2 VLAN映射表决定哪个VLAN走哪棵树实例本身没有意义只有和VLAN映射绑定后它才算承载了实际业务。映射的规则很简单一条命令里把VLAN列表和实例编号绑定。中兴设备通常使用instance instance-id vlan vlan-list这种形式配置比如instance 1 vlan 10就意味着VLAN 10的BPDU参与实例1的生成树计算VLAN 10的数据转发路径完全由实例1的树形拓扑决定。这里最容易踩坑的是映射遗漏。我见过有人在核心设备上把VLAN 10映射到了实例1但接入交换机上忘记给VLAN 10做映射结果VLAN 10在MSTP网络的某个区域里走了实例0的默认拓扑和预期路径完全不一致。更严重的是如果两端VLAN映射不一致交换机之间的MST配置握手会失败生成树会被迫落在CIST上整个MSTP区域内的隔离和负载分担全部失效。3.3 生成树区域MSTP的“行政区划”生成树区域是MSTP引入的一个非常独特的概念。所谓MST区域是指一组有着相同MST配置的设备集合这个配置包括区域名称、修订级别以及VLAN和实例的映射关系。只有这三者完全一致的交换机才算处于同一个MST区域中。如果两台交换机名字相同、修订号相同但VLAN映射表不同它们会被视为不同区域区域之间的互联链路会成为CIST或MSTI的边界。这个边界一旦出现跨区域的VLAN流量很容易出现路径绕远、甚至阻塞端口选择错误的情况。所以MSTP的配置必须做到全网一视同仁别想着只在核心上配一下接入层随便写写就行。每台设备的配置都需要完整对齐。中兴交换机上区域配置通常集中在一个配置视图里类似stp region-configuration region-name MNG-REGION revision-level 1 instance 1 vlan 10 instance 2 vlan 20 active region-configuration需要注意一定要执行激活操作否则区域配置只是改了缓冲区没有被生成树协议真正采用。这点和VLAN配置要先创建再应用到端口是一样的道理。4. 中兴交换机MSTP配置实战从规划到命令行4.1 需求规划一个让大家抄作业的拓扑为了把配置讲明白我构建一个常见的中型网络。核心层有两台交换机代号Core-A和Core-B之间用两条链路做聚合或互联接入层有两台交换机代号SW1和SW2各自双上联到两台核心。业务方面VLAN 10承载办公网段VLAN 20承载服务器管理网段。要求网络无环路冗余同时对两根上行链路做负载分担VLAN 10优先走Core-AVLAN 20优先走Core-B其中任意链路故障后能自动切换。这个需求在实际项目里非常典型。如果使用RSTP两台核心之间必须阻塞一条链路而且SW1、SW2上只有一条上行链路处于转发状态另一条永远空闲带宽白白浪费。用MSTP就能让两条链路同时工作。4.2 全局启用MSTP并配置区域中兴交换机的命令行风格简洁进入系统视图后第一步是设置生成树模式为MSTP。命令大致如下system-view stp mode mstp有了这个全局模式后继续配置区域。所有参与MSTP的交换机区域名称、修订级别、实例映射必须完全一致。这里我建议区域名称不要随便用最好和网络业务区划挂钩。比如某公司项目使用编号我会命名为统一的业务编码好处是未来跨厂家调试时能快速判断对方区域配置是否正确。在两台核心和两台接入交换机上统一执行以下配置stp region-configuration region-name MNG-REGION revision-level 1 instance 1 vlan 10 instance 2 vlan 20 active region-configuration这样的话实例1负责VLAN 10实例2负责VLAN 20其余未映射的VLAN默认属于实例0。所以如果网络里还有其他管理VLAN建议显式给它一个归宿比如instance 0 vlan 1避免管理流量意外走了一条不可控的路径也别让它默认落在某个未知的实例上。4.3 指定各实例的根桥和备份根桥区域配置完成后接下来是让每个实例有不同的根桥。我希望Core-A成为实例1的根桥Core-B成为实例2的根桥同时互为主备。在中兴设备上可以通过stp instance instance-id priority命令调整桥优先级数值越小优先级越高。默认优先级为32768把Core-A的实例1优先级设为4096它就会胜过其他设备成为实例1的根桥。Core-B的实例2同理。同时为了备用根桥可以给Core-A再设实例2的优先级为8192Core-B设实例1优先级为8192。这样一台核心失效时另一台能立刻顶上实例根桥的位置。Core-A stp instance 1 priority 4096 stp instance 2 priority 8192 Core-B stp instance 1 priority 8192 stp instance 2 priority 4096对于接入交换机SW1、SW2为了保证收敛时不会跳变它们不用配置特别低的优先级维持默认即可。这里还要注意根桥的优先级配置是针对实例而言的不要写成全局的stp priority那样会导致两个实例的根桥都是同一台设备负载均衡就白做了。4.4 端口角色优化与边缘端口配置MSTP计算完成后交换机之间的互联端口会自动形成根端口、指定端口、备份端口等角色一般不需要手工干预。但为了让接入层到核心的路径符合预期建议在上联端口上明确设置路径开销的标准或使用默认值。如果设备或链路速率不同默认开销计算方式会有差异比如1G口开销是2000010G口开销是2000此时生成树会天然优先选10G路径这是合理的。没有特殊需求建议不要手工篡改路径开销避免拓扑不符合直觉。与PC、服务器、AP对接的端口则需要配置为边缘端口。边缘端口不参与生成树计算直接进入转发状态终端接入后不会经历STP的收敛等待。中兴设备下通常这样配置interface gigabitethernet1/0/1 stp edged-port enable quit也可以选择在接口下使用stp disable彻底关闭STP但我不推荐。因为一旦这个端口被人误插网线连到另一台交换机上就会形成环路且没有任何保护。边缘端口虽然跳过生成树计算但收到BPDU后依然会触发STP处理逻辑这是比直接关闭STP稳妥得多的做法。表配置操作对应目标速查操作对象目的关键命令或参数全局模式启用MSTPstp mode mstp区域配置形成统一MST域区域名称、修订号、实例映射一致核心A实例1主根stp instance 1 priority 4096核心B实例2主根stp instance 2 priority 4096终端端口免收敛直通stp edged-port enable4.5 完整的例行配置脚本把上述配置拼在一起以Core-A为例完整脚本大致是这样system-view stp mode mstp stp region-configuration region-name MNG-REGION revision-level 1 instance 1 vlan 10 instance 2 vlan 20 active region-configuration quit stp instance 1 priority 4096 stp instance 2 priority 8192 interface gigabitethernet1/0/1 stp edged-port enable quit接入交换机SW1的脚本除了根桥优先级不同外基本一样。需要注意中兴一些型号还提供了stp enable全局开关如果你发现设备默认关闭生成树需要先执行这个命令开启。我记得在部分低端交换机的默认配置里STP是关闭的必须要显式开启这个步骤经常被漏掉导致前面所有配置全部无效却怎么查都查不出原因。5. 验证与排错别等网络断了才看日志5.1 必须掌握的查看命令配置完成后第一步要确认STP模式确实是MSTP而不是停留在默认模式。在中兴设备上执行display stp可以查看全局生成树状态输出信息里会包含运行模式、当前角色、桥优先级等关键值。如果显示MSTP正常启用再进一步用display stp instance 1查看实例1的根桥、根端口、指定端口信息。举一个典型的验证过程我在一台接入交换机SW1上执行display stp instance 1返回结果里如果根桥ID显示为Core-A的桥MAC和优先级说明实例1的根桥选举成功然后查看SW1各端口的角色上联到Core-A的端口应该是“根端口”或“指定端口”另一个上联到Core-B的端口则根据拓扑可能是备份或替换端口。再执行display stp instance 2此时根桥应该变成Core-B。如果两个实例的根桥都是同一台设备问题基本出在优先级配置没生效或者实例映射错乱。管理VLAN或调度VLAN的默认实例也需要验证执行display stp brief能快速看到所有VLAN端口的状态和角色。我习惯配置完所有步骤后把这个列表打印出来对照设计拓扑核对每一处转发和阻塞是否与预期一致。5.2 端口状态停留在“监听/学习”不动——常见原因配置完发现交换机的某个端口状态一直停留在监听或学习状态没有转转发。这种情况多半和边缘端口配置缺失或故障链路倒换有关。先看这个端口是否连接到终端设备如果是PC或服务器必须确认边缘端口是否已经配置。如果已经配了边缘端口但端口收发了BPDU设备会把这个端口自动转换为非边缘端口重新经历生成树收敛这时候网络会有几十秒的断流排查时可以通过抓包看端口是否持续收到BPDU。另外如果两台交换机之间既配置了Eth-Trunk/聚合又配置了STP要注意聚合成员端口必须处于统一状态否则每个成员端口会作为独立物理端口参与生成树计算导致环路判断错乱。中兴设备上建议先创建聚合口把STP配置应用在聚合逻辑口上物理成员口不要单独配置。5.3 BPDU收发不正常的排查思路MSTP的实例状态依赖BPDU的交互。如果display stp中显示某端口BPDU收发计数持续为0说明该链路可能没有收到任何生成树帧。这时检查物理链路、接口是否为Access口或Trunk口并确认对端设备MSTP已开启。Trunk端口在MSTP里的正常工作没有问题但要注意本端Trunk允许的VLAN列表必须包含相应VLAN否则即使STP在工作业务VLAN也无法在该链路上转发。还有一个容易漏的点是MSTP区域间的互联不会完全隔离它们之间走的是CIST路径。如果跨区域业务不通不要急着怀疑路由或防火墙先检查区域配置是否正确。我曾经遇到一个两栋楼互联的MSTP配置楼A区域名称是“MNG”楼B区域名称是“MNG-1”两边看着都差不多但就是VLAN间二三层都通不了最后核对才发现区域名称一个字符之差导致所有VLAN的生成树计算全部错误。这种问题用display stp region-configuration逐台比对配置是最快的解决方式。5.4 故障切换效果如何验证配置完成后一定要做故障演练不要只依赖理论判断。我常用的做法是在接入交换机的两个上联端口中临时手动shutdown主用端口。切换应该在秒级完成观察Ping业务IP的丢包数不超过几个包或者干脆用快速Ping测试每秒发包量观测断流窗口。恢复主用端口时链路重新协商和端口角色变更同样需要时间测试业务是否回切也至关重要。如果切换时业务中断太久优先看根桥是否发生了重新选举。正常优先级配置下故障切换只会影响端口角色变化根桥不应变化。如果日志里出现根桥漂移或TC事件频繁触发就要慎重检查是否存在环路或优先级配置未生效。6. 我在生产网上配置MSTP踩过的坑6.1 坑一全局STP没开启所有配置“白做了”有一类问题很隐蔽设备上配置了MSTP模式、配置了区域、配置了实例映射所有命令都敲进去了但上联端口依然处于转发状态怎么看都不符合树形拓扑。排查到最后发现这台设备的全局STP默认没有启用需要执行stp enable开启。中兴部分型号在出场配置里STP默认关闭有些型号默认开启同一厂商不同产品线也有差异。我的经验是配置前先执行一遍display stp看全局状态如果显示Disabled就先行开启再进入后续配置。这一步写在前头能省掉后面一整轮排错。6.2 坑二接入层和核心层的VLAN映射表不一致VLAN映射表不一致的杀伤力我前面提过一次但它的隐蔽性值得我再强调。假设核心交换机上实例1映射VLAN 10实例2映射VLAN 20接入交换机上因为配置更新漏了只给实例1映射了VLAN 10VLAN 20没写那么VLAN 20会落到实例0的默认树里。这时VLAN 20的两条上联路径变得不可预测可能长期走备份端口也可能跨区域绕行。更糟的是两台设备对MST配置的理解不一致会认为它们不在同一个MST区域导致CIST和MSTI之间相互影响VLAN 10也可能跟着遭殃。我现在的习惯是在所有设备上执行同一份区域配置模板并且在版本发布单里明确要求配置比对。新上线设备直接用脚本生成配置杜绝手敲遗漏。6.3 坑三边缘端口裸奔环路隐患被“埋在地底下”边缘端口如果配置不当网络短时间看不出问题但一旦有人误操作就出大事。可以这样操作比如在某个接入端口同时连接了一台PC和一台普通交换机而这个端口被配置成边缘端口PC上联的这条链路如果和对端交换机的另一条链路构成环路生成树因为边缘端口不参与计算不会去阻塞任何端口广播风暴会直接爆发。所以在设计阶段必须明确哪些端口会连接终端且只连接终端。如果接入的是带网管功能的IP电话或者AP它们后面可能还串联着终端设备这就要评估是否真的可以安全配置边缘端口。中兴交换机上边缘端口可以加stp edged-port enable但并没能彻底隔绝BPDU。收到BPDU后边缘端口会自动转为普通端口这一点是设备保护机制不能省。6.4 坑四跨厂商对接时MSTP参数差异在实际网络中完全避不开跨厂商互联的场景。MSTP虽然遵循IEEE 802.1s标准但不同厂商在实现细节上仍有差异。中兴设备和另一厂商设备互联最常见的问题是Bridge ID中MAC地址的排序方式不同或者MSTP域配置格式不同。比如有的厂商区域配置要求必须定义格式选择符默认是0中兴设备不显示这个参数但交互时仍然会携带。双方配置看似正确但区域不一定能建立成功。遇到这种情况我建议摒弃MSTP的思路退回到RSTP作为跨厂商互联的兜底方案在边界交换机上使用RSTP与对端互通内部保留MSTP。虽然损失了跨厂商的负载均衡但换来了稳定性和可排查性。如果必须全链路MSTP那么一定要找双方技术手册彻底核对区域配置参数的每一个字段包括区域名称、修订级别、VLAN映射表以及格式选择符。6.5 最后分享一个排查清单每次配置完MSTP我都会按这个顺序自检一遍这个习惯帮我避过很多雷先看所有设备STP是否全局开启再看区域配置是否完全一致并把实例映射核对三遍然后确认核心交换机的实例优先级是否按规划配置接着用display stp和display stp instance 1确认实际根桥和端口角色随后做一次主备切换演练记录业务断流窗口最后把边缘端口列表和物理端口规划表对一遍确保没有误配和遗漏。把这几步走完MSTP在网络上基本就是“隐形”的平时你不会感受到它的存在但关键时刻它能把冗余链路的价值真正发挥出来。