最近一直在练网络竞赛里很常见的二层综合实验，题目把VLAN、MSTP、链路聚合三个知识点放在同一个拓扑下。说句实话，单个知识点单独学，感觉都不难，可真把它们揉在一起配置的时候，交互关系才是最容易翻车的地方。这篇文章按我自己练习时的完整过程往下走，把每个步骤背后的原因讲清楚，适合正在备赛或者想理解企业网二层冗余机制的人参考。
1. 这个实验到底在解决什么问题：隔离、冗余与带宽的组合拳
很多初学者以为这个实验就是把VLAN建了、把链路聚合配了、把MSTP开了，最后能ping通就完成任务。实际上这样练完什么都记不住。综合实验的价值在于让你理解：二层网络一旦出现冗余路径，就一定存在环路风险；要解决环路又会浪费冗余链路；而MSTP靠多实例让不同VLAN走不同路径，链路聚合则先把多条物理链路合并成一条逻辑链路，让生成树的计算结果更干净、更可控。
我做个简单的分工表，先把这个实验的“骨架”立起来：
| 技术 | 负责解决什么 | 不负责解决什么 |
|---|---|---|
| VLAN | 广播隔离、业务隔离、缩小故障域 | 链路冗余、环路防止、带宽叠加 |
| 链路聚合 | 增加带宽、物理链路故障切换 | 跨设备路径选择、环路防止 |
| MSTP | 消除二层环路、按实例选路做负载分担 | 增加物理带宽、替代链路聚合 |
这三者的关系，可以类比成一个城市路网：VLAN是给不同车流划分专用道，链路聚合是把多条车道合并成一条大马路，MSTP则是在多条可用马路之间安排哪个方向放行、哪个方向暂时封闭。企业网里真正的要求不是其中任何一项单独成立，而是它们协同成立。
1.1 为什么三件套经常绑在一起出现
核心交换机双上联是很常见的组网方式。如果每对上联链路都有两条物理线，不聚合就会出现两条平行链路，生成树会阻塞其中一条导致带宽浪费；聚合之后，这一对线在逻辑上变成一条，带宽翻倍，故障切换也快。可聚合做完，交换机之间仍然可能形成环路，比如核心与核心之间、核心与接入之间组成的“方环”，这时必须靠生成树协议来阻断。
但如果只用普通STP，阻断的那条链路在整个VLAN里都不能用，冗余资源仍然闲置。MSTP把不同VLAN映射到不同生成树实例，每个实例独立计算阻塞端口，VLAN 10走这条路径、VLAN 20走另一条路径，两条上行链路就能同时工作。这就是为什么网络竞赛的综合实验总喜欢把这三样放在一起：它们刚好覆盖了“隔离、冗余、带宽、负载分担”四个核心诉求。
2. 拓扑设计与VLAN/Trunk的落地细节
动手敲命令之前，一定要先把拓扑和VLAN规划按自己的话说清楚。我练的这个实验，用了两台核心交换机和两台接入交换机，接入交换机SW1、SW2分别通过两组物理链路上联到两台核心，核心之间也有一条互联链路。为了防止同一条邻居之间出现平行物理线，每一对上联都做成了链路聚合。
拓扑关系可以简化为一个方环：
CORE-A --------- 聚合5 --------- CORE-B | \ / | | 聚合1 聚合4 | 聚合2 \ / 聚合3 | \ / | | \ / | SW1 -------（无直连，经核心互通）------- SW2SW1与CORE-A之间用两条物理口做聚合1，SW1与CORE-B之间用两条物理口做聚合2；SW2到两台核心同理。CORE-A与CORE-B之间也用聚合5。这个拓扑里，VLAN广播报文可以走多条路径，所以必须靠MSTP来决定哪些逻辑口转发、哪些逻辑口阻塞。
2.1 业务VLAN怎么规划
我规划了三个业务VLAN：VLAN 10给办公终端，VLAN 20给监控设备，VLAN 30给访客网络。接入交换机上给终端口划为access口，分别加入对应VLAN。核心和接入之间的上行口全是trunk，只放行这三个VLAN。
这里有一个习惯特别重要：trunk口不要图省事直接放行所有VLAN，尤其是生产环境。放行越多，广播域越大，MSTP BPDU扩散范围也越大，一旦有人误接设备，影响面会被放大。竞赛实验里虽然VLAN少，但从一开始培养“最小放行原则”，后面处理复杂拓扑会轻松很多。
2.2 接入端口与VLAN划分的配置顺序
在SW1上，我先把VLAN建好，再给终端口配置access：
vlan batch 10 20 30 interface GigabitEthernet1/0/10 port link-type access port default vlan 10 interface GigabitEthernet1/0/20 port link-type access port default vlan 20 interface GigabitEthernet1/0/30 port link-type access port default vlan 30核心交换机上同样需要先创建VLAN，否则trunk口放行时会提示VLAN不存在。按照一般设备习惯，vlan batch 10 20 30可以一次性创建多个VLAN，比一条条创建靠谱。接入层配完后先不要接上行线，把那几个VLAN的access口都检查一遍，免得后面MSTP收敛排查时混入接入侧的低级问题。
3. 链路聚合的配置与转发逻辑
链路聚合在这个实验里的作用，不是简单地把两根线绑在一起，而是把“生成树眼中的拓扑”简化。配MSTP之前，先把聚合处理好，后面看端口角色时思路会特别顺。
3.1 二层聚合口和成员口的关系
在命令行里，逻辑口叫Bridge-Aggregation，成员口通过port link-aggregation group加入。配置顺序上，建议先在物理口上执行“清空原有配置”或初始化，再创建聚合口并配trunk，最后加入成员口。反过来容易出问题，因为成员口加入聚合组时，它自己的二层属性会被聚合口覆盖，调试时很迷惑。
以CORE-A连接SW1的这组链路为例：
interface Bridge-Aggregation 1 port link-type trunk port trunk permit vlan 10 20 30 interface GigabitEthernet1/0/1 port link-aggregation group 1 interface GigabitEthernet1/0/2 port link-aggregation group 1SW1上对应的那组也要相同配置，两端聚合模式必须一致。我建议直接使用动态聚合，也就是链路聚合控制协议模式，这样对端设备可以协商成员口状态，某一根线没插好或者光衰异常时，不会硬生生把坏链路放进转发，排错也方便。
3.2 聚合流量从哪里分担，哪里不分担
必须说明一个常见误区：同一聚合组内部，流量是按报文地址或会话特征分担到不同成员口的，但两只不同核心的上行链路并不属于同一个聚合组，不能靠链路聚合来做跨设备负载均衡。跨设备的双上联路径选择，要靠MSTP实例去控制。
所以我在这个实验里的分工很明确：
- CORE-A到SW1的两条物理线，用聚合1变成一条逻辑链路；
- CORE-A到SW2的两条物理线，用聚合2变成另一条逻辑链路；
- SW1和SW2到两台核心的“方向选择”，交给MSTP。
如果聚合组内部只有少量终端电脑，根本观察不到带宽翻倍，因为流量特征不够多。想看聚合的实际效果，最好用压测工具产生并发流量，再查看成员口的计数，否则会误以为配置没生效。另外，聚合组里的成员口在MSTP计算中是同一个逻辑口，不会被单独阻塞。这意味着生成树如果决策要阻塞这个方向，整组链路都阻塞；如果不阻塞，整组都能转发，不会出现一根线转发一根线阻塞的诡异状态。
4. MSTP多实例：防环和负载分担一箭双雕
链路聚合做完之后，二层拓扑从“多根平行线”变成了“几条粗逻辑链路”，但方环依然存在。接下来就是MSTP出场的时候。
4.1 域配置与实例映射
MSTP和普通STP最大的不同是引入了“域”的概念。只有域名称、修订号和VLAN映射关系完全一致的交换机，才会被认为在同一个MST域内，才能正常计算多实例。只要有一台设备忘了改region名，或实例映射错了一个VLAN，它就会被当成另一个域的设备，生成树结果变得不可控，甚至出现无法预料的阻塞。
我在四台交换机上统一执行：
stp mode mstp stp region-configuration region-name LAB instance 1 vlan 10 instance 2 vlan 20 instance 3 vlan 30 active region-configuration这里要提醒一句：instance 1 vlan 10是把VLAN 10映射到实例1，VLAN 20映射到实例2，VLAN 30映射到实例3。如果还有其它VLAN没被映射，它们会默认落在实例0里。实例0是每个MST域都必须存在的，即使不关心它，也要给它规划好根桥，否则未知VLAN流量仍然可能乱走。
4.2 根桥优先级设计与路径选择
MSTP负载均衡的核心，就是让不同实例的根桥分布在不同的核心交换机上。比如CORE-A作为实例1的主根、实例2和实例3的备根；CORE-B作为实例2和实例3的主根、实例1的备根。这样VLAN 10的流量默认偏向CORE-A转发，VLAN 20和VLAN 30的流量偏向CORE-B转发。
CORE-A上配置：
stp instance 1 root primary stp instance 2 root secondary stp instance 3 root secondaryCORE-B上配置：
stp instance 1 root secondary stp instance 2 root primary stp instance 3 root primary配置完好，我自己会再确认一遍所有交换机的stp mode已经是mstp。很多设备默认跑的是RSTP，如果接入交换机忘改，它和核心就不在一个模式下工作，MSTP实例算不对是必然的，而且这类问题看端口状态很难一眼发现。
有人会问，为什么不干脆用RSTP，再手动阻塞某条上行线，效果不是一样吗？不行。RSTP只有一个生成树实例，同一时刻对全网所有VLAN全局选路，除非永远只让一个方向转发，否则无法做到不同VLAN走不同路径。MSTP的多实例才能实现“同样的物理拓扑，对不同业务流量给出不同转发策略”。这也解释了为什么根桥优先级要配合VLAN映射一起设计，光改域配置不改根桥，负载分担是不可能发生的。
5. 我练完几轮之后的验证方法：别只看ping得通
很多同学验证实验，习惯拿两台PC互ping一下，通了就宣告成功。这在综合实验里远远不够。ping通只能说明某种路径可用，根本看不出当前这条路径是不是你规划的那条，也看不出阻塞端口是否符合预期。必须形成一套命令行层面的检查套路。
5.1 用状态输出确认设计生效
我练完一组配置，会依次执行下面几条检查：
display vlan：看到VLAN 10/20/30都存在，并且access口和trunk口归属正确。display link-aggregation summary：确认聚合组编号、成员口状态，成员口必须是Selected，不能有Unselected。display stp region-configuration：确认每台交换机的域名称、修订号、实例映射完全一致。display stp instance 1 brief、display stp instance 2 brief、display stp instance 3 brief：看每个实例在每台交换机上的端口角色。
我习惯把预期结果写成一张对照表，再拿命令行输出逐项核对：
| 检查项 | 期望结果 |
|---|---|
| 实例1的根桥 | CORE-A |
| 实例2的根桥 | CORE-B |
| 实例3的根桥 | CORE-B |
| SW1上实例1的根端口 | 指向CORE-A的聚合逻辑口 |
| SW1上实例1的阻塞端口 | 指向CORE-B的聚合逻辑口 |
| SW1上实例2的根端口 | 指向CORE-B的聚合逻辑口 |
| SW1上实例2的阻塞端口 | 指向CORE-A的聚合逻辑口 |
这里有一个很容易让人糊涂的地方：同一个物理聚合口，在实例里既可能是根端口，也可能是阻塞端口。就像SW1的“上联CORE-A聚合口”，在实例1是根端口，负责转发VLAN 10；在实例2却是阻塞端口，VLAN 20不能从这边走。这不是故障，恰恰是MSTP负载分担的表现。
5.2 故障注入：拔线之后看自愈
验证通过后，我还会做故障注入练习。先拔掉SW1到CORE-A聚合组中的一条物理线，理论上聚合组不会断，成员口剩余那条会继续转发，业务不中断。此时用display link-aggregation summary看成员口状态，原本有两个Selected成员，拔掉后只剩一个Selected，其他预警日志会提示物理口down。
更关键的测试是拔整个聚合组，也就是把SW1到CORE-A的两条线全拔掉。这时MSTP会把VLAN 10的转发路径切到CORE-B，原本阻塞的备端口会经历Discarding到Learning再到Forwarding。如果用ping持续灌流，会在切换瞬间看到几个丢包，随后恢复。收敛时间取决于设备参数和网络规模，在普通实验环境秒级收敛是正常的。
故障注入一定要按顺序做：先确认备用路径和阻塞端口没问题，再拔线。如果上来就把所有线拔光，或者一次性接出环来，可能瞬间广播风暴，设备CPU飙高，日志刷屏，反而不利于定位问题。
6. 翻车复盘与练习节奏建议
综合实验练几轮之后，我整理了一些容易踩的坑，写在这里省得大家再花一遍排查时间。
6.1 常见坑
第一个坑是MSTP域配置不一致。有一次我在其中一台交换机上把region-name LAB打成了region-name Lab，表面上区域名字基本一样，实际上大小写不同就被视为两个域。那时实例计算怎么都不对，链路聚合和VLAN都查遍了，最后才发现是大小写问题。从那以后，每次配置完必查display stp region-configuration。
第二个坑是根桥没有预先设置。如果四台交换机优先级都一样，生成树会按照MAC地址自动选根，最后谁是根是随机的，我之前规划的路径全部失效。做这类实验，一定要在配置之前就把根桥规划写在纸上，然后用root primary或优先级命令固定下来。
第三个坑是聚合物理口还保留着旧的access配置。有些交换机成员口之前可能是access口，加入聚合组后它的二层属性会跟聚合口走，但如果设备固件版本不同，偶尔会出现遗留配置影响聚合协商。稳妥做法是把物理口恢复默认状态再入组。
第四个坑是跨设备聚合这个想法本身。我第一次练这个拓扑时，试图把SW1到CORE-A和CORE-B的两条物理线放进同一个聚合组，结果根本起不来。链路聚合的原理决定了两条成员链路最终必须汇聚在同一台设备上的同一个逻辑口，跨设备双上联如果想做“虚拟聚合”，需要先做堆叠或横向虚拟化，让多台核心看起来像一台设备。普通交换机组网里，跨设备路径用MSTP控制才是常规做法。
6.2 我的练习步骤建议
我会建议新手严格按照“规划→静态配置→验证→故障注入”的顺序来，不要跳步：
- 先画拓扑，标出哪些物理口组成哪个聚合口，哪些VLAN映射到哪个MSTP实例，根桥放哪台。
- 先配VLAN、access和trunk，不要接上联线。
- 配链路聚合，两条物理线中先只接一条，确认trunk和VLAN通。
- 接第二条物理线，观察聚合组是否正确协商，这时候还没配MSTP也不要紧，聚合本身会把两条线当成一条逻辑链路。
- 开启MSTP并配置域、实例和根桥，再逐实例查看端口角色。
- 做故障注入，断开单条成员口和整个聚合组，记录切换现象。
我在实际练习里发现，MSTP和链路聚合是“逻辑口”层面配合最紧密的一对。没有聚合时，生成树要在大量物理口之间计算，端口一多非常容易眼花；有了聚合，生成树面对的是几条干净的逻辑链路，哪个实例走哪个方向一目了然。综合实验练的就是这种“规划-配置-验证-复盘”的闭环习惯，命令量本身不大，关键是把状态机吃透。最后提一个小习惯：每完成一台设备，我都会导出配置文件存一份，文件名叫SW1_lab_before_validate.cfg之类的备份，后面改坏了好快速回滚。现在我自己练这个实验，基本能在一轮配置里做到零翻车，但刚开始那几次的报错和日志，反而是让我理解最深的素材。
