1. 从一条闲置的上行链路说起MSTP到底解决了什么前阵子帮某单位做核心网络改造拓扑并不复杂两台核心交换机做双机互备十几台接入交换机全部双上联到核心。业务也简单办公网和视频监控网都在二层跑。结果改造过程中撞上一个非常典型的问题——只要开了STP两条上行链路里总有一条被阻塞。办公和监控的流量全部挤在一条链路上另一条上千兆的链路平时完全空着只有故障切换时才派上用场。后来我把方案切到MSTP上把VLAN按业务拆成不同实例让两台核心在不同实例里分别扮演根桥两条链路同时进入转发状态链路利用率直接翻倍冗余能力一点没丢。这篇文章就围绕MSTP展开聊聊它为什么会出现、核心机理是什么、实际部署时怎么规划和配置以及这几年运维中遇到的各种坑。适合正在做园区网、局域网二层改造的运维人员也适合准备数通认证、想真正理解生成树协议而不只是背命令的朋友。1.1 二层环路冗余链路的原罪先说清楚为什么生成树这一类协议会存在。二层交换机的基本转发行为是收到广播帧、组播帧或者未知单播帧时除了接收端口之外的所有端口都转发一份。如果物理拓扑里存在环路一个广播帧会被无休止地复制、循环几秒钟就能把交换机的CPU打满MAC地址表也会因为同一台终端的MAC从不同端口到达而反复震荡终端直接断网。这不是理论推演任何人拿两台交换机接成环试一下就明白了广播风暴起来之后连管理地址都ping不通。但网络设计又偏偏需要冗余。核心到接入、接入到终端总得留一条备用路径万一主路径光纤被挖断、光模块老化业务不能断。于是问题就变成既要保留冗余链路又要让数据在正常状态下只沿一条逻辑路径走环路出现时能自动切断备用路径主路径失效时能快速恢复。STP生成树协议解决的就是这件事。它通过在所有交换机上选举一台根桥然后通过BPDU报文交换路径信息计算出每台设备到达根桥的最短路径最短路径对应的端口进入转发状态其它构成环路的端口被阻塞。逻辑拓扑就从物理环变成了一棵无环的树。1.2 STP和RSTP的共同短板全网只有一棵树STP能破环RSTP能让收敛速度从几十秒降到秒级但它们有一个共同的结构性问题全网不管有多少个VLAN最终只生成一棵生成树。这是什么概念呢。一台接入交换机上有办公VLAN 10、监控VLAN 20双上联到核心A和核心B。STP计算完之后假设根桥是核心A那么接入交换机面向A的端口是根端口面向B的端口大概率成为Alternate备用端口被阻塞。结果就是VLAN 10和VLAN 20的数据帧都只能走A方向B方向完全空闲。即便核心B上接了很多服务器接入层也只能望而兴叹流量就是绕不过去。有人会问多配几个VLAN不就行了吗没用STP和RSTP的生成树实例只有一个所有VLAN共用同一棵树的转发路径所谓按VLAN分流根本做不到。在某些厂商早期的私有方案里确实出现过每个VLAN一棵树的做法用流量控制灵活可一旦VLAN数量上百生成树实例数量直接失控CPU和带宽消耗都非常难看跨厂商互通更是灾难。这就是MSTP登场的原因。它既要保留RSTP的快速收敛能力又要解决多个VLAN共用一条路径导致带宽浪费的问题还得控制生成树实例的数量不能为每个VLAN都算一棵树。1.3 MSTP的答案实例、域与多棵树MSTP的核心思想可以概括成一句话把一组VLAN捆绑成一个实例每个实例独立计算一棵生成树不同实例可以有完全不同的根桥和转发路径。举例来说规划两个实例实例1绑VLAN 10、20实例2绑VLAN 30、40。让核心A在实例1中是根桥核心B在实例2中是根桥。这样接入交换机在实例1中的根端口指向A在实例2中的根端口指向B。办公流量正常沿A方向走监控流量正常沿B方向走两条上行链路同时满负荷工作万一A宕机实例1重新选举根桥为B网络自动收敛冗余能力依然保留。这就是MSTP最核心的价值不是简单多跑几棵生成树而是用受控数量的实例把原本闲置的冗余链路变成可用的转发路径实现真正意义上的负载均衡。理解了这一点后面所有机制——MST域、配置标识、CIST、域根——都是在为这个目标服务。2. MSTP的三个关键机制域、配置标识与生成树类型MSTP不是简单地把一个网络切成多个实例就完事。实际部署时交换机数量可能几十上百台如果每台交换机都维护全网所有实例的完整信息协议的开销和调试复杂度会失控。所以协议引入了域的概念把具备相同配置的交换机组装成一个逻辑整体域内跑多棵实例树域间只跑一棵公共树把问题分而治之。2.1 MST Region三要素为什么缺一不可MST域MST Region是MSTP中最重要的逻辑边界由三要素唯一确定域名Region Name相当于这个域的标识名称配置修订级别Revision Level用于区分同一域名下的不同配置版本VLAN与实例的映射关系表也就是哪些VLAN被划进了哪个实例。三个要素完全一致的交换机才会被识别为同一个MST域它们之间交换完整的多实例BPDU信息。只要有一个要素不一致设备就会认为对方属于另一个域双方只能通过域间的公共生成树相连。举个例子核心A上配置域名REGION-A修订级别1VLAN 10映射到实例1接入交换机B上配置域名REGION-A修订级别2VLAN 10同样映射到实例1。按三要素比对两者修订级别不同在协议眼里就是两个不同的域。这种不一致在运维中极其常见而且故障现象往往非常隐蔽——VLAN 10的转发路径可能仍然通但不符合预期因为你以为它们在同一棵实例树里实际却走了域间公共树。注意绝大多数MSTP的配置界面里只要修改了VLAN映射关系系统就会提示修改修订级别。如果你手动把版本号改回去或者某些设备同步配置时漏改了这一项就会出现配置看起来一样实际域划分不一样的坑。排查时务必三要素逐个比对。2.2 实例、CIST、IST和MSTI的关系MSTP协议里涉及的生成树类型名词比较多CIST、IST、CST、MSTI很多人一开始容易绕晕。我习惯用范围来区分它们。CIST是公共和内部生成树它是整个交换网络总的一棵生成树全网无论分成多少个域最终在逻辑上都要归到CIST这个唯一的总树上。CIST的根桥也就是全网总根是唯一的。CIST由两部分拼接而成一部分是各MST域内部的IST另一部分是连接各域之间的CST。IST是实例0也叫内部生成树。每个MST域内部实例0天然存在它负责承载域内那些没有显式映射到其它实例的VLAN同时承载域内的管理通信。IST把域内的所有设备连接成一个整体让每个域在CIST中表现为一个节点。CST是域间生成树负责连接各个MST域以及传统STP/RSTP设备。CST运行在各域之外只关心域与域的连接关系不关心域内部的具体拓扑。MSTI是实例1到实例N也就是用户定义的其它生成树实例。每个MSTI在域内独立计算、独立选举根桥。同一台交换机在不同MSTI中可以扮演完全不同的角色既可以是实例1的根桥也可以是实例2的普通桥。为了更好地对照我用表格整理了一下生成树类型范围作用CIST全网总生成树由IST和CST拼接根桥全网唯一IST单个MST域内部实例0承载未映射的VLAN和管理帧CST各MST域之间连接域与域、以及连接外部传统生成树设备MSTI单个MST域内部用户自定义实例承载映射的VLAN独立计算路径2.3 BPDU里的配置标识如何决定设备归属MSTP的BPDU桥协议数据单元是在RSTP BPDU基础上扩展的里面除了常规的根桥ID、路径开销、端口ID还携带一段MST配置标识内容就是前面说的三要素。当一台交换机收到MST BPDU时首先不是急着比较路径开销而是先解析配置标识和自身配置做比对。一致则把发送方归入同一个域按MSTI信息参与计算不一致则把发送方视为外部区域走CST处理逻辑。这个先认亲、再算账的设计保证了不同配置的交换机之间不会互相污染实例信息也大大减少了BPDU的体积。理解了BPDU中的配置标识再看常见的域分裂故障就容易了——不是协议出bug而是设备之间对自己属于哪个域的判断对不上。配置修订级别、域名、映射表任何一个变体都会让原本的域在逻辑上一分为二。3. 生成树计算到底在算什么总根、域根与端口角色MSTP的配置不难难的是出问题时能根据现象反推计算过程。这一节我把MSTP的计算逻辑拆开讲重点把总根选举、域根选举、端口角色这三个关键概念理清楚。3.1 CIST总根的选举规则CIST总根是全网的顶配设备它的选举规则和STP/RSTP完全一致比较的是桥ID优先级数值小者优先优先级相同则MAC地址小者优先。每台设备初始时都认为自己是总根然后通过BPDU向邻居宣告自己的根桥ID、路径开销等信息。收到BPDU后设备会比较收到的根桥ID与自己当前记录的根桥ID保留更优的那个同时计算出自己到达总根的最短路径开销并继续向下游转发。这个过程会在全网泛洪直到所有设备就总根达成一致。默认情况下所有交换机的STP优先级都是32768。如果核心A的MAC比核心B小A就会成为CIST总根。注意CIST总根并不一定是物理位置最核心的设备它只是优先级和MAC地址综合比较的结果。这也是很多网络的隐患所在——某台接入层交换机可能因为MAC地址更小、优先级配置不当意外成为全网总根导致所有流量路径全部绕道核心之间的直连链路反而被阻塞。3.2 域根与Master端口CIST总根选举出来之后每个MST域内部会进一步选举出本域的域根Regional Root。域根的定义是域内距离CIST总根路径开销最小的那台交换机。在同一个MST域里域根可能有多台设备并列路径开销相同时但最终只会选出一台作为域根。域根是整个域在CIST中的代言人。域内的IST计算是以域根为根来展开的域内所有设备通过IST共同协作。而域间CST在连接这个域时看到的域的出口就是Master端口——域边界上通往CST方向、路径开销最优的那个端口它类似整个域面向CIST总根的根端口。在MSTP里Master端口是必须能正确识别的。如果一台边界交换机有两个以上端口连接外部域Master端口选出后其它候选端口会进入Alternate状态等待替换。很多跨域流量走弯路的问题都是Master端口位置不符合预期导致的。3.3 端口角色和状态的完整对应MSTP的端口角色比STP/RSTP多但逻辑并不复杂。我用表格把角色和典型出现位置列出来端口角色出现位置作用根端口非根桥设备上本设备到达域根/CIST总根的最优路径端口指定端口每条链路的指定侧负责把桥信息转发到下游网段根桥上的端口通常都是指定端口Alternate端口非根桥设备上根端口的备份主根端口失效时可快速接管Backup端口某条链路或网段上指定端口的备份提供冗余但平时阻塞Master端口域边界设备上域通往CST方向的出口相当于域在CIST中的根端口域边界端口域边界设备上连接其它MST域或传统STP/RSTP区域的端口端口状态则相对简化Forwarding转发数据帧、Learning学习MAC但暂不转发、Discarding不转发也不学习。需要特别说明的是Alternate、Backup、Master这些角色都对应Discarding状态逻辑上阻塞但不影响它们作为备份端口在故障发生时快速切换。3.4 用实例做负载均衡的底层原理现在把前面所有的机制串起来看看负载均衡到底是怎么实现的。假设有两台核心A和B接入交换机C双上联。规划实例1承载办公VLAN实例2承载监控VLAN。我们在A上把实例1的桥优先级设为0实例2的桥优先级设为4096在B上反过来实例1设4096实例2设0。这样CIST总根可能仍然是A但实例1的根桥是A实例2的根桥是B。在实例1的生成树计算中C面向A的端口路径开销更优成为根端口面向B的端口成为Alternate所以办公流量走A在实例2的计算中C面向B的端口成为根端口面向A的端口成为Alternate所以监控流量走B。两条上行链路同时转发互不抢道。注意实例1和实例2各自独立选举根桥所以完全可以把根桥分散到两台核心上。这是MSTP负载均衡的精髓——实例划分只是手段把根桥位置错开才是真正的目的。4. 从规划到落地MSTP部署配置与验证理解了原理配置就只是把这些逻辑落实到命令里。但实际部署时很多细节比命令本身更重要比如实例怎么划分、优先级怎么设、配置完怎么验证。我按实施顺序往下说。4.1 实例规划的基本原则实例规划是整个MSTP部署的起点规划得好后面几乎没麻烦规划得随意后面全是这里绕路、那里不通的疑难杂症。第一实例0不要承载业务VLAN。实例0是CIST的一部分负责管理通信和域间互通让它保持轻量能减少不必要的拓扑变化。很多生产网把管理VLAN留在实例0里业务VLAN全部显式映射到其它实例这是一个好习惯。第二按业务组转发方向来分实例。一个实例里的VLAN应该有相近的流量路径需求。办公终端数量多、流量零散适合放一个实例视频监控流量大、方向集中适合放另一个实例服务器和存储对接核心防火墙可能又是独立的路径。把路径需求相近的VLAN绑在一起根桥选择才有实际效果。第三实例数量要克制。MSTP的价值在于用少量实例实现分流而不是建几十个实例。二三层网络规划里3到6个实例足够覆盖绝大多数园区网需求。实例过多优先级配置、故障排查的复杂度都会成倍上升。第四核心设备上要预留故障切换通道。假设实例1根桥在A、实例2根桥在B如果A宕机实例1要能快速把根桥切换给B所以B在实例1里不能只是普通优先级通常应该设置为次优比如priority 4096保证切换路径是设计过的而不是临时随机选举出来的。4.2 核心配置命令逐条拆解我把配置过程按步骤铺开假设网络里有四台核心设备两台核心交换机和两台接入交换机域名统一实例划分一致。第一步全局启用MSTP。如果设备默认运行STP或RSTP需要切换到MSTP模式stp mode mstp第二步创建MST域配置配置域名、修订级别和实例映射。以某类企业级交换机的通用命令行风格为例stp region-configuration region-name CORE-MIST revision-level 1 instance 1 vlan 10 20 30 instance 2 vlan 40 50 60 active region-configuration注意最后的active region-configuration这个动作必须执行配置才会真正生效并参与BPDU交换。很多配了没反应的问题都是忘了激活。第三步在核心A上设置实例优先级让它成为实例1的根桥、实例2的次优根桥stp instance 1 priority 0 stp instance 2 priority 4096第四步在核心B上做相反的设置stp instance 1 priority 4096 stp instance 2 priority 0这样实例1的主根桥是A备份是B实例2的主根桥是B备份是A。接入交换机不需要额外配置实例优先级保持默认32768即可它们只需要计算路径、选出根端口。4.3 配置后的验证方法和判断标准命令配置完只完成了30%的工作剩下的70%是验证。我每次实施MSTP至少会做三件事。第一确认全网MST域配置一致性。逐台设备执行display stp region-configuration检查域名、修订级别、实例映射三要素确保每台设备输出完全一致。这一步能排除绝大多数域分裂隐患。第二查看实例根桥和端口角色。在核心A上执行display stp instance 1 root可以确认实例1的根桥是不是自己实例2的根桥是不是B。再执行display stp instance 1 brief查看接入交换机在实例1中的端口角色确认面向A的端口是根端口ROOT、面向B的端口是AlternateALT。然后在核心B上对实例2做同样的检查。第三做一次实际流量验证。最简单的办法是在不同VLAN的终端之间互ping然后在核心交换机的上联口看流量计数更严谨的做法是拔掉一条链路看收敛速度和路径切换是否符合预期。上联口有没有流量实例划分有没有真正生效一查便知。4.4 多域场景下的边界问题如果网络规模较大比如总部和分公司通过二层专线互联可能需要在不同站点配置不同的MST域。每个域拥有域名和映射表域间通过CST连接跨域VLAN流量只能沿CIST路径走无法享受域内的多实例分流。这时要留意两个问题。一是域边界的Master端口位置它决定了跨域流量从哪个出口走配置前要明确规划二是不要为了让多个站点看起来像一个域而强行统一域名和映射表。如果VLAN规划不一致强统反而会引发配置标识紊乱不如划分成多个域让CST去完成域间桥接。5. 运维中常见的MSTP故障现象、原因与排查链路协议本身设计得再严谨配置层面的疏漏也总会出现。这几年处理过的MSTP故障不算少问题表象五花八门根因却高度集中基本都是配置一致性、根桥位置、端口角色这三类。我把典型场景梳理出来每个都能对应到实际排障过程。5.1 VLAN映射不一致导致的域分裂故障现象某台接入交换机下挂的终端通过VLAN 10访问服务器时延迟忽高忽低拓扑偶尔出现环路告警抓包发现这台交换机和其它设备之间的BPDU频繁被丢弃。排查链路先查接入交换机与核心交换机的MST域配置。display stp region-configuration显示接入交换机把VLAN 10绑定到了实例2而核心交换机把VLAN 10绑定在实例1。三要素中的映射表不一致接入交换机和核心交换机被判定为两个不同的MST域域间CST重新计算路径变化导致转发震荡。处理方法统一所有设备的VLAN映射。如果这是一台新上线设备直接改配置如果是批量割接建议先在图上标好每台设备的映射关系再逐台修改并执行active region-configuration。改完后必须重新检查display stp region-configuration确认每一台的输出一致。5.2 修订级别改完忘同步故障现象某次给核心交换机增加新VLAN映射后网络突然出现间歇性丢包紧接着接入层的端口角色大面积变化。排查链路查看核心交换机的修订级别为2另一台核心还是1。实际上改动映射表后配置变更会自动触发修订级别变化但部分接入交换机没有得到新配置还在用旧的修订级别。域里一半设备认为是新配置域一半设备认为是旧配置域整个域被拆成两半CIST重新收敛丢包随之而来。处理方法在所有相关设备上统一修订级别。我习惯把修订级别当作配置版本号看待每次修改实例映射就主动把revision-level加1并统一同步到整个域。不要把修订级别当成一个随意填的数字它在协议里承担着域身份校验的责任。5.3 根桥位置不对造成次优路径故障现象核心A和B各有业务流量但A上联口的转发量远大于B即使B侧链路明明带宽更大。接入交换机的两条上行链路里有一条始终没有流量。排查链路display stp instance 1 root发现实例1的根桥既不是A也不是B而是一台接入交换机。原因是这台接入交换机曾经是哪台设备的优先级被误设为4096加上MAC地址较小在实例1中意外成为根桥。它这个根桥让核心A不得不通过接入交换机中转才能连接到核心B核心间的直连链路被阻塞流量路径全部绕远实际转发效率大打折扣。处理方法把根桥优先级重新规划。在同一厂商设备上设置核心A优先级为0、核心B为4096核心设备务必压到最低避免接入层设备抢到根桥。设置完成后再看display stp instance 1 root确认根桥在预期位置。根桥位置直接决定全网转发路径。优先级配置不是随便给核心设个小的就完事而是要具体到每个实例都明确主根、备份根并且让接入层优先级保持在默认值以上不做特殊调整。5.4 与其它设备对接时的兼容问题MSTP是标准协议但不是所有老旧设备都支持完整MSTP特性。和仅支持STP/RSTP的设备对接时MSTP端口会自动回退到RSTP或STP模式运行这种兼容行为本身是安全的但会导致边界端口的角色和预期不一致进而让某些VLAN的路径不同于域内设计。处理这类问题首先要明确定位设备支持的能力再决定是否在边界端口上做协议模式约束。接入层设备如果长期不更换而且本身不感知VLAN可以考虑把核心到它的链路配置成trunk时端口接入模式显式指定为RSTP让MSTP域内的复杂实例不延伸到这台设备上。实测下来这种方式比强行让老旧设备跑MSTP稳定得多也让后续排障范围更可控。6. 关于MSTP运维我沉淀下来的几个习惯文章最后说几个纯粹来自实战的习惯也许可以帮读者少走弯路。第一个习惯是改配置前先拍照。修改MSTP配置之前我会先执行一遍display stp region-configuration和display stp instance all brief把当前状态留下来。一旦改动后网络异常可以直接和改动前对照快速定位是哪台设备的哪些参数变了。第二个习惯是统一变更全量执行。MSTP是全局性的协议配置必须全网一致。如果只改一台设备剩下的设备会立刻在协议层面感知到域身份变化。每次割接时我会把所有涉及MSTP的设备分组逐组把域名、修订级别、映射表全部对齐再逐台激活。永远不要贪快只在一两台设备上改动就跑去测业务。第三个习惯是让实例0保持干净。实例0承载CIST和三要素校验是MSTP所有计算的基础。无论业务怎样扩展我都不会把业务VLAN塞进实例0也不会让实例0承载过多管理和监控流量。这样CIST收敛快域间故障排查也简单。第四个习惯是把备份路径当主路径一样验证。配置MSTP负载均衡后我会主动拔掉核心A的上联观察实例1的根桥是否快速切换到B业务是否恢复。备份路径如果不经过实际演练等到真正出故障时可能发现交换机之间的链路聚合、优先级限制等细节并没有按预期生效。MSTP这个协议表面看是一组配置命令实际运维中检验的是对域、实例、根桥、端口角色这一整套逻辑的理解。把原理吃透再回头处理那些看起来极度复杂的网络故障会发现大部分问题其实都出在配置一致性和根桥位置这两个点上。希望这篇梳理能让正在研究MSTP的朋友少走我之前走过的弯路。