1. 为什么我坚持让每个新手先做一遍STP生成树协议实验1.1 一个真实踩过的二层环路事故几年前我在一个办公网络里排查过一次全网卡顿的事故现场情况极其典型两台接入交换机之间被同事随手插了一根备用跳线本意是做冗余结果整个办公区网络开始剧烈抖动交换机面板上的指示灯疯狂闪烁几台核心设备的CPU占用直接拉满员工的电脑时断时续连网关都ping不通。当时我们从三层角度查了半天路由表、查了ARP表、抓了包全都没问题最后顺着MAC地址表异常学习这条线索才定位到那根多余的网线。拔掉之后网络瞬间恢复。这个事故的本质就是二层没有TTL机制。IP报文每经过一个三层设备TTL会减一减到零就被丢弃所以三层环路会自愈但以太网帧没有这个字段广播帧、未知单播帧、组播帧在环路里会被无限复制转发形成广播风暴几秒钟就能把一条千兆链路跑满。这就是我做STP生成树协议实验的出发点——它不是考试里的一道题而是二层网络里唯一一道防环闸门。STP生成树协议实验的核心价值在于把环路怎么形成、协议怎么破环、选路结果为什么是这样这三件事在可控环境里跑一遍让你以后在真实网络里看到端口闪断、看到某条链路明明是通的却不转发流量、看到拓扑变更告警时脑子里能立刻浮现出根桥、路径开销、端口角色这几个关键词而不是只能重启设备碰运气。这篇文章适合刚接触交换网络的入门者也适合做了几年但一直靠拔线重启解决问题的朋友。下面我按实验设计、概念铺垫、参数推演、实操配置、排错复盘这几个层次把这套实验完整拆一遍。1.2 这套实验到底要达成什么目标我把这套实验的目标拆成四层从浅到深。第一层是看得见能亲手构造一个物理环路观察没有STP时广播风暴是怎么把网络打瘫的这个冲击感比看一百页文档都强。第二层是说得清能根据拓扑和优先级参数提前手算出根桥是谁、每台交换机的根端口在哪、每条链路的指定端口在哪、哪个端口会被阻塞然后上台设备验证自己的推演是否正确。第三层是控得住能通过手工指定根桥、调整端口开销、启用边缘端口这些手段主动干预选路结果让流量走你希望它走的那条路。第四层是查得动面对一个已经收敛但行为异常的生成树能用正确的命令序列把问题定位出来。很多教程把实验做成敲完这几条命令看到端口变绿就完事这种做完等于没做。我的做法是先给出预期结果再上机验证不一致的地方才是真正学到东西的地方。这套流程后面会详细写。2. 实验前必须啃透的几个核心概念2.1 BPDU报文里到底装了什么生成树的全部决策都建立在一种叫BPDUBridge Protocol Data Unit的二层报文上默认每2秒由各交换机从指定端口发一次。它不走IP直接封装在以太网帧里目的MAC是一组固定的组播地址所以即使交换机还没学任何业务MACBPDU照样能传。理解BPDU的字段是理解整个协议的前提。关键字段有这么几个根桥IDRoot Bridge ID、根路径开销Root Path Cost、发送者桥IDBridge ID、发送者端口IDPort ID再加上三个定时器——Hello Time默认2秒、Max Age默认20秒、Forward Delay默认15秒。这里有个特别容易忽略的点BPDU里的根桥ID和根路径开销记录的是发送者认为的当前最优信息而不是本地信息。也就是说一台非根桥发出的BPDU里面填的根桥是它自己认定的根桥根路径开销是它到根桥的距离。这就像是邻居告诉你我离超市走路要10分钟你判断自己过去要多久时得用他给的10分钟加上你到他家的时间。这个设计带来的直接后果是根桥发出的BPDU里根路径开销是0第一跳邻居收到后加上自己入口链路的开销再转发出去时这个值就变成了非零。整个网络通过这种接力累加的方式让每台设备都知道自己离根有多远。如果你在抓包时看到某台交换机的BPDU里根路径开销莫名其妙很大那基本可以判断它到根桥的路径出问题了。2.2 桥ID、优先级与根桥选举的比对规则桥ID是8个字节前2字节是网桥优先级后6字节是设备的MAC地址。优先级的默认值是32768取值必须是4096的整数倍范围从0到61440。这个4096步长的规定不是随便定的因为优先级字段的低12位在早期标准里是留给VLAN标识用的后来MSTP沿用了这个划分方式所以实际可用的只有高4位。根桥选举的规则非常朴素桥ID越小越优先。比较顺序是先比优先级优先级相同再比MAC地址MAC小的赢。这意味着在没有人工干预的情况下网络中MAC地址最小的那台设备会成为根桥——这个结果是随机的、不可控的也是为什么生产环境里一定要手工指定根桥的原因。你永远不会希望一台放在角落里的老旧接入交换机因为MAC地址碰巧最小就成为整个园区的流量中心。我在实验中一般会把核心交换机优先级设成4096备用核心设成8192接入层保持默认32768。这样既保证了主备关系明确也给后续可能新增的设备留出了调整空间。如果直接把主核心设成0看似最保险但万一以后要插入一台优先级更低的设备做临时测试就没有余量了。2.3 路径开销的标准差异与选路逻辑路径开销的计算有两套主流标准这是新手最容易栽跟头的地方。老标准802.1D-1998用16位数值10M链路开销100、100M链路19、1000M链路4、10G链路2。新标准802.1t用32位数值100M链路200000、1000M链路20000、10G链路2000。问题在于老标准里100M和1000M的开销是19和4差距不到5倍而实际带宽差距是10倍到了10G和1000M开销是2和4差距只有2倍完全失真了。所以现代设备默认都用新标准数值大但比例准确。你在做实验时如果发现两端设备算出来的路径开销对不上导致选路结果诡异八成是一端配了老标准。这类问题在实际割接中非常隐蔽因为设备各自算各自的谁也不报错。选路的完整流程是四步。第一步选根桥全网唯一。第二步每台非根桥选一个根端口也就是到根桥最近的那个口判断依据依次是根路径开销最小、对端桥ID最小、对端端口ID最小、本地端口ID最小。四个条件逐级递进前面分出胜负就不再看后面。第三步每条链路上选一个指定端口判断依据是该链路上哪台设备的根路径开销更小谁小谁当指定端口相等则比桥ID再相等比端口ID。第四步既不是根端口也不是指定端口的全部阻塞。我用一个具体数字走一遍。假设三台交换机SW1、SW2、SW3组成三角形SW1是根桥链路开销都是20000。SW2的根端口选到SW1的那条根路径开销20000。SW3的根端口也选到SW1的那条根路径开销20000。SW2和SW3之间这条链路SW2在链路上的贡献是它的根路径开销20000SW3也是20000相等那就比桥IDSW2的MAC更小所以SW2这一侧成为指定端口SW3那一侧被阻塞。这就是为什么看起来更近的链路有时候反而不转发流量——它压根不是比物理距离是比这四个递进的向量。2.4 端口角色与状态迁移的完整生命周期传统STP有五种端口状态Disabled不转发也不学MAC不参与生成树、Blocking不转发、不学MAC但收BPDU、Listening不转发、不学MAC参与选举、Learning不转发、开始学MAC、Forwarding转发也学MAC。一个端口从阻塞到转发要经历Blocking→Listening15秒→Learning15秒→Forwarding总共30秒如果是从链路故障中恢复还要先等Max Age 20秒超时合计50秒。这50秒就是很多人抱怨拔了线要等快一分钟才能通的根源。端口角色上根端口和指定端口最终进转发状态阻塞端口在RSTP里叫Alternate端口留在阻塞。这里有个细节值得注意阻塞端口并不是完全不工作它依然在收BPDU一旦连续20秒收不到更优的BPDU就会认为自己这条路径失效重新参与计算。所以你去抓阻塞端口的包是能看到BPDU在流动的很多人一看这个口不转发业务但有报文就以为坏了其实是正常的。RSTP把这套状态简化成三种Discarding、Learning、Forwarding并且引入了边沿端口Edge Port和P/AProposal/Agreement快速握手机制。边沿端口接终端设备配置后直接进转发、跳过所有等待一插上就能上网P/A机制让两台交换机之间的指定端口和根端口通过一次协商直接进入转发把秒级收敛变成了可能。MSTP在RSTP基础上又加了多实例可以让不同VLAN走不同的生成树实现负载分担。这三个协议在实验里的对比非常值得做一遍后面会给出具体的配置。3. 实验拓扑设计与参数规划3.1 拓扑结构与设备角色分配我的实验拓扑用五台交换机组一个双核心三接入的结构链路间刻意做出三角形和四边形环路这样能同时观察多个阻塞点。具体安排是SW1和SW2作为双核心互联一条千兆链路SW1分别下联SW3、SW4SW2分别下联SW4、SW5SW3和SW5之间再拉一条横向链路构成大环路。终端PC1挂SW3PC2挂SW4PC3挂SW5三个终端在同一个VLAN 10里网段用10.10.10.0/24网关暂时不配因为实验只关心二层行为。这套拓扑刻意设计了三类典型场景SW1-SW2之间的核心互联是最短路径之争SW3-SW5的横向链路是冗余备份链路最终会被阻塞SW4同时连两个核心是多条等价路径下的四步选路。设备选型上不需要太高端支持802.1D/802.1w/802.1s的普通二层或三层交换机都可以几台废旧设备、模拟器都行。我个人更推荐用真实设备做前两遍因为模拟器对定时器的模拟往往不准确50秒收敛你等不到看不到真实的等待过程。参数规划上我把SW1的优先级设为4096SW2设为8192SW3、SW4、SW5保持默认32768。链路开销不手工干预先观察默认计算结果。三个终端口的端口优先级和开销都不动。这样初始状态下SW1必然成为根桥SW2成为备份根桥这是预期结果也是后面所有推演的基础。3.2 关键参数对照表与预期结果推演上机之前先做一张表把所有参数和预期结果写清楚这张表是实验的答案卷上机就是核对。项目参数设定说明协议版本802.1D首轮/ 802.1w次轮/ 802.1s末轮分三阶段做对比收敛差异根桥SW1优先级4096手工指定不用默认选举备份根桥SW2优先级8192优先级次低主根失效时接管其余设备优先级32768默认不干预观察默认值下的角色链路开销标准802.1t32位统一标准避免两端不一致Hello Time2秒默认不改观察默认行为Max Age20秒默认故障检测的等待时间Forward Delay15秒默认状态迁移的等待时间预期结果推演如下SW1根桥所有直连SW1的端口在SW1侧都是指定端口并转发SW3、SW4、SW5各自选一个根端口优先选直连SW1的那条开销20000SW4因为有两条到根桥的路径经SW1或经SW2会比较两条路径的根路径开销——经SW1是20000经SW2是200002000040000所以SW4的根端口在连SW1的那条上连SW2的口会被阻塞。SW3-SW5横向链路SW3侧根路径开销20000SW5侧根路径开销20000都直连SW1相等比桥ID假设SW3的MAC更小则SW3侧是指定端口SW5侧阻塞。这套推演里有三个地方最容易算错一是忘了非根桥的根路径开销要加上自己出口链路的开销二是比到最后一步忘了还有端口ID这个兜底条件三是没注意端口ID是优先级端口号端口优先级默认128、步长16不同设备的端口编号方式不同。我第一次做的时候就栽在第三点上两台设备的端口号一个是G0/0/1一个是G1/0/1我按字符串大小比了半天实际比的是数值。提示推演结果一定要写在纸上再上机不要上机之后再倒推答案。倒推会让你误以为自己懂了实际上什么都没学会。4. 完整实操过程与命令记录4.1 基础网络搭建与无STP的环路复现第一步刻意先不配STP把物理环路接起来看看会发生什么。这一步是整个实验最有价值的部分但也是最容易把模拟器跑崩的部分建议在真实设备上做或者用模拟器时限制观察时间。先把三台终端的IP配好10.10.10.1/24、10.10.10.2/24、10.10.10.3/24交换机上创建VLAN 10把所有互联口和终端口都划进VLAN 10。配置本身很简单以VRP风格命令为例sysname SW1 vlan 10 quit interface GigabitEthernet0/0/1 port link-type trunk port trunk allow-pass vlan 10 quit interface GigabitEthernet0/0/2 port link-type access port default vlan 10 quit按拓扑把所有链路配好之后STP默认是开启的所以你还看不到风暴。这时候手工把五台交换机的STP全部关掉undo stp enable全局关闭之后从PC1持续ping PC2然后观察现象。你会看到ping在最初几秒还勉强能通随后延迟飙到几百毫秒、上千毫秒接着开始大量丢包最后完全不通。交换机面板上的链路指示灯从规律闪烁变成常亮说明链路已经被广播帧占满了。这时候在任意一台交换机上查MAC地址表会看到同一个MAC地址在多个端口之间疯狂跳变一秒钟能刷好几屏。这个现象的原理很简单PC1发一个ARP广播SW3收到后从所有其他端口泛洪出去SW4、SW5各收到一份它们继续泛洪由于环路存在这个广播帧会在SW3→SW4→SW1→SW2→SW5→SW3这个圈里一直转每转一圈复制几份指数级增长。二层设备没有TTL唯一的终止条件就是链路带宽耗尽、缓冲区溢出开始丢包。注意做这一步时把观察时间控制在30秒以内持续风暴可能导致设备的控制面CPU被BPDU和泛洪报文打满出现管理口都登不上的情况。真遇到了直接断电重启别硬扛。观察完把STP重新打开风暴会在几十秒内消失网络恢复。这个关闭-复现-开启-恢复的完整闭环是我认为整个实验里最有说服力的部分。4.2 手工指定根桥与备份根桥STP打开之后先看默认状态下谁是根桥。在所有交换机上执行display stp输出里会有一行Root bridge : yes或者CIST Root/ERPC之类的信息找到那台标着自己是根桥的设备。绝大多数情况下这台的MAC地址在五台里最小纯属巧合。这个结果直接在真实网络里就是隐患所以接下来手工干预。在SW1上把优先级降到4096stp priority 4096在SW2上设成8192stp priority 8192配置下发后生成树会重新计算一次根桥切换到SW1。这里有个值得注意的细节修改优先级会触发一次拓扑变更全网短暂震荡几秒所以生产环境做这类调整一定要安排好窗口。另一种更优雅的写法是在SW2上直接配stp root backup在SW1上配stp root primary设备的软件会自动帮你计算合适的优先级不用记4096这个数字。但我在实验里更喜欢手写具体数值因为你能明确知道优先级是多少而不是被软件智能掉。验证方式是再查一遍display stp确认SW1显示自己是根桥SW2显示根桥是SW1且自己不是。然后手动把SW1和SW2之间的链路断开观察SW2是否能接管根桥角色。这个切换过程在传统STP下大概需要50秒你会明确感受到那段网络不通的窗口期这种感觉很重要它让你以后在用户投诉断网一分钟时能立刻对上号。4.3 用端口开销干预选路默认选路不一定符合你的流量规划。比如某个场景你希望SW5的流量走SW3那条横向链路而不是绕远走核心直觉上会觉得直连核心更快但生成树的判断依据是根路径开销不是跳数也不是物理距离。假设我们想验证这个结论把SW3上连接SW1的端口开销手工调大看看选路会不会翻转。在SW3上执行interface GigabitEthernet0/0/1 stp cost 100000 quit这个值的含义是让SW3认为经这条链路到根桥要花100000而经横向链路到SW5再经SW5到SW1总开销是200002000040000比100000小。理论上SW3的根端口应该切换到横向链路上原本被阻塞的横向端口变成转发。上机验证用display stp interface查看端口角色确认是否翻转。我第一次做这个实验时翻转没成功查了半天发现是链路开销标准不一致SW3默认用802.1t千兆开销20000而我手填的100000是照着老标准的量级写的结果数值确实比40000大逻辑上应该翻转。真正的原因是SW5那一侧的开销还保持着默认路径总和算下来和我推的不一样。这种参数没问题但结果不对的情况只能靠逐段核对每台设备的实际开销值来定位。修正之后选路确实翻转了SW3的根端口变成了横向链路。但这带来一个新的副作用SW5的根端口也可能跟着变因为SW5到根的路径现在可能经过SW3。生成树是一个全局联动的系统你动一个端口的开销可能引发好几台设备的角色重排。所以我一般建议在实验里每次只改一个变量改完立刻把全网的角色记录一遍形成一张前后对比表这样才看得清联动关系。4.4 结果验证与命令速查验证环节决定了你到底有没有真的看懂实验结果。我的习惯是从四个维度依次查谁当根桥、每台设备的根端口在哪、每条链路的指定端口是谁、哪些端口被阻塞。验证目标常用命令观察要点全局角色概览display stp根桥ID、本地桥ID、根路径开销、根端口指定端口详情display stp interface GigabitEthernet0/0/1端口角色、端口状态、端口开销、指定桥BPDU报文内容display stp bpdu-statistics 或抓包收发计数、根桥字段是否异常拓扑变更记录display stp topology-change变更次数、最近一次变更时间端口收敛统计display stp interface brief各端口当前状态一览IOS风格的设备对应命令是show spanning-tree、show spanning-tree interface、show spanning-tree detail。两者输出结构不同但信息一致。我强烈建议把display stp的完整输出粘到文档里和自己上机前推演的表格一行行对对不上的那一行就是你的知识盲区。还有一个进阶的验证方法在SW1和SW2之间、SW3和SW5之间的链路上分别抓BPDU对比两个方向上BPDU的根路径开销。你会清楚看到同一个根桥ID、不同的路径开销这比看命令输出直观得多。抓包工具随便用一个支持二层抓取的就行过滤条件设成生成树专用的组播目的地址即可。4.5 换上RSTP和MSTP再跑一遍传统STP跑通之后把协议切到RSTP命令很简单stp mode rstp切换之后重复刚才的断链测试你会明显感觉到收敛时间从50秒降到1秒以内。原因有两个一是RSTP用P/A机制让端口之间直接协商不用等定时器超时二是RSTP的故障检测依赖邻居连续3次收不到BPDU也就是6秒左右就判定失效不用等满20秒的Max Age。这两点让RSTP在现代网络里成了默认选择。接着再切到MSTP配置稍微复杂一些要划域stp mode mstp stp region-configuration region-name lab revision-level 1 instance 1 vlan 10 instance 2 vlan 20 active region-configuration quit域内所有设备的域名、修订级别、实例与VLAN的映射表必须完全一致否则会认为不在同一个域退化成CIST计算。这是MSTP最常见的配置错误没有之一。配不一致的时候设备不会报错只会各自按CIST算看起来生成树也通但你规划的双实例负载分担完全没生效。我在实验里故意配错过一次两台设备一台映射了VLAN 10到实例1另一台忘了配结果两台设备互相看不到对方的MST配置display stp region-configuration的输出对比一眼就能看出来。MSTP跑通之后就可以观察到真正有价值的效果VLAN 10和VLAN 20的流量分别走SW1一侧和SW2一侧两条链路都不浪费同时互为备份。这个效果在传统STP下是做不到的因为只有一个实例所有VLAN共用一棵树必定有一条链路被彻底阻塞。5. 排错实录与常见问题速查5.1 那些看起来像设备坏了的现象做这套实验的人几乎都会遇到几个经典现象我把它们整理成表遇到时先对照一下能省掉大量瞎猜的时间。现象最常见原因排查动作端口一直卡在Discarding不转发对端端口没开STP或者收到了更优BPDU查对端是否关闭了STP查该端口收到的BPDU根桥ID断链后要等40至50秒才恢复传统STP的定时器机制正常现象确认协议版本切RSTP观察差异两端算出的选路结果不一致链路开销标准一端是802.1D一端是802.1t逐台核对端口实际生效的cost值MSTP多实例不生效域配置三要素不一致对比两端的region-name、revision、映射表接入终端插拔引起全网拓扑震荡终端口没配边沿端口把终端口设为边缘端口并启用BPDU保护反复出现拓扑变更告警空口频繁上下、光模块老化、边缘端口配置错误查拓扑变更计数增长频率定位到具体端口5.2 端口不转发但链路是通的这是最高频的问题。链路物理层正常指示灯亮但业务不通查生成树发现端口在阻塞状态。排查路径我一般按这个顺序走。先确认这个端口应该是什么角色。如果你的推演说它该是根端口但实际是阻塞那就是对端发出的BPDU比你预期的更优。登录对端查它的根路径开销看它到根桥的距离是不是比你算的小。常见的坑是对端有一条你没注意到的低开销路径或者对端优先级被别人改过。再确认端口收到的BPDU来源是不是你以为的那台设备。如果中间串了一台没纳管的设备BPDU可能被它截获后重新发出来信息就变了。这种情况在接入层跑多个小交换机的地方特别常见查的时候要顺着物理链路一段段确认。最后看是不是配置层面的问题端口被手工设成了非指定状态或者端口开销/优先级被改成了不合理值。这类问题往往发生在多人协作的环境里配置是你留的但别人后来动过。5.3 拓扑变更泛洪与MAC表抖动生成树每次拓扑变更都会从根桥开始向下游发送TCN拓扑变更通知每台设备收到后把MAC地址表的老化时间从默认300秒缩短到15秒目的是尽快清掉已经失效的表项。这个机制本身是必要的但它如果被频繁触发就会导致全网MAC表反复被清空再重建转发效率大幅下降。什么样的操作会触发拓扑变更端口从转发变成阻塞、从阻塞变成转发都会触发。所以接入层的终端口如果没配边沿端口员工每天插拔笔记本、笔记本休眠唤醒都会引起一次拓扑变更。一个百人办公区一天触发几千次是很常见的数字后果就是核心交换机的MAC表长期处于半空状态流量大量泛洪。解决办法是给所有接终端的端口配边沿端口并开启BPDU保护防止有人私接交换设备搞出环路interface GigabitEthernet0/0/10 stp edged-port enable stp bpdu-protection quit开了BPDU保护之后如果这个端口收到了BPDU说明对面接的不是终端而是交换机设备会自动把这个口shutdown掉避免环路扩散。这个功能在生产环境是必配项但在实验里要特别小心因为它会把端口锁死你得手工undo shutdown才能恢复很多人第一次遇到会以为设备故障。注意开了BPDU保护之后实验里从终端口拔线插到交换机上这个口会直接进error-down状态这是设计行为不是故障。查display interface能看到error-down的原因用shutdown/undo shutdown清掉即可。5.4 收敛慢到底慢在哪里很多人说STP收敛慢但说不清慢在哪一段。把50秒拆开看就很清楚链路故障后下游设备可能要先等Max Age 20秒超时如果是间接故障本端端口还亮着只是收不到BPDU了然后进入Listening 15秒、Learning 15秒合计50秒。如果是本端链路直接down故障能被立刻感知可以跳过Max Age那就是30秒。RSTP改善的正是这两块用P/A握手跳过30秒的状态迁移等待用3倍Hello时间6秒替代20秒的Max Age。所以RSTP在直接链路故障下的收敛能做到亚秒级间接故障下也就6秒左右。这个数量级的差别在实验里用秒表掐一遍记忆会非常深刻。另外还有一个容易被忽略的影响因素如果网络直径大比如串了七八台交换机BPDU从根桥传播到边缘本来就需要时间网络直径越大收敛越慢。所以在实际设计里接入层到核心的跳数要控制别为了省线把交换机一层层串起来。6. 做完这套实验之后我个人的几点体会这套实验我从最开始的照着教程敲命令到后来能闭着眼推演任意拓扑的选路结果中间大概反复做了七八遍。最开始那几遍基本都在跟配置错误搏斗后来慢慢地注意力从命令怎么写转到了为什么是这个结果这时候实验的价值才真正出来。我个人的第一条体会是一定先算后配。把拓扑画在纸上把每台设备的优先级、每条链路的开销写下来从根桥开始一步步推推完再上机。推错了不要紧上机发现不一致才是最高效的学习时刻因为你的错误认知被具体现象打破了。反过来先配完再看结果你很容易陷入哦原来是这样的假懂状态下次换个拓扑还是不会。第二条是永远只改一个变量。生成树是个全局联动的系统动一个端口可能引发多台设备的角色重排。一次改好几个参数结果错了你根本不知道是哪个引起的。我习惯在实验记录里写清楚本次只改了SW3的G0/0/1开销其余不变然后记录前后两版完整角色表对比着看。第三条是一定要在实验里制造故障。拔线、关端口、改优先级、断开根桥这些操作在实验里是免费的在生产环境里是有代价的。你在实验里把根桥拔掉十次看看切换过程中流量断了多久、多少台设备的MAC表被清、恢复后收敛用了几个周期这些数据积累下来以后做割接方案时心里就有底了。最后分享一个可以继续往下扩展的方向把这套实验和链路聚合结合起来做。两条链路聚合成一个逻辑链路之后生成树看到的是一条链路不会再阻塞其中一条同时聚合组内的成员链路还能互为备份。这个组合是实际网络中非常常见的配置方式把两者放在一起观察端口角色和开销计算的变化会对二层冗余设计有更完整的理解。再往后还可以接上MSTP多实例加VRRP的网关冗余场景那就是一个完整的园区网二层设计实验了。这套东西做到最后你会发现真正难的不是记命令而是在一个复杂的、有冗余的、随时可能出故障的网络里快速判断哪条链路该通、哪条该断、断了之后会怎么切。这个判断力只能靠一遍遍地把拓扑画出来、算出来、验出来。